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

[Eric Rescorla <[e-mail]>]

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

> 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.


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