Re: Key updates

[Mikkel Fahnøe Jørgensen <[e-mail]>]

On the last part: using a longer packet number - that would create an
observable signal similar to an unencrypted key-phase bit because many
packets would tend to have similar sizes, then suddenly spike a few bytes
in length.

Key phase could also be tied to connection id, and perhaps some
consideration should be given to a possible multi-path design before opting
for the more complex solution.

As I understand it, the commit option still requires synchronised key
updates in both directions. How about one-sided key updates?

On 6 August 2018 at 07.56.18, Martin Thomson ([e-mail])
wrote:

One of the open items out of the design team work was the interaction
between TLS and key updates. As you might know, TLS key updates are
synchronous, which works well in TCP, but less well in QUIC, where you
need at least two active keys for reception around a key change.

As it is, I think that there are two serious options:

1. Use KEY_PHASE to signal a change. This requires that both
endpoints are loosely synchronized, which disadvantages asymmetric
data exchanges.

2. Use a prepare-commit style. DTLS does this by having each peer
send a KeyUpdate message, then requiring that to be acknowledged
before they can switch to the new epoch. QUIC could do the same. The
change is still signaled in the key phase bit, but only after this
signaling exchange.

The weakness of the first option is that packets marked with a change
of key phase trigger trial decryption. And it requires synchronized
changes, where if one endpoint moves to epoch N (epoch == encryption
level with fewer characters to type), then the other has to follow
before either can move to epoch N+1. The second has more moving
parts, but avoids both of these problems.

I tend to think that the second is a better design on balance, if only
to dispense with the trial decryption, which we've managed to avoid in
every other case thus far. The complication might also present some
opportunities, which I will explain below, but that's a secondary
concern.

If we want to use this signaling method, we need to decide who drives
key updating, TLS or QUIC:

TLS: The DTLS design might work in QUIC, but with the KeyUpdate
message hidden in an opaque CRYPTO frame, it could be a little tricky
to manage properly. If we let TLS drive the key update, then it will
send a KeyUpdate message in a CRYPTO frame and inform QUIC of the
change in sending keys. From here, QUIC can keep using old keys until
all CRYPTO frames from that epoch are acknowledged. The receiver will
inform QUIC of new receive keys when it receives KeyUpdate, which can
be installed.

QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC
sends when it wants to update keys. When this is acknowledged, new
keys can be installed and used for sending. A new API is needed to
TLS to support cranking the key schedule forward. Invoking that API
would lead to TLS signaling the availability of new keys. The receive
side isn't any different from the TLS option. If this was to have
parity with TLS, this would probably need to be two frame types so
that a unilateral update could be distinguished from an update that
includes a request for a mutual update.

In both cases, QUIC will install new receive keys, but retain old
receive keys so that it can deal with reordering. A few round trips,
an RTO, 2MSL, or whatever we decide for the handshake is probably
fine. Sending keys can be discarded immediately.

The advantage of having TLS drive is that it uses the same machinery
we have for the handshake. And there is no disparity between what TLS
and QUIC understand to be current: when TLS wants to send something (a
NewSessionTicket message for example), then it asks for an epoch that
matches what QUIC is using.

The disadvantage of using TLS is that there are more moving parts
involved. It fits the rules we have for the handshake neatly: for
instance, the CRYPTO frame would be retransmitted using the strict
encryption-level rules, reusing that code from the handshake. But
those rules aren't really necessary given that the rules for a
KEY_UPDATE easily have the same effect.

My inclination here is to have TLS drive this. The additional
complexity seems to be manageable in the sense that it uses mechanisms
that should already exist for the handshake. I also don't think that
a new API for this feature is a good way to ensure that it is used.

Those who are implementing, I know that key updates are often a long
way down the list of priorities, but has anyone spent time considering
the options here? (I personally implemented key updates for TLS, but
I still haven't managed to find time to do it for DTLS, which might
say something...)

-- 
Addendum: Optional Key Phase ?

One of the nice things about either prepare-commit design is that it
opens a new option for how we use bits in headers. If there is a
concern about spending a bit on every packet for the key phase (a
whole bit!), we could design an encoding that only included the key
phase if a longer packet number encoding was in use.

The idea would be that you could use the longer packet number encoding
while you have a key update outstanding, so that the key phase was
available for the entirety of the changeover. Once packets with the
new epoch were acknowledged, you could switch back to a shorter
encoding that didn't include a key phase. The receiver would switch
to expecting the new epoch after receiving the first packet in the new
epoch.

That's a saving that might allow endpoints to use the shortest packet
number encoding in more cases. Of course, the header design is
already complex enough, so maybe we don't actually *want* more options
to consider there :)