Subject: [quicwg/base-drafts] Remove EOED v2 (#1798)

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 11:20:19 -0700

Just so we have options.

As suggested by @kazuho.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1798

-- Commit Summary --

  * Remove EndOfEarlyData from TLS
  * CRYPTO can't appear at 0-RTT any more
  * Discarding 0-RTT keys is more complicated now
  * Don't allow this with TCP
  * Snafu regarding 0-RTT and handshake interleaving
  * Don't tie EOED removal to the extension

-- File Changes --

    M draft-ietf-quic-tls.md (48)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1798.patch
https://github.com/quicwg/base-drafts/pull/1798.diff

-- 
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/pull/1798

---

From: ianswett <[email-masked]>
Date: Tue, 25 Sep 2018 12:59:54 -0700

ianswett commented on this pull request.

Some small suggestions that may apply to the other PR as well.

> @@ -656,13 +655,14 @@ all the acknowledgements necessary to reach the same state.
 
 After all CRYPTO frames for a given encryption level have been sent and all
 expected CRYPTO frames received, and all the corresponding acknowledgments have
-been received or sent, an endpoint starts a timer.  To limit the effect of
-packet loss around a change in keys, endpoints MUST retain packet protection
-keys for that encryption level for at least three times the current
-Retransmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}.
-Retaining keys for this interval allows packets containing CRYPTO or ACK frames
-at that encryption level to be sent if packets are determined to be lost or new
-packets require acknowledgment.
+been received or sent, an endpoint starts a timer.  For 0-RTT keys, which do not
+carry CRYPTO frames, this timer starts when the first packets protected with

The 0-RTT timer can be much more aggressive than 3 * RTO, since nothing now ever needs to be retransmitted at 0-RTT, it can always be sent with 1-RTT keys instead.

> @@ -656,13 +655,14 @@ all the acknowledgements necessary to reach the same state.
 
 After all CRYPTO frames for a given encryption level have been sent and all
 expected CRYPTO frames received, and all the corresponding acknowledgments have
-been received or sent, an endpoint starts a timer.  To limit the effect of
-packet loss around a change in keys, endpoints MUST retain packet protection
-keys for that encryption level for at least three times the current
-Retransmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}.
-Retaining keys for this interval allows packets containing CRYPTO or ACK frames
-at that encryption level to be sent if packets are determined to be lost or new
-packets require acknowledgment.
+been received or sent, an endpoint starts a timer.  For 0-RTT keys, which do not
+carry CRYPTO frames, this timer starts when the first packets protected with
+1-RTT are sent or received.  To limit the effect of packet loss around a change
+in keys, endpoints MUST retain packet protection keys for that encryption level
+for at least three times the current Retransmission Timeout (RTO) interval as
+defined in {{QUIC-RECOVERY}}.  Retaining keys for this interval allows packets

I think the key goal here is allowing retransmitted CRYPTO data to be acknowledged with the correct encryption level?

-- 
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/pull/1798#pullrequestreview-158718706

---

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

martinthomson commented on this pull request.

I don't think that we need to special case that - as we agreed, there are optimizations that are possible, but we don't need to describe them.  The trick here is that the sender/client might stop using 0-RTT, but the receiver/server can't as easily.

-- 
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/pull/1798#discussion_r220377101

---

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

That's part of it, but the reordering thing matters more for key updates.  I'd prefer to fix this separately, if that's OK.

-- 
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/pull/1798#discussion_r220377275

---

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

Merged #1798 into master.

-- 
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/pull/1798#event-1867031586