Re: [quicwg/base-drafts] Include epoch in the AAD or the nonce? (#3661)

[Kazuho Oku <[e-mail]>]

As as implementer, I hope that this issue will be closed with no action, assuming that we do not have strong reason for making the change.

Up until now, we have tried hard to have minimum divergence in the record encryption algorithms being used in QUIC and TLS. We use HKDF and AEAD the same way, with the only difference being the labels. The proposed change would be a departure, as it means that the AEAD layer of QUIC would no longer be using a sequence number, but rather a tuple of epoch and a sequence number.

It does break the existing AEAD API of picotls, as it assumes the use of a 64-bit sequence number (this might have been a shortsighted decision, but anyways).

@ekr
> With that said, as you observed in our call today, it seems like there is an easy fix: both AES_GCM and ChaCha20/Poly1305 take a 96-bit nonce which we are just left-padding with 0s. If we are willing to restrict to <2^32 key changes, we could encode the epoch in those 0s, right?

Am I correct to understand that this is effectively the same as XORing the first four bytes of IV with the epoch? I think that is the case because the moment an endpoint changes the send epoch is when it moves to a new set of key and IV.

Based on that view, I wonder what the benefit is by changing IV from _HKDF<sup>epoch</sup>_ to _HKDF<sup>epoch</sup> XOR epoch_ is. I'm eager to admit that I do not understand the problem, but I would assume that, when applying HKDF multiple times, we do need to retain a counter counting how many times HKDF was applied, and then mix that into the output.

-- 
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/issues/3661#issuecomment-637192990