Lift single-packet ClientHello requirement?

[davidben]

draft-ietf-quic-tls says "QUIC requires that the first Initial packet from a client contain an entire cryptographic handshake message, which for TLS is the ClientHello."

My (possibly incorrect) understanding is this was needed so the server can, in the old QUIC/TLS embedding, statelessly send a HelloRetryRequest without having to statefully assemble a ClientHello out of multiple packets. In the new QUIC/TLS embedding, this concern no longer applies because the stateless rejects are entirely external to TLS. Thus, should we simply delete most of the #clienthello-size section?

This avoids a number of awkward pitfalls because the ClientHello size is a function of many factors, with both client and server considerations that change over time. Perhaps we add a new TLS extension or key share type and some SNIs work but larger SNIs were closer to the limit and this brings them over. Or perhaps the server's NewSessionTicket is large[*] and breaks subsequent connections from some client. Perhaps that server tested it against one client, but another client has a larger baseline ClientHello and then it breaks.

Finally, post-quantum key exchange candidates tend to come with large keys. The current text prevents QUIC from experimenting with or deploying such schemes. This is particularly fun because QUIC clients typically also speak TLS over TCP, so the security of connections to a server is bound by the weaker of TLS over QUIC and TCP.

[*] Client certificates are often inserted into the ticket, so now we have a client-specific limit being influenced by a server-specific implementation decision which is, in turn, dependent on client/CA-controlled size of client certificate. Additionally, draft-ietf-quic-transport#zerortt-parameters implies servers may wish to remember QUIC transport parameters in the ticket.

[ianswett]

This seems like a reasonable change to me.

I don't anticipate this creating any new issues with recovery/etc, though it might exacerbate some of the existing ones.

[mikkelfj]

I believe a main motivation for a single packet is that it avoids binding a lot of state on the server which can be a significant DoS vector. If anything we can expect certificates to get smaller with more widespread use of EC25519. As to post quantum, lets make another QUIC version in about 30-60 years or so.

[janaiyengar]

As @mikkelfj says, I believe there was a concern about state at the server for connections that have not yet been established, if it receives only part of a ClientHello. I don't think this is a debilitating concern however. I would like to air this for a little while though ... I remember us using the assumption that the ClientHello is a single packet a few times, and I'm not sure if we did document them all.

…

On Tue, Jul 23, 2019 at 2:31 PM MikkelFJ ***@***.***> wrote: I believe a main motivation for a single packet is that it avoids binding a lot of state on the server which can be a significant DoS vector. If anything we can expect certificates to get smaller with more widespread use of EC25519. As to post quantum, lets make another QUIC version in about 30-60 years or so. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2928?email_source=notifications&email_token=ACUOBVEOGE7FJPC4OYE3WHTQA5FBLA5CNFSM4IGHDJG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2UA2LY#issuecomment-514329903>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACUOBVGYEWRBGZ65Y5RWAIDQA5FBLANCNFSM4IGHDJGQ> .

[ianswett]

I agree we should not hurry on this. From a text perspective, it's a simple change. I'd like the chairs(@larseggert @mnot ) to briefly bring this up at the next QUIC session to ensure we can be aware of any potential pitfalls before making this change.

[davidben]

I believe there was a concern about state at the server for connections that have not yet been established, if it receives only part of a ClientHello

Could you elaborate on this? There are other client messages than the initial ClientHello, which would all require state at the server for unestablished connections. There is certainly a need to statelessly do something with unestablished connections, but there's a point where the server transitions to being stateful.

In the old TLS/QUIC embedding, yes, that point was at the first ClientHello and you needed the entire ClientHello to produce a HelloRetryRequest+cookie, which was the mechanism for statelessly bouncing a connection. That's no longer the case in the new embedding, as far as I can tell. The retry packets don't actually depend on the full ClientHello or interact with the TLS handshake at all. It should work equally well if that initial packet has a full ClientHello or half of one.

As to post quantum, lets make another QUIC version in about 30-60 years or so.

This time estimate is not consistent with what people are already doing in this space.
https://www.imperialviolet.org/2018/12/12/cecpq2.html

[mikkelfj]

I'm not sufficiently deep into the handshake to detail this - but you are correct that there is less dependency on the TLS engine than what went before. I'm not sure when ClientCerts land in this process - I know they can't always fit in one piece but all else being equal, it simplifies bad content defence a lot to have a consistent starting point.

[nibanks]

If we did allow for multiple packets for the ClientHello, I'd still want to retain the ability to decide whether or not to accept the incoming connection from every one of those initial packets. This would mean things like ALPN and SNI would need to be duplicated in each packet. I wouldn't want to accept a design where an attacker forces the server to buffer packets while it wait for the necessary information just to decided if it can accept the connection. IMO, this sounds like a v2 feature. Does this prevent us from shipping v1?

[martinthomson]

So if a client is forced to split the ClientHello into two datagrams, you can use Retry. I don't think that this is crazy. The only thing we know to be true is that the restriction is annoying.

[martinthomson]

My mistake: late stage process means that only chairs mark things as design. This is a design change.

[DavidSchinazi]

I agree with @martinthomson . We should remove the restrictions and add text explaining that servers can either buffer or send retry. I can write the PR if it helps.

[martinthomson]

Thanks David. We'll probably want to raise this on the list, but I'd greatly appreciate a PR. It should be mostly deleting text, but some advice about how to handle multi-packet startups is probably wise, because it isn't a great situation to be dealing with.

[tatsuhiro-t]

I observed that the size of ticket OpenSSL issues if client certificate is used becomes quite large and it does not fit into a single QUIC packet.

[martinthomson]

NSS does the same because it puts the entire certificate (if not the certification path) into the ticket.

[davidben]

BoringSSL as well.

[huitema]

If we do a change like that, how do we test it?

[larseggert]

Discussed in Cupertino. PR exists #3045. @DavidSchinazi assigned.

[larseggert]

@huitema to add a test to the interop matrix

[huitema]

I just defined the test matrix option Q for Quantum Readiness.