Re: [quicwg/base-drafts] Rewrite key update section (#3050)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.

Thank you very much for writing this.

This is a big change in text and I assume it has been tough to write down. It's also hard to read and make comments at once, so below are my tentative comments.

> +{{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.

It seems a bit odd that we do not talk about 0-RTT packet here, even though Initial and Handshake are mentioned.

Maybe something like: _Keys of packets other than the 1-RTT packets are never updated; their keys are derived solely from the TLS handshake state._

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

s/updates/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.

Would it be possible to clarify the ordering of the operation that the endpoint needs to follow?

IIUC, there is a MUST requirement to update the send keys, before sending an ACK for a packet that triggered that update.

We have the following paragraph starting from line 1280 stating that the peer can close the connection if the endpoint does not follow this ordering requirement.
>  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.

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

Maybe s/this generating/this key generation/?

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

IIUC, this sentence is suggesting an alternative approach to the previous sentence. Assuming that is the case, I think it might be slightly better to start this sentence with "Endpoints MAY _instead_".

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

Maybe "adding" is superfluous?

-- 
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/3050#pullrequestreview-290325868