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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> +The KEY_PHASE bit on the public flags is the most significant bit (0x80).
+{{key-phase-table}} summarizes the different values for the KEY_PHASE bit.
+
+| Scenario | Client (No 0-RTT) | Client (0-RTT) | Server |
+|:-|-:|-:|-:|
+| Handshake | 0 | 0 |  0 |
+| 0-RTT Data | - | 1 | - |
+| 1-RTT Data | 1 | 0 | 1 |
+| 1st Key Update | 0 | 1 | 0 |
+| 2nd Key Update | 1 | 0 | 1 |
+{: #key-phase-table title="Summary of KEY_PHASE Values"}
+
+{{key-phase-table}} shows that a client marks 1-RTT with a different KEY_PHASE
+bit depending on whether 0-RTT is attempted.  Attempting 0-RTT therefore results
+in fully protected data having different KEY_PHASE values.  This is true even if
+0-RTT data is rejected and ignored by the server.

I think that we might want to use the version bit for disambiguation.

0-RTT going missing isn't a big deal.  A server that receives 1-RTT encrypted data must have 1-RTT keys AND it doesn't need to receive any more cleartext handshake messages (it must have read the ClientHello in order to have responded to it).  Thus, the only catch is with unprotected ACK frames that arrive late.  I go into this in more detail further down.

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