Subject: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 5 Jan 2021 19:53:41 -0800

Changing Subject: and adding tls@ ...

On Wed, Jan 06, 2021 at 02:04:02PM +1100, Martin Thomson wrote:
> Hi Ben,
> 
> I'm going to respond here to your DISCUSS points, but leave the comments to our issue tracker.  Lucas has volunteered to do transcription for that.

Sounds good.

> On Tue, Jan 5, 2021, at 15:53, Benjamin Kaduk via Datatracker wrote:
> > (1) Rather a "discuss-discuss", but we seem to be requiring some changes
> > to TLS 1.3 that are arguably out of charter.  In particular, in Section
> > 8.3 we see that clients are forbidden from sending EndOfEarlyData and it
> > (accordingly) does not appear in the handshake transcript.  The
> > reasoning for this is fairly sound; we explicitly index our application
> > data streams and any truncation will be filled in as a normal part of
> > the recovery process, so the attack that EndOfEarlyData exists to
> > prevent instrinsically cannot happen.  However, the only reason we'd be
> > required to send it in the first place is if the server sends the
> > "early_data" extension in EncryptedExtensions ... and we already have a
> > bit of unpleasantness relating to the "early_data" extension, in that we
> > have to use a sentinel value for max_early_data_size in NewSessionTicket
> > to indicate that the ticket is good for 0-RTT, with the actual maximum
> > amount of data allowed indicated elsewhere.  TLS extensions are cheap,
> > so a new "quic_early_data" flag extension valid in CH, EE, and NST would
> > keep us from conflating TLS and QUIC 0-RTT semantics, thus solving both
> > problems at the same time.  On the other hand, that would be requiring
> > implementations to churn just for process cleanliness, so we might also
> > consider other alternatives, such as finessing the language and/or
> > document metadata for how this specification uses TLS 1.3.
> > (There are a couple other places in the COMMENT where we might suffer
> > from scope creep regarding TLS behavior as well, but I did not mark them
> > as DISCUSS since they are not changing existing specified behavior.)
> 
> I don't think that you will find much appetite for changes.  However, I think that your suggestion here shows how we can rationalize the change: negotiating the quic_transport_parameters extension results in the suppression of EndOfEarlyData.  No need for any additional extensions.

I didn't expect to find much appetite for changes, but I wouldn't be doing
my job if I didn't ask the question.  It's a little unusual for something
outside the core protocol to change the behavior of an extension defined in
the core protocol, but perhaps not unheard of.  There is also the question
of whether it would merit an "Updates:" relationship ... since you have to
implement the rest of the new thing to get the new semantics, it may not be
needed.

> Having been responsible for implementing a lot of TLS early data and the QUIC extensions, I can say that your suggestion would be more difficult to manage, because it requires checking two different extensions that independently govern the same behaviour.  (I would concede that I did make some architectural choices that are questionable in light of the above rationalization, but my point stands nonetheless.)

Which behavior is that, exactly?  The QUIC 0-RTT keys are different than
the TLS ones, and the data itself is carried in a different place...

I think the key question for the TLS WG might be how similar something has
to be before it's a good idea to reuse an extension codepoint vs. getting a
new one.

> From a process perspective, if you consider this change to TLS to be out of scope, even though it is specifically limited to QUIC's usage of TLS, then I'm happy to have the TLS working group discuss the change.  It is true that this extension does alter the protocol in a non-trivial way, so requesting specific review is sensible.

