Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT)

[Martin Thomson <[e-mail]>]

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.

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.

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

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

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

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.

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.