Skip to content

Instantly share code, notes, and snippets.

@martinthomson
Last active June 13, 2021 07:43
Show Gist options
  • Save martinthomson/c254bbc4214e8b3d4f38372b9afce18d to your computer and use it in GitHub Desktop.
Save martinthomson/c254bbc4214e8b3d4f38372b9afce18d to your computer and use it in GitHub Desktop.
QUIC Key Schedule

The TLS key schedule looks like this:

TLS Key Schedule

QUIC effectively exports the various traffic secrets, so I had assumed that its use of the different base label in HKDF-Expand-Label() would be limited to those uses that were after that export. I forgot key update when writing this up, but that was fixed in #1899.

QUIC Key Schedule

However, in looking at what people implemented, it appears that the base label they use was used for the entirety of the TLS key schedule.

QUIC Key Schedule - As Implemented

This has the unfortunate property of being quite invasive, as well as making it difficult to upgrade to any potential future TLS 1.4, which might use a different key derivation function (KDF).

Therefore, I propose that we either revert to using HKDF-Expand-Label() unmodified, and instead change the labels used to derive the "key", "iv", and "pn" keys. By adding "quic " to these, the effect will be that keys are diversified (as intended). The resulting label is a little strange ("tls13 quic key"), but this ensures that the KDF can be used directly, without altering the core key schedule.

Proposed QUIC Key Schedule

We could, as proposed by #1976, just use the TLS key schedule. That assumes that the presence (or absence) of the QUIC extension is sufficient to ensure that TLS-in-QUIC is properly distinguished from TLS-over-TCP. An attacker might be prevented from causing the two variants to be confused after the switch to handshake protection, because they can't re-encapsulate packets/records without keys, but relying on that could make analysis difficult. It creates an interdependency between the handshake and the packet-/record-protection layer, which we have avoided thus far.

In talking to Chris Wood, who raised this issue, we agreed that an additional layer of key separation is the most cautious approach, even if we can't think of any way in which this might be exploited.

Display the source blob
Display the rendered blob
Raw
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Display the source blob
Display the rendered blob
Raw
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Display the source blob
Display the rendered blob
Raw
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Display the source blob
Display the rendered blob
Raw
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment