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

From: Christian Huitema <[email-masked]>
Date: Tue, 03 Jul 2018 20:16:38 -0700

The TLS spec seems to imply that the End Of Early Data (EOED) message, if required, should be protected and transmitted as 0-RTT data.  I found that when implementing the draft-13 spec, and it was somewhat of a surprise. I understand the willingness to exactly parallel TLS 1.3 behavior of TCP, but it is weird when packets are sent as UDP datagrams.

The weirdest part is probably the retransmission behavior. 0-RTT packets are only acked by 1-RTT packets. Stream frames in 0-RTT packets are resent in 1-RTT packets. For correct behavior, we must guarantee that it is received before the Client Finished message. What are implementers supposed to do? Put a huge wart in the retransmission control?

It would be much simpler to not require an EOED message for Quic. EOED is not really functional, since 0-RTT packets are not processed through the TLS stack. 0-RTT and 1-RTT packets are in the same sequence space, there is no need for a demarcation. It is just one of those hazing things that are imposed on developers.

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

---

From: ekr <[email-masked]>
Date: Tue, 03 Jul 2018 20:46:47 -0700

On Tue, Jul 3, 2018 at 8:16 PM, Christian Huitema <[email-masked]>
wrote:

> The TLS spec seems to imply that the End Of Early Data (EOED) message, if
> required, should be protected and transmitted as 0-RTT data.
>

Yes. All messages are transmitted in the same epochs they would be in TLS
1.3.

I found that when implementing the draft-13 spec, and it was somewhat of a
> surprise. I understand the willingness to exactly parallel TLS 1.3 behavior
> of TCP, but it is weird when packets are sent as UDP datagrams.
>
> The weirdest part is probably the retransmission behavior. 0-RTT packets
> are only acked by 1-RTT packets. Stream frames in 0-RTT packets are resent
> in 1-RTT packets. For correct behavior, we must guarantee that it is
> received before the Client Finished message. What are implementers supposed
> to do? Put a huge wart in the retransmission control?
>
Well, EOED isn't a stream frame, so I don't think it's actually that
complicated to implement this. I think it's more important to keep the TLS
1.3 state machine intact.

-Ekr

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 03 Jul 2018 21:11:52 -0700

It really depends how you deal with retransmissions. In my code it is a huge pain. Of course I can find some contorted way to deal with it. But I hate that kind of stuff.

As for the TLS 1.3 state machine, what does the EOED actually achieve? You cannot clear the 0-RTT encryption context until you are sure that all 0-RTT datagrams have been received. Do you just want to prove that the client could exercise the 0-RTT key?

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Jul 2018 23:26:35 -0700

I'm not sure that I understand how this is difficult.  How is it different to - for example - CRYPTO frames in Handshake packets?

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 04 Jul 2018 08:25:00 -0700

The difference is that handshake packets are acknowledged immediately. 0-RTT packets are only acknowledged by 1-RTT packets. The computation of timers is different, per the recovery draft, with handshake packets acked asap, and 0-RTT packets acked leisurely, as data. For example, the recovery draft says: 
```
 3.5.7.1. Handshake Alarm

When a connection has unacknowledged handshake data, the handshake alarm is set and when it expires, all unacknowledgedd handshake data is retransmitted.
```
To this naive reader, "handshake packets" means packets of type Initial or Handshake, not 0-RTT. What I have to implement is "also retransmit those 0-RTT packets that contain Crypto Stream data". Or something similar.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Jul 2018 17:39:35 -0700

It says "handshake data", which is correct, if perhaps a little too easy to mistake for "Handshake packets".

Acknowledging promptly is primarily an optimization.  It should still work with the leisurely timers.  My naive assumption was that when you process a CRYPTO frame you would cut the ack delay timer.  That gets you a pretty good approximation of the right behaviour, even if that also means that NewSessionTicket forces more aggressive acknowledgment than necessary (for which you could condition on the packet protection level if you cared).

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

---

From: ianswett <[email-masked]>
Date: Mon, 09 Jul 2018 08:35:50 -0700

I agree with Christian, this is a pain and an ugly special case, since everything else sent in 0RTT can be retransmitted in 1RTT.

I think this is a case where the stream 0 QUIC record layer design should make EOED unnecessary.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 11 Jul 2018 17:05:26 -0700

I do not think that the requirement to send EOED using a 0-RTT packet is complex enough to justify the changes to the TLS handshake transcript.

My understanding is that TLS stacks emits EOED when 1-RTT write key becomes available (otherwise in TLS over TCP a client will have a moment when it cannot send any data, which is silly). 1-RTT read key will be available at that moment, so you can always be certain that you can receive an ACK for EOED.

In other words, retransmission is not an issue.

Note also that clients have the freedom to continue retransmitting 0-RTT packets with application data even after receiving the 1-RTT write key. That is what TLS over TCP exactly does.

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 12 Jul 2018 17:09:51 -0700

@kazuho can you expand a bit the argument about "the changes to the TLS handshake transcript"? Are you concerned about reusing the TLS code as is, or about not invalidating the results of the TLS1.3 correctness proofs?

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Jul 2018 17:14:41 -0700

@huitema The latter.

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