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

From: ekr <[email-masked]>
Date: Fri, 15 May 2020 15:58:32 -0700

Over in TLS we have been discussing the data which is included in the AEAD transform. 

1. Some parts of the context for encryption (epoch, length, etc.) are implicit.

2. The AD only covers the bits on the wire.

This intuitively seems like it ought to be OK because these values do affect how the protection is done, but only implicitly. For instance, length delineates the data, the packet number/record sequence number controls the nonce, etc., but nevertheless only some of these values are in the AD. It turns out that there is a bit of a gap between analysis we have of this so far and the
current state, and specifically we don't have analysis of the epoch, which is sent only partially in both QUIC and DTLS [0]. Note that QUIC is actually worse than DTLS here because in DTLS the epoch is folded into the sequence number used to make the nonce, but in QUIC the nonce is just the packet number. This issue is intended to raise the question of if we should revisit that, for instance by putting the epoch in the AD.

[0] https://mailarchive.ietf.org/arch/msg/tls/Ri33zZmFNb1kZ4HToDHs9cDDTPY/

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

---

From: ekr <[email-masked]>
Date: Sat, 16 May 2020 05:13:38 -0700

See also: https://mailarchive.ietf.org/arch/msg/tls/YE1uAmPFL_59E-5h9fHn0sLE_B0/

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

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 17 May 2020 16:34:59 -0700

In case of QUIC, I wonder if epoch is included already in AAD, as the packet type in the first byte.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 17 May 2020 17:37:23 -0700

As Kazuho says, the short value is covered by the AAD; it's only the full value that we need to worry about.

This is only an intuition, but my expectation is that the analysis offered in https://www.felixguenther.info/docs/QUIPS2020_RobustChannels.pdf could extend to epochs.  That is, the packet contains the key phase, which is analogous to the packet number.  Endpoints only accept packets within a very narrow window.  For packet numbers, this is determined by the length of the packet number encoding in that analysis; for epochs, this would be the two epochs you keep live, which matches the length of the key phase.  I can make an argument that keeping the number of keys less than the number of epoch values is no worse than one key and no encoded epoch values.

That's not formal though; there might be a trick needed to resolve the odd loop where the value you are relying on is authenticated by the key that it identifies (I don't see that question being addressed in the referenced thread).

The question for me is whether you believe that this requires formal analysis.  Obviously it would be great if someone could find a way to subject this to more formal analysis, but we need to determine how much of a deal-breaker this could be.

Folks in TLS seem to be pushing toward adding more to the AAD, but that doesn't seem to be well supported by anything other than an excess of caution in the absence of any real analysis.  I don't think we should change something without formal analysis supporting additional measures.

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

---

From: ekr <[email-masked]>
Date: Mon, 18 May 2020 18:17:10 -0700

I think where TLS is going to land is with no change, because the nonce includes the full epoch. I have the same intuitions as you, but as you say they aren't formal. 

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?

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 May 2020 18:26:30 -0700

Given the limits we have on usage, 2^32 would mean exhausting epochs before we exhaust packet numbers.  Both are pretty large values, and maybe we can avoid that limit for some future AEAD.  For AES, that means 2^56.5, which equates to roughly 1e20 bytes (100 exabytes) at a 1400 byte MTU, which seems like it would be tolerable.

That said, this is a fairly fundamental change with fairly thin rationale.  If people don't want to do this, then I'm not inclined to push very hard for a change.

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