Merge pull request #337 from quicwg/unprotect_client_finished

The client Finished message can't be protected with 1-RTT keys

Author: seanturner

draft-ietf-quic-tls.md

@@ -317,7 +317,7 @@ ensures that TLS handshake messages are delivered in the correct order.
 
                                            QUIC Frames <any> @1
                             <--------
-@1 QUIC STREAM Frame(s) <1>:
+@C QUIC STREAM Frame(s) <1>:
      (EndOfEarlyData)
      {Finished}
                             -------->
@@ -337,7 +337,7 @@ In {{quic-tls-handshake}}, symbols mean:
 
 If 0-RTT is not attempted, then the client does not send packets protected by
 the 0-RTT key (@0).  In that case, the only key transition on the client is from
-unprotected packets (@C) to 1-RTT protection (@1), which happens before it sends
+unprotected packets (@C) to 1-RTT protection (@1), which happens after it sends
 its final set of TLS handshake messages.
 
 The server sends TLS handshake messages without protection (@C).  The server
@@ -350,7 +350,7 @@ QUIC.  QUIC packets from the server are sent in the clear until the final
 transition to 1-RTT keys.
 
 The client transitions from cleartext (@C) to 0-RTT keys (@0) when sending 0-RTT
-data, and subsequently to to 1-RTT keys (@1) for its second flight of TLS
+data, and subsequently to to 1-RTT keys (@1) after its second flight of TLS
 handshake messages.  This creates the potential for unprotected packets to be
 received by a server in close proximity to packets that are protected with 1-RTT
 keys.
@@ -460,14 +460,14 @@ TLS provides QUIC with signals when 0-RTT and 1-RTT keys are ready for use.
 These events are not asynchronous, they always occur immediately after TLS is
 provided with new handshake octets, or after TLS produces handshake octets.
 
-When TLS has enough information to generate 1-RTT keys, it indicates their
-availability.  On the client, this occurs after receiving the entirety of the
-first flight of TLS handshake messages from the server.  A server indicates that
-1-RTT keys are available after it sends its handshake messages.
+When TLS completed its handshake, 1-RTT keys can be provided to QUIC.  On both
+client and server, this occurs after sending the TLS Finished message.
 
-This ordering ensures that a client sends its second flight of handshake
-messages protected with 1-RTT keys.  More importantly, it ensures that the
-server sends its flight of handshake messages without protection.
+This ordering means that there could be frames that carry TLS handshake messages
+ready to send at the same time that application data is available.  An
+implementation MUST ensure that TLS handshake messages are always sent in
+cleartext packets.  Separate packets are required for data that needs protection
+from 1-RTT keys.
 
 If 0-RTT is possible, it is ready after the client sends a TLS ClientHello
 message or the server receives that message.  After providing a QUIC client with
@@ -501,9 +501,9 @@ Get Handshake
                                                 1-RTT Keys Ready
                      <--- send/receive ---
 Handshake Received
-1-RTT Keys Ready
 Get Handshake
 Handshake Complete
+1-RTT Keys Ready
                       --- send/receive --->
                                               Handshake Received
                                                    Get Handshake
@@ -648,8 +648,8 @@ packets sent by the client.
 
 1-RTT keys are used by both client and server after the TLS handshake completes.
 There are two secrets used at any time: one is used to derive packet protection
-keys for packets sent by the client, the other for protecting packets sent by
-the server.
+keys for packets sent by the client, the other for packet protection keys on
+packets sent by the server.
 
 The initial client packet protection secret is exported from TLS using the
 exporter label "EXPORTER-QUIC client 1-RTT Secret"; the initial server packet
@@ -840,19 +840,15 @@ ensure that TLS handshake messages are sent with the correct packet protection.
 The initial exchange of packets are sent without protection.  These packets are
 marked with a KEY_PHASE of 0.
 
-TLS handshake messages that are critical to the TLS key exchange cannot be
-protected using QUIC packet protection.  A KEY_PHASE of 0 is used for all of
-these packets, even during retransmission.  The messages critical to key
-exchange are the TLS ClientHello and any TLS handshake message from the server,
-except those that are sent after the handshake completes, such as
-NewSessionTicket.
+TLS handshake messages MUST NOT be protected using QUIC packet protection.  A
+KEY_PHASE of 0 is used for all of these packets, even during retransmission.
+The messages affected are all TLS handshake message up to the TLS Finished that
+is sent by each endpoint.
 
