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

From: Christian Huitema <[email-masked]>
Date: Sat, 01 Sep 2018 10:27:06 -0700

@davidben if I understand correctly, the main issue is then compatibility with the existing TLS implementations. They expect the EOED to be received before the first handshake message. 

For me the simplest way to achieve that without changing the TLS stack would be to carry the EOED data in the handshake packet rather than the 0-RTT packet, and then deliver it to the TLS stack while pretending that it was carried with 0-RTT encryption. The added cost is a new frame type, but then I could remove all the warts about retransmitting 0-RTT data sometimes as 1-RTT and sometimes as 0-RTT.

Even simpler of course would be a TLS API option to "not bother with EOED when running over a datagram transport". That would remove all the EOED warts in the QUIC code. It would add some of them back in the TLS code, but probably at a much lower cost. 

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

---

From: David Benjamin <[email-masked]>
Date: Sat, 01 Sep 2018 11:00:15 -0700

Right, I'm assuming that, given the rest of the stream zero business, the TLS stack will need modifications anyway, at which point it is perfectly capable of the occasional tweak for QUIC.

I wouldn't want to have too many of these and obviously you especially shouldn't change something substantial that would break analysis or future TLS extensions, but EndOfEarlyData seems unlikely to matter much. (Famous last words...)

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

---

From: ekr <[email-masked]>
Date: Sat, 01 Sep 2018 11:21:30 -0700

I don't think the main issue is compatibility with the existing TLS implementations but rather (a) having consistency with TLS and (b) reasoning about the security properties of the protocol. From this perspective, carrying it in handshake encryption is quite bad, because it's a big change that's hard to reason about.

However, even in a datagram protocol removing EOED does change those properties: EOED tells you that you will not receive messages with 0-RTT keys but with greater PNs. It's not clear if that property is important, but we should try to actually reason about it (this applies to DTLS as well, I imagine).

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

---

From: ekr <[email-masked]>
Date: Sat, 01 Sep 2018 11:26:21 -0700

Just to follow up on this point, removing EOED does allow a weak extension attack against data in the 0-RTT epoch. Consider the case where the client (a) sends EOED  and then (b) is compromised. Under these conditions an attacker will be able to send data which will appear to the server to be in 0-RTT. As I say, this is quite a weak attack because (a) the client could just delete the 0-RTT keys and (b) the attacker would presumably be able to instead send 1-RTT data instead. But it is a change in the properties of the system.

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

---

From: ianswett <[email-masked]>
Date: Sun, 02 Sep 2018 13:42:27 -0700

@ekr: I don't think "EOED tells you that you will not receive messages with 0-RTT keys but with greater PNs." is providing much, since if EOED is lost, the receiver will continue to process 0RTT packets with higher packet numbers.

Also, you have to continue processing these 0RTT packets long after EOED has been initially received, because the sender of EOED may not know EOED has been received.

I'd argue in QUIC EOED is actually telling you very little, and I tend to think it's inclusion is more harmful than helpful.  It requires keeping 0RTT keys around and continue processing them for longer.  Without EOED, you can stop processing 0RTT packets once a single packet is received with 1RTT encryption, which seems like a much stronger signal.

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

---

From: ekr <[email-masked]>
Date: Sun, 02 Sep 2018 14:27:16 -0700

1. Yes, the receiver will continue to process them if EOED is lost. That's why you retransmit them.
2. You don't have to continue processing higher-numbered 0-RTT packets after EOED is received because the client will never send them.
3. You can't stop processing 0RTT packets once a single packet is received in epoch 3 unless you want gaps due to reordering.

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

---

From: Christian Huitema <[email-masked]>
Date: Sun, 02 Sep 2018 14:40:18 -0700

We do not have a rule in the transport draft that says that clients shall stop sending more 0-RTT packets after EOED has been sent. The separation between transport and TLS prevents that. The TLS stack at some points tells the client to "please forward these bytes on the epoch=1 crypto stream". The client does not know what the bytes mean. It has no concept of EOED.

Of course, we could introduce an extra synchronization between the transport and the TLS stack. The transport could tell the TLS stack that it has sent all the queued 0-RTT packets. Or the TLS stack could somehow signal to the transport that it should not send any more 0-RTT packets -- except of course for those 0-RTT packets required to send TLS messages, or to repeat them if no ACK arrives. I am definitely not suggesting that we do anything like that.

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

