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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

@ekr, I think that it is up to us to work out what the key update side channel looks like.

(Sorry for leaving these comments pending for so long, I thought that I had posted them already.

>  
 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

My bad.  Refactoring collateral.

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

We are.  That's the KDF TLS provides.

To your point below, the label is "tls13 quic ku".  When we get TLS 1.4, assuming that it makes minimal changes, we'll use HKDF-Expand-Label with "tls14 quic ku".

> +## 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.
+
+For example, to update write keys with TLS 1.3, HKDF-Expand-Label is used as:
+
+~~~
+secret_<n+1> = HKDF-Expand-Label(secret_<n>, "quic ku",
+                                 "", Hash.length)
+~~~

See above.  We're not changing the label the KDF uses internally.

Elsewhere we have "tls13 " + "quic iv" or "quic key" or "quic hp".

> +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:
+
+: Keys of packets other than the 1-RTT packets are never updated; their keys are
+  derived solely from 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.

This is part of the removal of timing side channels.  I know that you think that's overcomplex, but I am current disinclined to agree.  More later.

> +
+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 receive packet protection keys until some time after a key update
+completes, up to three times the PTO; see {{old-keys-recv}}.

I disagree.

I agree with you that the leak is minor.  And that acquiring the signal might be difficult (but nor do I think that it's impossible).

However, I think that the fix is cheap.  As long as you aren't resource-constrained, you just ensure that you always have the next set of keys available.  The recommendation is really only around deferring that processing.  It's not zero effort, but I doubt that "a lot more complicated" is accurate.

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