Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)

[MikkelFJ <[e-mail]>]

I read through the latest commit and I think it is largely fine, but I found the attack discussion a bit difficult, and the text is not distinguishing between receiving a key and authenticating a key. Also, it is probably not clear to the reader that the intent is to compute a key ahead of time when reading the first section. Furthermore, there is also an attack on send since if you compute the send key when you respond immediately, that can be timed.

The text also does not discuss what to do with a packet that does not authenticate. Do you drop, or something else. After trying to formulate that, I ended up with some problems that you can hopefully help clarify.

Here is my proposed text:

```
Packets received with the current key phase are unprotected using the
corresponding receive key.  When a packet arrives with the opposite key phase,
an endpoint determines which receive key to use by tracking the lowest packet
number among the packets received and successfully decrypted and authenticate
with the currently key phase. If a packet is received that has a different
KEY_PHASE bit and a lower packet number than this value, the endpoint uses the
receive key of the previous key phase for unprotecting the packet, if that key
is available.

If the packet has a higher packet number and it can be decrypted and
authenticated with the receive key of the next key phase, the receiver switches
to the new keyphase.

An an endpoint SHOULD compute the secret and related receive and send keys of
the next keyphase ahead of time to protect against timing attacks. The receiver
therefore has at least two installed receive keys but SHOULD transitionally
maintain older an older key to deal with late arriving packets for a duration of
3 PTO after switching to a new key phase.

The endpoint derives keys of the next key phase by calculating the
next secret (see Section 7.2 of {{!TLS13}}), the corresponding read key and IV
using the KDF function provided by TLS.

Once an endpoint has sent a packet encrypted with a given key phase, it MUST NOT
send a packet encrypted with an older key phase. (EDITORIAL: see note below)
If packet cannot be decrypted the reciever drops the packet but MAY also close
the connection with a PROTOCOL_VIOLOATION error if it finds that it can decrypt
and authenticate a packet with receive key that is retired for that packet number. 

(EDITORIAL NOTE: I'm struggling with when a key is fully retired and in violation because
it is always possible that an earlier packet is received after a key switch
which also carries the new key phase. You could formulate something but it gets
complicated).
```

Maybe we can just use "successfully unprotect" instead of decrypt and authenticate. Or perhaps it is enough to authenticate without decrypting. Noting that these are parallel and separate steps in GCM that can be processed separately.

-- 
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/pull/2791#issuecomment-503441559