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

From: ianswett <[email-masked]>
Date: Tue, 14 Aug 2018 15:35:50 -0700

My current thinking is that we should make it QUIC v2 and try to convince someone to spend the time to do the correctness proofs in that timeframe, so we don't need this forever, and possibly prove we don't need CFIN as well.  And whatever other warts we have discovered in this process.

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 14 Aug 2018 23:20:48 +0000 (UTC)

@ianswett You can certainly live with warts for sometimes, if they don't start metastasis...

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

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 31 Aug 2018 11:45:47 -0700

I'm not sure I agree with the "correctness proof" argument.  EndOfEarlyData exists to protect against truncation attacks on 0-RTT data; as such, it's a part of record layer, not handshake layer.  In fact, it did not go into transcript before draft19, so most papers cited for handshake analysis in the RFC do not mention it (out of those that do, the INRIA/MSR analysis treats it as a record layer entity, and _TLS 1.3 in Tamarin_ explicitly states it does not model it at all).

Given that this is unnecessary and adds bunch of complex and ugly logic, I think we should remove this.

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

---

From: David Benjamin <[email-masked]>
Date: Fri, 31 Aug 2018 14:52:30 -0700

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