Subject: Re: [quicwg/base-drafts] IANA review of -tls (#4369)

From: Martin Thomson <[email-masked]>
Date: Tue, 08 Dec 2020 01:31:28 -0800

This is NOT ready.  In fact, this is very much un-ready.  I'm in the process of changing salts and retry keys and discovered that this codepoint needs a final value.  I've asked the experts to expedite expert review and - if necessary - to request an early allocation.  

I think that this blocks publication of -33.

-- 
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/4369#issuecomment-740501067

---

From: Nick Banks <[email-masked]>
Date: Tue, 08 Dec 2020 07:56:56 -0800

Follow up question on changing the TLS extension codepoint: Do you expect version negotiation via the VN QUIC extension to work between older draft versions (-29) and final version (-33, v1)? It seems you might need to send both on the client or support both on the server to make things work smoothly...

I _think_ naïve VN (without the extension) should work if the client just regenerates the TLS CH based on the QUIC new version being used.

-- 
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/4369#issuecomment-740707665

---

From: Martin Thomson <[email-masked]>
Date: Tue, 08 Dec 2020 14:40:49 -0800

Excellent question.

Yes, if you use a Version Negotiation packet, this is OK.  At least to the extent that things sort of resolve themselves.  You are pretty badly exposed to downgrade attack though.

The VN-less migration proposed in draft-ietf-quic-version-negotiation won't work without a few tweaks.  My preferred option is to effectively rewrite the TLS handshake to remap the extension codepoint.  Doing that is tricky because both sides need to agree on how that is done or you get a transcript mismatch error.  It's also somewhat invasive to do so.

You could, as you suggest send both extensions, but that isn't a good long-term plan.  Aside from the extra bytes (which is probably manageable), it means that you are sending a private-use extension at scale for an indeterminate period.  That would likely have the effect of making 0xffa5 unusable as a private use codepoint.  I would prefer not to do that.

This only reinforces the need for @ekr and @DavidSchinazi to restart work on their draft.

-- 
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/4369#issuecomment-741154941

---

From: David Schinazi <[email-masked]>
Date: Tue, 08 Dec 2020 15:14:58 -0800

[draft-ietf-quic-version-negotiation](https://tools.ietf.org/html/draft-ietf-quic-version-negotiation) introduces the concept of "Compatible Versions". It is defined as:

>    Two versions of QUIC A and B are said to be "compatible" if a version
   A Initial can be used to negotiate version B and vice versa.  The
   most common scenario is a sequence of versions 1, 2, 3, etc. in which
   all the Initial packets have the same basic structure but might
   include specific extensions (especially inside the crypto handshake)
   that are only meaningful in some subset of versions and are ignored
   in others.  Note that it is not possible to add new frame types in
   Initial packets because QUIC frames do not use a self-describing
   encoding, so unrecognized frame types cannot be parsed or ignored
   (see the Extension Frames section of [QUIC](https://tools.ietf.org/html/draft-ietf-quic-version-negotiation-02#ref-QUIC)).

I think all we need to say is that QUIC versions `ff00001d` (draft 29) and `00000001` (RFC) are considered compatible because the server can receive an INITIAL for one of those versions and it has all the information required for the other version. But we could also just not care and everything will be just fine, servers will need to support both draft 29 and the RFC for a while anyway. I'm not sure what the problem is.

-- 
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/4369#issuecomment-741203221

---

From: Martin Thomson <[email-masked]>
Date: Tue, 08 Dec 2020 17:20:08 -0800

@DavidSchinazi The problem is that the TLS ClientHello for 0xff00001d will contain a different extension codepoint than the very similar message in 0x00000001.  My initial thought was that the server could just rewrite the codepoint in the ClientHello and proceed as you suggest.

I realize now that a server could construct an equivalent ClientHello *in some cases*, but not all.  The PSK binder in TLS certainly throws a wrench in the works.  That suggests the potential for *partial* compatibility, which is really awkward.

-- 
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/4369#issuecomment-741385270

---

From: David Schinazi <[email-masked]>
Date: Wed, 09 Dec 2020 09:03:06 -0800

Can you expand on "in some cases"? Isn't this just a matter of making sure your TLS stack understands the other TP TLS extension codepoint? I'm not suggesting you rewrite the ClientHello before passing it to your TLS stack because that'll derail the key schedule.

-- 
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/4369#issuecomment-741908241

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Dec 2020 18:48:28 -0800

The problem here is that you have a different codepoint for each version.  If the server accepts a ClientHello with one codepoint and generates a ServerHello with the other (which I what I think you are suggesting), the TLS stack won't accept that.

The cases in which a rewrite of the ClientHello would be possible only include non-ECH.  I think that it might be possible for a server to rewrite in the case of PSK if it accepts the PSK, but that's really fiddly.

This all leads me to think that pre-v1 to v1 compatible upgrade is either not worth it at all, or needs to be narrowly limited to those cases where rewrites are possible and trivial.

-- 
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/4369#issuecomment-742200142

---

From: David Schinazi <[email-masked]>
Date: Wed, 09 Dec 2020 19:08:29 -0800

I agree with you that there is no reason to declare `ff00001d` compatible with `00000001` since neither of them has any extra features compared to the other. But my point was that for this to matter your server needs to support both versions, and if it does then it already has code to parse and write both codepoints. Adding an if statement to make sure the ServerHello codepoint matches the ClientHello codepoint sounds feasible. But either way, all this to say that we're fine and we don't need to change anything.

-- 
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/4369#issuecomment-742206606

---

From: Martin Thomson <[email-masked]>
Date: Sun, 13 Dec 2020 14:21:00 -0800

Closed #4369.

-- 
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/4369#event-4106513303

---

From: Martin Thomson <[email-masked]>
Date: Sun, 13 Dec 2020 14:54:48 -0800

Reopened #4369.

-- 
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/4369#event-4106542738