---

From: ekr <[email-masked]>
Date: Sun, 02 Sep 2018 14:55:19 -0700

After EOED is sent, the TLS stack tells the transport stack that further non-TLS data should be sent with the 1-RTT keys at this point. How did you think that the transition happened other than that?

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

---

From: ekr <[email-masked]>
Date: Sun, 02 Sep 2018 14:56:37 -0700

This is shown in Figure 3 of the TLS draft, though perhaps some more text is required.

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

---

From: MikkelFJ <[email-masked]>
Date: Sun, 02 Sep 2018 15:05:14 -0700

> 2. You don't have to continue processing higher-numbered 0-RTT packets after EOED is received because the client will never send them.

I don't get all the details of this but would you exepct higher numbered 0-RTT transmissions after EOED if there are retransmissions and EOED packet hasn't been acked.

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

---

From: ianswett <[email-masked]>
Date: Sun, 02 Sep 2018 15:11:06 -0700

Re #2, it it possible the client misses an acknowledgement of the EOED.  If this happens, we either need to rely on implicit acknowledgement, which we've avoided so far, or the client retransmitting EOED and the server ACKing it.  Or never stop ACKing EOED until you know it's been received, but that seems more complex?

Re #3, I had higher numbered packets in mind, due to reordering.  But this seems very similar to how changing key phases would work, which matches my mental model of the 0RTT to 1RTT transition.

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

---

From: ekr <[email-masked]>
Date: Sun, 02 Sep 2018 16:01:05 -0700

(2) Ian, sorry, yes, I meant just application data.
(3) Hmm... I was thinking these were separate sequence number spaces like in DTLS, but I guess they're the same, so maybe you're right. I'll have to think about that.

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

---

From: Christian Huitema <[email-masked]>
Date: Sun, 02 Sep 2018 17:55:28 -0700

@ekr You write that "_After EOED is sent, the TLS stack tells the transport stack that further non-TLS data should be sent with the 1-RTT keys at this point_." I don't know for other stacks, but there is no such signal with Picotls. That API provides signals such as "expecting data from epoch X", "Here is data to send on epoch Y", "here is the write (or read) key for epoch X" and "all done". The signal "here is the write key for epoch 3" does not double as "and please stop sending on epoch 1". It cannot, because the epoch 1 crypto stream still has to be transmitted and acknowledged.

We could also have an interesting discussion about stream frames carried in the same 0-RTT packet as crypto frames. Should we have a different treatment depending on whether the stream frame is carried before or after the crypt frame in the packet?

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

---

From: ekr <[email-masked]>
Date: Sun, 02 Sep 2018 18:03:28 -0700

Well, you certainly need some signal that says "send application data in epoch 3". What is that signal?

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

---

From: Christian Huitema <[email-masked]>
Date: Sun, 02 Sep 2018 18:48:53 -0700

There is no explicit signal, but it is very much assumed that if the TLS stack provides the transport with the write key for epoch 3, then application data will be sent that way. I read again the QUIC/TLS draft, and I could not find a statement saying that application data MUST NOT be sent as 0-RTT if the 1-RTT key is available. But in fact, that's the whole point of this thread. If it were not for the transmission of EOED over 0-RTT, the transport could simply just discard the 0-RTT write keys when the 1-RTT write keys become available. I would very much like to be able to do that.

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

---

From: Victor Vasiliev <[email-masked]>
Date: Sun, 02 Sep 2018 20:41:58 -0700

> I don't think the main issue is compatibility with the existing TLS implementations but rather (a) having consistency with TLS

The point I was trying to make is that EOED is not logically part of TLS handshake protection (which we're trying to preserve in order to rely on security properties proven in multiple analyses), but rather of TLS record layer.  We're pretty much rolling our own record layer, which means it befalls on us to ensure its security ourselves.  That does not itself mean we should drop EOED by itself, merely that we actually *have* to decide something without pointing fingers to TLS 1.3 :)

Regarding your attack, if you're concerned about 0-RTT keys being compromised after EOED, wouldn't you want to drop them as soon as possible?  As it stands, the client can't do it because it has to hold onto them for retransmitting EOED.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 15:35:00 -0700

Closed #1518 via #1792.

-- 
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#event-1867031676