-The second flight of TLS handshake messages from the client, and any TLS
-handshake messages that are sent after completing the TLS handshake do not need
-special packet protection rules.  This includes the EndOfEarlyData message that
-is sent by a client to mark the end of its 0-RTT data.  Packets containing these
-messages use the packet protection keys that are current at the time of sending
-(or retransmission).
+Any TLS handshake messages that are sent after completing the TLS handshake do
+not need special packet protection rules.  Packets containing these messages use
+the packet protection keys that are current at the time of sending (or
+retransmission).
 
 Like the client, a server MUST send retransmissions of its unprotected handshake
 messages or acknowledgments for unprotected handshake messages sent by the
@@ -861,27 +857,25 @@ client in unprotected packets (KEY_PHASE=0).
 
 ### Initial Key Transitions {#first-keys}
 
-Once the TLS key exchange is complete, keying material is exported from TLS and
+Once the TLS handshake is complete, keying material is exported from TLS and
 QUIC packet protection commences.
 
 Packets protected with 1-RTT keys have a KEY_PHASE bit set to 1.  These packets
 also have a VERSION bit set to 0.
 
-If the client is unable to send 0-RTT data - or it does not have 0-RTT data to
-send - packet protection with 1-RTT keys starts with the packets that contain
-its second flight of TLS handshake messages.  That is, the flight containing the
-TLS Finished handshake message and optionally a Certificate and
-CertificateVerify message.
-
 If the client sends 0-RTT data, it marks packets protected with 0-RTT keys with
 a KEY_PHASE of 1 and a VERSION bit of 1.  Setting the version bit means that all
-packets also include the version field.  The client removes the VERSION bit when
-it transitions to using 1-RTT keys, but it does not change the KEY_PHASE bit.
+packets also include the version field.  The client retains the VERSION bit, but
+reverts the KEY_PHASE bit for the packet that contains the TLS EndOfEarlyData
+and Finished messages.
+
+The client clears the VERSION bit and sets the KEY_PHASE bit to 1 when it
+transitions to using 1-RTT keys.
 
 Marking 0-RTT data with the both KEY_PHASE and VERSION bits ensures that the
-server is able to identify these packets as 0-RTT data in case the packet
-containing the TLS ClientHello is lost or delayed.  Including the version also
-ensures that the packet format is known to the server in this case.
+server is able to identify these packets as 0-RTT data in case packets
+containing TLS handshake message are lost or delayed.  Including the version
+also ensures that the packet format is known to the server in this case.
 
 Using both KEY_PHASE and VERSION also ensures that the server is able to
 distinguish between cleartext handshake packets (KEY_PHASE=0, VERSION=1), 0-RTT
@@ -905,26 +899,16 @@ KEY_PHASE of 1.
 
 ### Retransmission and Acknowledgment of Unprotected Packets
 
-The first flight of TLS handshake messages from both client and server
-(ClientHello, or ServerHello through to the server's Finished) are critical to
-the key exchange.  The contents of these messages determines the keys used to
-protect later messages.  If these handshake messages are included in packets
-that are protected with these keys, they will be indecipherable to the
-recipient.
+TLS handshake messages from both client and server are critical to the key
+exchange.  The contents of these messages determines the keys used to protect
+later messages.  If these handshake messages are included in packets that are
+protected with these keys, they will be indecipherable to the recipient.
 
 Even though newer keys could be available when retranmitting, retransmissions of
 these handshake messages MUST be sent in unprotected packets (with a KEY_PHASE
 of 0).  An endpoint MUST also generate ACK frames for these messages that are
 sent in unprotected packets.
 
-The TLS handshake messages that are affected by this rule are specifically:
-
-* A client MUST NOT restransmit a TLS ClientHello with 0-RTT keys.  The server
-  needs this message in order to determine the 0-RTT keys.
-
-* A server MUST NOT retransmit any of its TLS handshake messages with 1-RTT
-  keys.  The client needs these messages in order to determine the 1-RTT keys.
-
 A HelloRetryRequest handshake message might be used to reject an initial
 ClientHello.  A HelloRetryRequest handshake message and any second ClientHello
 that is sent in response MUST also be sent without packet protection.  This is
@@ -933,12 +917,6 @@ need to be sent.  Upon receipt of a HelloRetryRequest, a client SHOULD cease any
 transmission of 0-RTT data; 0-RTT data will only be discarded by any server that
 sends a HelloRetryRequest.
 
-Note:
-
-: TLS handshake data that needs to be sent without protection is all the
-  handshake data acquired from TLS before the point that 1-RTT keys are provided
-  by TLS (see {{key-ready-events}}).
-
 The KEY_PHASE and VERSION bits ensure that protected packets are clearly
 distinguished from unprotected packets.  Loss or reordering might cause
 unprotected packets to arrive once 1-RTT keys are in use, unprotected packets