@kaduk said:

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