Re: [quicwg/base-drafts] Make EOED transmission optional in QUIC, please (#1518)

[David Benjamin <[e-mail]>]

Prior to it being a handshake message, we had an end_of_early_data *alert* and a KeyUpdate *message*. This combination was kind of weird, and since other post-handshake messages exist, so the application record processor must already account for handshake message interrupts, making it a message was simpler. Thus it was made a message for consistency. Messages during the handshake go into the transcript, so in it went. That resulted in a happy accident in stopping servers from breaking streaming 0-RTT, so that all worked well. (Before the change, folks kept trying to read 0-RTT data and *then* decide whether to accept early data, without realizing that [is forbidden and deadlocks](https://tools.ietf.org/html/rfc8446#section-4.2.11.3). Putting it in the transcript orders early data processing after ServerHello, which makes the processing order implicitly clear.)

Neither of these considerations apply to QUIC, and then handshake transcript trivially remains injective with it removed, so removing it seems plausible, and it sounds like it's complicating things a lot. At the same time, QUIC should avoid unnecessary modifications to TLS to keep abstractions clear, so the bar for such tweaks must be high. Otherwise TLS and QUIC will not be able to evolve independently.

(Which of these two considerations is stronger in this case, I don't have particular opinions. It does not sound frivolous, but I don't know enough about QUIC to judge how un-frivolous it is.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1518#issuecomment-417798551