The TLS key schedule looks like this:
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.
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.
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.
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.
