Rewrite key update section

This makes some significant editorial changes to the key update section,
hopefully making the various activities clearer and more explicit.

In the process, I am also trying to address #2792, which is the timing
sidechannel created by having the generation of updated keys inline with
packet processing.  In doing so, I'm suggesting that endpoints create
the next keys at some time after the key update happens.  Right now, I'm
thinking 1-2 PTOs is probably close enough to workable.  I've limited
this at 3PTO.  This is, however, just a (firm) suggestion at this stage.

For endpoints that only want to keep 2 sets of keys, this is probably
the right time frame, especially if we keep the current advice for 3PTO
before a subsequent update.

The effect of this is that attempts to update at certain times could
cause all packets after the update to be discarded.  That would only
happen if implementations consistently ignored advice on update
frequency, so I think that's tolerable, but I'd like input on this.

(This also attempts to take up the advice from the other, older PRs on
this subject.)

Closes #2792, #2791, #2237.

Author: martinthomson

draft-ietf-quic-tls.md

@@ -1168,89 +1168,232 @@ anticipation of receiving a ClientHello.
 
 # Key Update
 
-Once the handshake is confirmed, it is possible to update the keys. The
-KEY_PHASE bit in the short header is used to indicate whether key updates
-have occurred. The KEY_PHASE bit is initially set to 0 and then inverted
-with each key update.
+Once the 1-RTT keys are established and confirmed, it is possible to update the
+keys used to protect packets.
 
-The KEY_PHASE bit allows a recipient to detect a change in keying material
-without necessarily needing to receive the first packet that triggered the
-change.  An endpoint that notices a changed KEY_PHASE bit can update keys and
-decrypt the packet that contains the changed bit.
+The Key Phase bit indicates which packet protection keys are used to protect the
+packet.  The Key Phase bit is initially set to 0 for the first set of 1-RTT
+packets and toggled to signal each subsequent key update.
+
+The Key Phase bit allows a recipient to detect a change in keying material
+without needing to receive the first packet that triggered the change.  An
+endpoint that notices a changed Key Phase bit updates keys and decrypts the
+packet that contains the changed value.
 
 This mechanism replaces the TLS KeyUpdate message.  Endpoints MUST NOT send a
 TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate
 message as a connection error of type 0x10a, equivalent to a fatal TLS alert of
 unexpected_message (see {{tls-errors}}).
 
-An endpoint MUST NOT initiate the first key update until the handshake is
-confirmed ({{handshake-confirmed}}). An endpoint MUST NOT initiate a subsequent
-key update until it has received an acknowledgment for a packet sent at the
-current KEY_PHASE.  This can be implemented by tracking the lowest packet
-number sent with each KEY_PHASE, and the highest acknowledged packet number
-in the 1-RTT space: once the latter is higher than or equal to the former,
-another key update can be initiated.
-
-Endpoints MAY limit the number of keys they retain to two sets for removing
-packet protection and one set for protecting packets.  Older keys can be
-discarded.  Updating keys multiple times rapidly can cause packets to be
-effectively lost if packets are significantly reordered.  Therefore, an
-endpoint SHOULD NOT initiate a key update for some time after it has last
-updated keys; the RECOMMENDED time period is three times the PTO. This avoids
-valid reordered packets being dropped by the peer as a result of the peer
-discarding older keys.
-
-A receiving endpoint detects an update when the KEY_PHASE bit does not match
-what it is expecting.  It creates a new secret (see Section 7.2 of {{!TLS13}})
-and the corresponding read key and IV using the KDF function provided by TLS.
-The header protection key is not updated.
-
-If the packet can be decrypted and authenticated using the updated key and IV,
-then the keys the endpoint uses for packet protection are also updated.  The
-next packet sent by the endpoint MUST then use the new keys.  Once an endpoint
-has sent a packet encrypted with a given key phase, it MUST NOT send a packet
-encrypted with an older key phase.
-
-An endpoint does not always need to send packets when it detects that its peer
-has updated keys.  The next packet that it sends will simply use the new keys.
-If an endpoint detects a second update before it has sent any packets with
-updated keys, it indicates that its peer has updated keys twice without awaiting
-a reciprocal update.  An endpoint MUST treat consecutive key updates as a fatal
-error and abort the connection.
-
-An endpoint SHOULD retain old keys for a period of no more than three times the
-PTO.  After this period, old keys and their corresponding secrets SHOULD be
-discarded.  Retaining keys allow endpoints to process packets that were sent
-with old keys and delayed in the network.  Packets with higher packet numbers
-always use the updated keys and MUST NOT be decrypted with old keys.
-
-This ensures that once the handshake is complete, packets with the same
-KEY_PHASE will have the same packet protection keys, unless there are multiple
-key updates in a short time frame succession and significant packet reordering.
+{{ex-key-update}} shows a key update process, with keys used identified with @M
+cannot be used until the endpoint has received and successfully decrypted a and
+@N.  The value of Key Phase bit is indicated in brackets \[]..
 
 ~~~
    Initiating Peer                    Responding Peer
 
-@M QUIC Frames
-               New Keys -> @N
-@N QUIC Frames
+@M [0] QUIC Packets
+
+... Update to @N
+@N [1] QUIC Packets
                       -------->
-                                          QUIC Frames @M
-                          New Keys -> @N
-                                          QUIC Frames @N
+                                         Update to @N ...
+                                      QUIC Packets [1] @N
+                      <--------
+                                      QUIC Packets [1] @N
+                                    containing ACK
                       <--------
+... Key Update Permitted
+
+@N [1] QUIC Packets
+         containing ACK for @N packets
+                      -------->
+                                 Key Update Permitted ...
 ~~~
 {: #ex-key-update title="Key Update"}
 
-A packet that triggers a key update could arrive after the receiving endpoint
-successfully processed a packet with a higher packet number.  This is only
-possible if there is a key compromise and an attack, or if the peer is
-incorrectly reverting to use of old keys.  Because the latter cannot be
-differentiated from an attack, an endpoint MUST immediately terminate the
-connection if it detects this condition.
 
-In deciding when to update keys, endpoints MUST NOT exceed the limits for use of
-specific keys, as described in Section 5.5 of {{!TLS13}}.
+## Initiating a Key Update {#key-update-initiate}
+
+Endpoints maintain separate read and write secrets for packet protection.  An
+endpoint initiates a key update by updating its packet protection write secret
+and using that to protect new packets.  The endpoint creates a new write secret
+from the existing write secret as performed in Section 7.2 of {{!TLS13}}.  This
+uses the KDF function provided by TLS with a label of "quic ku".  The
+corresponding key and IV are created from that secret as defined in
+{{protection-keys}}.  The header protection key is not updated.
+
+
+The endpoint toggles the value of the Key Phase bit and uses the updated key and
+IV to protect all subsequent packets.
+
+An endpoint MUST NOT initiate a key update prior to having received an
+acknowledgment for a packet that it sent protected with keys from the current
+key phase.  This ensures that keys are available to both peers before another
+can be initiated.
+
+Note:
+
+: Changes in keys from Initial to Handshake and from Handshake to 1-RTT don't
+  use this key update process. Key changes during the handshake are driven
+  solely by changes in the TLS handshake state.
+
+The endpoint that initiates a key update also updates the keys that it uses for
+receiving packets.  These keys will be needed to process packets the peer sends
+after updating.
+
+An endpoint SHOULD retain old keys so that packets sent by its peer prior to
+receiving the key update can be processed.  Discarding old keys too early can
+cause delayed packets to be discarded.  Discarding packets will be interpreted
+as packet loss by the peer and could adversely affect performance.
+
+
+## Responding to a Key Update
+
+Once an endpoint has acknowledged a packet in the current key phase, a peer is
+permitted to initiate a key update.  If a packet is received with a key phase
+that differs from the value the endpoint used to protect the last packet it
+sent, the endpoint uses the next packet protection keys for reading and the
+corresponding key and IV; see {{receive-key-generation}} for considerations
+about generating these keys.
+
+An endpoint uses the same key derivation process as its peer uses to generate
+keys for receiving.
+
+If a packet is successfully processed using the next key and IV, then the peer
+has initiated a key update.  The endpoint MUST updates its send keys to the
+corresponding key phase in response, as described in {{key-update-initiate}}.
+By acknowledging the packet that triggered the key update in a packet protected
+with the updated keys, the endpoint will ultimately signal that the key update
+is complete.
+
+An endpoint can defer sending the packet or acknowledgement according to its
+normal packet sending behaviour; it is not necessary to immediately generate a
+packet in response to a key update.  The next packet sent by the endpoint will
+use the updated keys.  The next packet that contains an acknowledgement will
+cause the key update to be completed.  If an endpoint detects a second update
+before it has sent any packets with updated keys or an acknowledgement for the
+packet that initiated the key update, it indicates that its peer has updated
+keys twice without awaiting confirmation.  An endpoint MAY treat consecutive key
+updates as a connection error of type KEY_UPDATE_ERROR.
+
+An endpoint that receives an acknowledgement that is carried in a packet
+protected with old keys where any acknowledged packet was protected with newer
+keys MAY treat that as a connection error of type KEY_UPDATE_ERROR.  This
+indicates that a peer has received and acknowledged a packet that initiates a
+key update, but has not updated keys in response.
+
+
+## Timing of Receive Key Generation {#receive-key-generation}
+
+Endpoints responding to an apparent key update MUST NOT generate a timing
+side-channel signal that might indicate that the Key Phase bit was invalid (see
+{{header-protect-analysis}}).  Endpoints can use dummy packet protection keys in
+place of discarded keys when key updates are not permitted; using dummy keys
+will generate no variation in the timing signal produced by attempting to remove
+packet protection, but all packets with an invalid Key Phase bit will be
+rejected.
+
+The process of creating new packet protection keys for receiving packets could
+reveal that a key update has occurred.  An endpoint MAY perform this process as
+part of packet processing, but this creates a timing signal that can be used by
+an attacker to learn when key updates happen and thus the value of the Key Phase
+bit in certain packets.  Endpoints SHOULD instead defer the creation of the next
+set of packet protection keys until some time after a key update completes, up
+to three times the PTO; see {{old-keys-recv}}.
+
+Once generated, the next set of packet protection keys SHOULD be retained, even
+if the packet that was received was subsequently discarded.  Packets containing
+apparent key updates are easy to forge and - while the process of key update
+does not require significant effort - triggering this process could be used by
+an attacker for DoS.
+
+For this reason, endpoints MUST be able to retain two sets of packet protection
+keys for receiving packets: the current and the next.  Retaining the previous
+keys in addition to these might improve performance, but this is not essential.
+
+The time taken to generate new keys could reveal through timing side channels
+that a key update has occurred, or where an attacker injects packets, be used to
+reveal the value of the Key Phase on injected packets.  After receiving a key
+update, an endpoint SHOULD generate and save the next set of packet protection
+keys.  After new keys are available, receipt of packets will not create timing
+signals about the value of the Key Phase.
+
+This depends on not doing this generating during packet processing and it can
+require that endpoints maintain three sets of packet protection keys for
+receiving: for the previous key phase, for the current key phase, and for the
+next key phase.  Endpoints MAY choose to defer generation of the next packet
+protection keys until they discard old keys so that only two sets of receive
+keys need to be retained at any point in time.
+
+
+## Sending with Updated Keys {#old-keys-send}
+
+An endpoint always sends packets that are protected with the newest keys.  Keys
+used for adding packet protection can be discarded immediately after switching
+to newer keys.
+
+Packets with higher packet numbers MUST be protected with either the same or
+newer packet protection keys than packets with lower packet numbers.  An
+endpoint that successfully removes protection with old keys when newer keys were
+used for packets with lower packet numbers MUST treat this as a connection error
+of type KEY_UPDATE_ERROR.
+
+
+## Receiving with Different Keys {#old-keys-recv}
+
+For receiving packets during a key update, packets protected with older keys
+might arrive if they were delayed by the network.  Retaining old packet
+protection keys allows these packets to be successfully processed.
+
+As packet protected with keys from the next key phase use the same Key Phase
+value as those protected with keys from the previous key phase, it can be
+necessary to distinguish between the two.  This can be done using packet
+numbers.  A recovered packet number that is lower than any packet number from
+the current key phase uses the previous packet protection keys; a recovered
+packet number that is higher than any packet number from the current key phase
+requires the use of the next packet protection keys.
+
+Some care is necessary to ensure that any process for selecting between
+previous, current, and next packet protection keys does not expose a timing side
+channel that might reveal which keys were used to remove packet protection.
+
+Alternatively, endpoints can retain only two sets of packet protection keys,
+swapping previous for next after enough time has passed to allow for reordering
+in the network.  In this case, the Key Phase bit alone can be used to select
+keys.
+
+An endpoint SHOULD allow a period between one and two times the Probe Timeout
+(PTO; see {{QUIC-RECOVERY}}) after a key update before it creates the next set
+of packet protection keys.  These MAY replace the previous keys at that time.
+With the caveat that PTO is a subjective measure - that is, a peer could have a
+different view of the RTT - this time is expected to be long enough that any
+reordered packets would be declared lost by a peer even if they were
+acknowledged and short enough to allow for subsequent key updates.
+
+Endpoints SHOULD allow for the possibility that a peer is not able to handle a
+key update during this period by allowing three times the PTO after receiving an
+acknowledgment that signals that the key update is complete and initiating
+another.  Failing to allow sufficient time could lead to packets being
+discarded.
+
+An endpoint SHOULD retain old read keys for a period of no more than three times
+the current PTO.  After this period, old read keys and their corresponding
+secrets SHOULD be discarded.
+
+
+## Key Update Frequency
+
+Key updates MUST be initiated before usage limits on packet protection keys are
+exceeded.  For the cipher suites mentioned in this document, the limits in
+Section 5.5 of {{!TLS13}} apply.  Other cipher suites MUST define usage limits
+in order to be used with QUIC.
+
+
+## Key Update Error Code {#key-update-error}
+
+The KEY_UPDATE_ERROR error code (0xE) is used to signal errors related to key
+updates.
 
 
 # Security of Initial Messages
@@ -1460,15 +1603,15 @@ authenticated using packet protection; the entire packet header is part of the
 authenticated additional data.  Protected fields that are falsified or modified
 can only be detected once the packet protection is removed.
 
-An attacker could guess values for packet numbers and have an endpoint confirm
-guesses through timing side channels.  Similarly, guesses for the packet number
-length can be trialed and exposed.  If the recipient of a packet discards
-packets with duplicate packet numbers without attempting to remove packet
-protection they could reveal through timing side-channels that the packet number
-matches a received packet.  For authentication to be free from side-channels,
-the entire process of header protection removal, packet number recovery, and
-packet protection removal MUST be applied together without timing and other
-side-channels.
+An attacker could guess values for packet numbers or Key Phase and have an
+endpoint confirm guesses through timing side channels.  Similarly, guesses for
+the packet number length can be trialed and exposed.  If the recipient of a
+packet discards packets with duplicate packet numbers without attempting to
+remove packet protection they could reveal through timing side-channels that the
+packet number matches a received packet.  For authentication to be free from
+side-channels, the entire process of header protection removal, packet number
+recovery, and packet protection removal MUST be applied together without timing
+and other side-channels.
 
 For the sending of packets, construction and protection of packet payloads and
 packet numbers MUST be free from side-channels that would reveal the packet
@@ -1507,6 +1650,9 @@ values in the following registries:
   Recommended column is to be marked Yes.  The TLS 1.3 Column is to include CH
   and EE.
 
+* QUIC Error Codes Registry {{QUIC-TRANSPORT}} - IANA is to register the
+  KEY_UPDATE_ERROR (0xE), as described in {{key-update-error}}.
+
 
 --- back