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

From: Kazuho Oku <[email-masked]>
Date: Mon, 01 Jun 2020 17:16:15 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 01 Jun 2020 17:35:57 -0700

Kazuho, you have the gist of it.  There is no material performance impact.  The base nonce that you xor the packet number with is still constant.  But the theory would be that you don't get confusion about which epoch was used.  The counter-argument being that the keys (and the nonce) should be completely different anyway.

As you can see, the concern is that there is a risk inherent.

As for divergences, it's not divergent from DTLS, which is where this is coming from.  Because the analytical framework for the record/packet layer in DTLS is more similar to QUIC, that makes this somewhat more compelling.

All that said, I'm inclined toward no action myself, but I want that to have a firmer basis than we currently have.  I am prepared to accept that we won't get that though, in which case we will just have to make a call.

-- 
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-637199156

---

From: ianswett <[email-masked]>
Date: Tue, 02 Jun 2020 14:46:54 -0700

Without evidence this is a problem, I strongly prefer the status quo which aligns more closely with TLS.

If we get new information, we can always fix this in QUICv2.

-- 
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-637823845

---

From: Felix Günther <[email-masked]>
Date: Wed, 03 Jun 2020 00:14:35 -0700

As already mentioned, there's little analytical support regarding key updates in QUIC (and DTLS), including [our analysis](https://www.felixguenther.info/docs/QUIPS2020_RobustChannels.pdf). As stated for DTLS, my understanding is that some form of authentication of the epoch number would be helpful for a clean analysis.

My thought is: with QUIC's current approach, you could _in principle_ have that the key+IV across two epochs collide, which then would mean you can replay packets across those two epochs. If the epoch is authenticated through the AAD, that's prevented. With XOR-ing into the nonce it's more messy, as now you could have a colliding IV 'cancel out' the XOR (the same affects DTLS, actually).

That said, I would expect the concrete loss for key+IV collisions to probably be an additional birthday-bound term in the order of  #epochs^2 / 2^{|key|+|IV|}. Here, I am thinking of #epochs = number of epochs in a connection, coming from an/our analysis viewpoint on the full channel. In extending that to multiple keys one would usually want to abstract out key generation and assume key/IV across all epochs to be independent, hence the birthday bound.

Martin pointed out to me that (a) #epochs might be reduced to the number of currently active epochs (2-3), and (b) |IV| might be too much due to the sequence number range, which may lead to nonce collisions between ranges.

So, overall, while having the epochs in the AAD might be cleaner from an analysis point of view, I don't have a strong basis for that and think no-change likely comes with a small loss only in comparison.

-- 
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-638005491

---

From: Lars Eggert <[email-masked]>
Date: Wed, 03 Jun 2020 04:23:29 -0700

It sounds like the proposal is to close with no action, or alternatively, to park this issue until new information is available? It would be great if we could resolve this soon, since we are hoping WGLC the next set of documents w/o open design issues.

-- 
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-638133140

---

From: ekr <[email-masked]>
Date: Wed, 03 Jun 2020 18:48:21 -0700

Thanks @fxguenther. Based on this I am happy to close with no action

-- 
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-638552333

---

From: Lars Eggert <[email-masked]>
Date: Wed, 03 Jun 2020 23:12:18 -0700

Great, I will mark this proposal-ready, where the proposal is to close with no action. We'll confirm that together with the WGLC on -29.

-- 
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-638624653

---

From: David Schinazi <[email-masked]>
Date: Thu, 04 Jun 2020 18:20:14 -0700

I support close with no action based on the analysis in this thread.

-- 
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-639202274

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 09 Jun 2020 15:25:58 -0700

Based on the discussion here, the proposal is to close this issue with no action.

-- 
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-641613626