Subject: Re: [quicwg/base-drafts] Improve KEY_PHASE description (#43)

From: Dragana Damjanovic <[email-masked]>
Date: Thu, 08 Dec 2016 12:08:18 -0800

ddragana commented on this pull request.

> +decrypt these packets, which will be unsuccessful.  Though a server that has
+1-RTT keys can safely discard any unprotected handshake messages from the
+client, an unprotected ACK frame could indicate that the server needs to
+retransmit its own handshake messages.  ACK frames therefore cannot be
+discarded.
+
+Until the server has received a positive acknowledgment for all of its
+unprotected handshake messages, either in the form of an explicit acknowledgment
+or implicitly through the use of 1-RTT keys, it MUST NOT discard packets with a
+KEY_PHASE of 0 if they cannot be decrypted successfully.  If these packets are
+unprotected and contain ACK frames, those ACK frames MUST be recovered and used
+to determine whether to retransmit TLS handshake messages.
+
+TBD:
+
+: We could observe/require that all unprotected packets are marked with a

I would suggest to have VERSION bit set not only for unprotected packets but for 0RTT encrypted packets as well. For 2 reasons:
1)VERSION number tells the server how to interpreter packet, so if ClientHello packet gets lost and server receives 0RTT encrypted packet it will not know how to read it because it does not know which protocol version it is. (if we do not change the packet format for different version it might be ok, but we do not want to ossify on this). In that case it would need to wait for ClientHello and it will not be able to send acks to trigger retransmits, the version change request from server will be delayed,etc.
2) we can remove asymmetry: unprotected packet have KEY_PHASE=0 and VERSION=1, 0RTT packets have KEY_PHASE=1 and VERSION=1 and 1RTT packet have KEY_PHASE=1 and VERSION=0 (which will be the same on the server side and the same as the case when 0RTT is not used)

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 08 Dec 2016 19:08:34 -0800

martinthomson commented on this pull request.

I like this logic.  I will make that change.

I suspect that servers will likely have very different tolerances for 0-RTT packets, particularly in the absence of the ClientHello. The ClientHello will probably be the only place that we can put a source address validation token.

---

From: ianswett <[email-masked]>
Date: Fri, 09 Dec 2016 03:49:42 -0800

ianswett commented on this pull request.

Agreed, let's go with this.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Dec 2016 15:58:48 -0800

Merged #43.

-- 
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/43#event-889097740