Re: Key updates

[Martin Thomson <[e-mail]>]

On Tue, Aug 7, 2018 at 2:55 PM Kazuho Oku <[e-mail]> wrote:
> I do not think that the current mechanism requires trial decryption.
> IIUC, the endpoints are not allowed to start sending packets at epoch
> N+1 until they see peers acknowledging packets that were sent in epoch
> N. That means that an endpoint only needs to have at most 2 keys (for
> epoch N+1 and N). The epoch (either N or N+1) can be recovered from
> the KEY_PHASE bit and there is no need for trial decryption.
>
> Am I missing something?

There is a problem right now with concurrent updates.  If both peers
bump at the same time, then N-1 packets could still be in flight.  A
little reordering will cause them to be interpreted as N+1 instead
(because they arrive after packets at N and we only have one bit of
signal).

So if you want to avoid loss spikes around rekeying, you have to do a
little trial decryption at that point.

Also, the way you ratchet forward is to observe a bit flip, at which
point you decrypt with N+1.  If that works, then you do something.
It's not quite trial decryption in the sense that you only try one
key, but - having implemented it - it's a little annoying to get
right.


> I am not sure if adding a way to signal the receipt of ACK for a
> particular TLS message from QUIC to TLS stack is worth the cost. We do
> not have that kind of mechanism. I am scared that such mechanism could
> become very complex, considering the fact that the QUIC stack can
> split TLS handshake in any way that it would like.
>
> Or are you suggesting a mechanism other than what is defined in DTLS?

It's pretty close that in DTLS.  Here's what I imagined would work:

You let TLS send its KeyUpdate, which gets bundled into a CRYPTO
frame.  TLS moves to the new epoch, and advertises the availability of
new keys.  However, you continue to send in the old epoch until you
have flushed all pending CRYPTO data from the old epoch (i.e., the
CRYPTO frame has all been acknowledged).  All other processing stays
the same: CRYPTO frames are always sent using the same keys, even on
retransmission, new TLS messages would be sent in the new epoch, and
ACK frames would need to send using the epoch of the packets they
acknowledge.

The reason we don't have problems with the handshake is that we *know*
that the peer has keys for the new epoch.  Otherwise we would have to
do the same thing.  There, following these rules would mean sending in
the clear, which isn't smart.  Here, it's just a key update.