ClientHello needs to fit in a single packet #338
Conversation
martinthomson
added
editorial
draft-ietf-quic-tls.md
Outdated
| Implementations are reminded that large session tickets or HelloRetryRequest | ||
| cookies, multiple or large key shares, and long lists of supported ciphers, | ||
| signature algorithms, versions, and other negotiable parameters and extensions | ||
| could cause this message to grow. |
There was a problem hiding this comment.
This also needs to inclde the transport params, right?
draft-ietf-quic-tls.md
Outdated
| @@ -1223,11 +1246,11 @@ by an attacker. | |||
| Certificate caching {{?RFC7924}} can reduce the size of the server's handshake | |||
| messages significantly. | |||
|
|
|||
| A client SHOULD also pad {{!RFC7685}} its ClientHello to at least 1024 octets. | |||
| QUIC requires that the packet containing a ClientHello be padded to 1280 octets. | |||
There was a problem hiding this comment.
"at least 1280 octets"
draft-ietf-quic-transport.md
Outdated
| The initial cryptographic handshake message needs to be sent in a single packet. | ||
| This avoids having to reassemble a message from multiple packets. This would | ||
| require that servers maintain state prior to establishing a connection, exposing | ||
| servers to a denial of service risk. |
There was a problem hiding this comment.
Phrasing unclear. How about "This avoids having to reassemble a message from multiple packets since doing so would require that a server maintain state prior to establishing a connection, exposing the server to a denial of service risk."
draft-ietf-quic-transport.md
Outdated
| servers to a denial of service risk. | ||
|
|
||
| The first client packet of the cryptographic handshake protocol MUST fit within | ||
| a 1280 octet QUIC packet. this includes overheads that reduce the space |
There was a problem hiding this comment.
I don't think we're requiring 1280 bytes, just that it fit within a packet, right? We talk about MTU elsewhere, how about just saying that this packet MUST fit within a single QUIC packet, assuming that the packet is MTU-sized or smaller?
There was a problem hiding this comment.
Well, we can't exclude implementations that choose to only send 1280 octet packets. That would be unwise, I think. This is MORE strict, I agree, but I think that we want to specifically exclude handshake packets that exceed this or we will find that they aren't properly applicable across multiple networks and use cases.
If a handshake packet grows too much, then we limit this to networks that can handle a larger MTU. Given that we don't need the space right now, this seems like a constraint that won't be hard to meet.
draft-ietf-quic-tls.md
Outdated
| ## ClientHello Size | ||
|
|
||
| QUIC requires that the initial handshake packet from a client fit within a | ||
| single packet of 1280 octets. With framing and packet overheads this value |
There was a problem hiding this comment.
"at least 1280 octets."
| risk. | ||
|
|
||
| The first client packet of the cryptographic handshake protocol MUST fit within | ||
| a 1280 octet QUIC packet. This includes overheads that reduce the space |
There was a problem hiding this comment.
change "1280 octet" to "MTU-sized"
martinthomson
force-pushed
the
one_packet_hello
branch
from
ade3e2e
to
6407ce1
Compare
I'm marking this as editorial. It touches both TLS and transport. Anyone who thinks that this is OK can merge it.