I don't think that an argument about "out of scope" is going to be a
particularly useful use of anyone's time, though I do want to see if
framing the question in this way elicits any responses from the TLS WG
(cc'd).

> I will be strongly advocating for no change, of course.  I will note that we did circulate the draft for review already and this issue did not arise, nor did it arise as it was implemented in many stacks, so I would not expect there to be much support for a different design.

I don't want to let process wonkery derail the running code, so hopefully
it is just a short discussion.
For what little it's worth, the patches to enable building a QUIC stack on
top of OpenSSL (that have been rejected by upstream at this point

> > (2) Let's check whether the quic_transport_parameters TLS extension
> > should be marked as Recommended or not.  The document currently says
> > "Yes", and the live registry say 'N'.  That said, the earliest mention I
> > can see of using 'N' in the archives is in
> > https://mailarchive.ietf.org/arch/msg/tls-reg-review/z8MOW0bYNP2KIj4XcCXBe2IOKfI/
> > which seems to just be stating what IANA did when they changed what
> > codepoint (since there were issues with the initially selected value
> > '46') and not a reasoned decision.
> 
> The reason that the codepoint has an 'N' is that an early allocation (which we used to obtain the number) cannot be recommended.  However, the intent has always been to recommend the extension.  I don't think that conditional applicability necessarily disqualifies an extension from being recommended.  Just from a quick scan, I can immediately pick out use_srtp as one we recommend, despite it being highly specific.  

Ah, I had forgotten about the early allocation/Recommended interaction.

If you send "use_srtp" and aren't using SRTP (or RTP at all, even), your
TLS connection can still succeed, though.  If you send
quic_transport_parameters and don't use QUIC, you're setting youself up for
failure.

> I think that recommended means that an extensions comes with the recommendation of the IETF if it provides a relevant function.  Choosing between max_fragment_length vs. record_size_limit is an example of how this might be consumed.

Looking back at what RFC 8447 says, supposedly it's "generally recommended
for implementations to support", and that 'N' is used for things that
(among other things) have "limited applicability" or are "intended only for
specific use cases".  I think this has exactly one specific use case, but
can concede that we can generally recommend implementations to support it
(and all that it brings with).  Thanks for talking it through.

-Ben

> I would strongly prefer that the IETF indicate that they think this extension is good through use of a 'Y'.  That is my understanding of the intent of the signaling.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Jan 2021 10:18:31 -0800

On Tue, Jan 5, 2021 at 7:54 PM Benjamin Kaduk <[email-masked]> wrote:

> > I'm going to respond here to your DISCUSS points, but leave the comments
> to our issue tracker.  Lucas has volunteered to do transcription for that.
>
> Sounds good.
>
> > I don't think that you will find much appetite for changes.  However, I
> think that your suggestion here shows how we can rationalize the change:
> negotiating the quic_transport_parameters extension results in the
> suppression of EndOfEarlyData.  No need for any additional extensions.
>

I agree with MT, especially in view of the fact that DTLS also omitted
EOED, which, I think, reflects the TLS WG view that this is OK technically.

https://tlswg.org/dtls13-spec/draft-ietf-tls-dtls13.html#section-5.5

If QUIC weren't at the IESG now we could just make this change cleanly in
8446-bis (details TBD but something about how datagram protocols don't need
it) but in the real world, we should just do it in QUIC and DTLS and then
retroactively bless it.

-Ekr

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 07 Jan 2021 14:50:43 +1100

Trimming this down.

> implement the rest of the new thing to get the new semantics, it may not be

This isn't an "Updates: X" moment at all in my view.  Extensions to TLS have added new handshake messages (certificate status for instance) without updating what it means to implement the core protocol.  It's only an update in my view if the functions defined in the updated document.
 
> the TLS ones, and the data itself is carried in a different place...

I referred to all of the code that involves 0-RTT.

> to be before it's a good idea to reuse an extension codepoint vs. getting a

If you like.
 
> top of OpenSSL (that have been rejected by upstream at this point

(incomplete?)

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 Jan 2021 20:04:30 -0800

(incomplete?)

> I referred to all of the code that involves 0-RTT.

At what layer?  I honestly do not understand which parts you see as "the
same behavior".  The application will have some data to send early, sure,
but at some point your interface has to know if it's running over TCP+TLS
or over QUIC, and the only differences I see are below that point.  Any
given TLS handshake is intrinsically destined for QUIC or not-QUIC, so
you're never in a situation where you would send both extensions at the
same time.

> > top of OpenSSL (that have been rejected by upstream at this point

Yes, sorry -- interrupted mid-compose.

For what little it's worth, the patches to enable building a QUIC stack on
top of OpenSSL (that have been rejected by upstream at this point in the
3.0.0 release cycle and are now maintained by Akamai and used by several
parties) don't implement support for early data at all, so I don't have any
direct implementation insight to provide.  OTOH, that suggests that people
might not be using QUIC 0-RTT with the openssl TLS stack at all.

-Ben

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 07 Jan 2021 16:11:22 +1100

I'm not sure that the other discussions are productive any more, so I'll fix my errors...

> > This isn't an "Updates: X" moment at all in my view.  Extensions to TLS have added new handshake messages (certificate status for instance) without updating what it means to implement the core pr…

Sorry, ... if the functions in the update alter the operation of the core protocol in ways that the core protocol does not anticipate or allow.

For TLS extensions can (and have) changed all sorts of stuff.

> you're never in a situation where you would send both extensions at the

I was largely referring to the TLS internals that would change if early data was conditioned on a second extension.  It's not a big change, but it would definitely be a difficult one to get right.  My guess is that 0-RTT accounts for about half of the complexity of TLS 1.3 in our stack.  0-RTT in QUIC is relatively easy once TLS has it (it only took me a few hours to implement, from memory).

> might not be using QUIC 0-RTT with the openssl TLS stack at all.

0-RTT is a feature that isn't uniformly supported (I don't think that Google implementations have support yet, though I could be wrong).  It's in Firefox and awesome though.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 Jan 2021 22:26:37 -0800

> Sorry, ... if the functions in the update alter the operation of the core protocol in ways that the core protocol does not anticipate or allow.

Okay, thanks.  8446 doesn't anticipate changes to EndOfEarlyData for
TCP+TLS, but this is ... not that.

> For TLS extensions can (and have) changed all sorts of stuff.

It has not always gone smoothly...

Anyway, I propose that we proceed with your suggestion of (roughly)
"including the 'quic_transport_parameters' extension in EncryptedExtensions
suppresses the requirement to send EndOfEarlyData otherwise implied by
sending 'early_data' in EncryptedExtensions".

> I was largely referring to the TLS internals that would change if early data was conditioned on a second extension.  It's not a big change, but it would definitely be a difficult one to get right.…

It seems like only QUIC internals would have to change, not TLS internals?

My expectation is roughly that, if we were to compare the work needed to go
from (has TLS 1.3 implementation) to (has QUIC implementation that uses
quic_early_data instead of early_data) with the work needed to go from (has
TLS 1.3 implementation) to (has QUIC implementation as currently
specified), there would not be much difference.  Obviously if you are
starting from (has QUIC implementation as currently specified), things are
different, especially if you want to be able to support both draft QUIC and
RFC QUIC in the same codebase.  I still think that things are cleaner with
a separate extension and won't involve trying to smush together two things
that are mostly, but not entirely, the same, but I'm not going to hold a
Discuss over it.

> 0-RTT is a feature that isn't uniformly supported (I don't think that Google implementations have support yet, though I could be wrong).  It's in Firefox and awesome though.

My data from a couple months ago is that google does QUIC 0-RTT but not TLS
0-RTT, if I'm reading my notes properly.

-Ben

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 7 Jan 2021 16:14:05 +0100

> On 7 Jan 2021, at 07.26, Benjamin Kaduk <[email-masked]> wrote:
> 

The concern is also the QUIC v1 uses TLS 1.3 but QUIC as a concept is not heavily tied to a specific crypto paradigm. TLS 1.3 provides the handshake and the transport keys, but QUIC handles all of its own session encryption with or without help from a TLS library. On a practical level this can also helps performance optimizations in software and in hardware.

From a TLS perspective it may seem reasonable to use the designed feature set, but from a QUIC perspective, QUIC does not necessarily benefit from a tight coupling as long as it can get the keys that it needs. This separation makes it simpler to evolve new versions of QUIC with different crypto designs.

For example, a given TLS library might not support many-core optimizations and this also isn’t critical for obtaining traffic keys, but a large volume of early data could be processed on 24 separate cores in parallel. Getting that to work with any run of the mill TLS library could be a challenge.

Mikkel

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 8 Jan 2021 12:52:33 -0600

For what it's worth,

On Thu, Jan 7, 2021 at 9:15 AM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> The concern is also the QUIC v1 uses TLS 1.3 but QUIC as a concept is not
> heavily tied to a specific crypto paradigm. TLS 1.3 provides the handshake
> and the transport keys, but QUIC handles all of its own session encryption
> with or without help from a TLS library. On a practical level this can also
> helps performance optimizations in software and in hardware.
>

I asked about how closely QUIC would be tied to TLS 1.3 during charter
discussions, and the answer I got then was that most of what would keep
QUIC tied to TLS 1.3 was that the security people who replied weren't
expecting any replacement for TLS 1.3 anytime soon. So this was a case of
QUIC using the only handshake that made sense, not the only handshake that
could work.

So I'm agreeing with Mikkel here.

Best,

Spencer

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 8 Jan 2021 11:27:54 -0800

Hi Mikkel,

I suspect I'm misunderstanding something, because it sounds to me like you
are supporting a dedicated "quic_early_data" extension to help decouple QUIC
from TLS.  More inline...

> The concern is also the QUIC v1 uses TLS 1.3 but QUIC as a concept is not heavily tied to a specific crypto paradigm. TLS 1.3 provides the handshake and the transport keys, but QUIC handles all of…

Yes.  This is what I mean by QUIC 0-RTT and TLS 0-RTT being different --
TLS provides keys, but the actual data handling is done by QUIC.  Using the
TLS mechanism to negotiate TLS early data as an indication that QUIC early
data should be used seems to needlessly couple TLS and QUIC for little
gain.

> For example, a given TLS library might not support many-core optimizations and this also isn’t critical for obtaining traffic keys, but a large volume of early data could be processed on 24 separat…

This just seems to be reconfirming that TLS only provides keys to QUIC but
doesn't do any of the bulk-data-handling work.  So a flag that tells TLS
"give me QUIC 0-RTT keys" would work just fine, and there's no reason to
make it be the same flag that says "do TLS 0-RTT".

-Ben