Subject: [quicwg/base-drafts] Lift single-packet ClientHello requirement? (#2928)

From: David Benjamin <[email-masked]>
Date: Tue, 23 Jul 2019 10:39:16 -0700

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](https://www.imperialviolet.org/2018/04/11/pqconftls.html). 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928

---

From: ianswett <[email-masked]>
Date: Tue, 23 Jul 2019 11:16:50 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514324472

---

From: MikkelFJ <[email-masked]>
Date: Tue, 23 Jul 2019 11:31:51 -0700

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 or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514329903

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 23 Jul 2019 11:42:03 -0700

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 <[email-masked]> 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.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2928?email_source=notifications&email_token=ACUOBVEOGE7FJPC4OYE3WHTQA5FBLA5CNFSM4IGHDJG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2UA2LY#issuecomment-514329903>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ACUOBVGYEWRBGZ65Y5RWAIDQA5FBLANCNFSM4IGHDJGQ>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514333564

---

From: ianswett <[email-masked]>
Date: Tue, 23 Jul 2019 11:50:56 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514336702

---

From: David Benjamin <[email-masked]>
Date: Tue, 23 Jul 2019 12:42:14 -0700

> 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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514354972

---

From: MikkelFJ <[email-masked]>
Date: Tue, 23 Jul 2019 13:08:24 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514364306

---

From: Nick Banks <[email-masked]>
Date: Tue, 23 Jul 2019 13:21:32 -0700

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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514368733

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Jul 2019 08:48:23 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514689022

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Jul 2019 08:48:56 -0700

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2928#issuecomment-514689259