[quicwg/base-drafts] Timing side-channel on key updates (#2792)

[Marten Seemann <[e-mail]>]

When receiving a packet with an unexpected key phase, an implementation should compute the new keys:
> A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret [...] and the corresponding read key and IV using the KDF function provided by TLS.

This creates a timing side-channel, since an attacker can modify the KEY_PHASE bit, thereby making a peer compute the next key generation. The packet will be discarded, since the header is protected by the AEAD, but the fact that the key is computed on receipt of that packet is a side-channel that might be used to recover the header protection key.

The way to avoid this side-channel is to pre-compute the N+1 key when rolling over keys from key phase N-1 to N. An implementation would then use the N+1 keys when receiving a packet with an unexpected KEY_PHASE, in exactly the same way it would do decryption on a packet sent at key phase N.

This however contradicts the text that claims that an implementation may choose to only keep two read keys at any given moment:
> 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.

Directly after a key update, an implementation would have to store (at least) 3 key generations: N-1 for a duration of 3 PTO, in order to be able to decrypt delayed / reordered packets, N, as well as the precomputed N+1 to avoid the timing side-channel described above.

I don't think that storing 3 keys is a problem (I think @kazuho disagrees, I'll let him explain his reasoning himself), but the spec shouldn't pretend that it's possible to create an implementation that both isn't vulnerable to the timing side-channel and at the same time gracefully handles moderate amounts of reordering around a key update.

-- 
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/issues/2792