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

[Benjamin Kaduk <[e-mail]>]

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.