Subject: [quicwg/base-drafts] TLS_AES_128_CCM_8_SHA256 (#2019)

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Nov 2018 21:20:54 -0800

We assume that every TLS 1.3 cipher suite has a 16 byte expansion.  TLS_AES_128_CCM_8_SHA256 doesn't.

The most sensible options seem to be:

1. Leave header protection for this suite undefined, and explain that this particular suite can't be used as a result.  A later extension might be defined that could be used to enable this suite.
2. Require that `len(payload) + aead_expansion` be at least the sample size, meaning that padding is required for suites that have a short authentication tag.

We could put a flat prohibition on the use of this cipher suite.  I don't consider this particular suite to be a good choice for a general-purpose protocol and have reservations about its value in the domain it is design for.  But it is a "recommended" cipher suite and we need to be principled in our approach.  I prefer the former option on that basis.

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

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Nov 2018 21:48:27 -0800

I agree that we do not need to have AES128-CCM8 in QUIC.

At the same time, it is IMO a good idea to be less coupled to the properties of cipher-suties that we support now. That is one of the reasons I prefer @DavidSchinazi's proposed padding scheme: `length(packet number) + length(payload) >= 4` (see 
https://github.com/quicwg/base-drafts/issues/1575#issuecomment-425662595, 
https://github.com/quicwg/base-drafts/pull/2006#discussion_r234033345).

The scheme not only simplifies the logic that we have for dealing with short packets but also gives us the agility to support cipher-suites with short authentication tags, i.e., the only required change would be to alter the constant (i.e. `4`) to an appropriate value.

-- 
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/2019#issuecomment-439778672

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 Nov 2018 22:38:37 -0800

It's not really a constant.  In the general case, we want to ensure that `length(packet_number) + length(payload) + aead_expansion > sample_size + max_pn_encoding`.  The problem with the AEAD in question that `aead_expansion = sample_size + 8`.

-- 
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/2019#issuecomment-439786651

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 18 Nov 2018 22:49:23 -0800

What I mean is that if we view the equation as `length(packet_number) + length(payload) >= x`, then x becomes a per-cipher-suite constant (under the assumption that `max_pn_encoding` is a constant of 4 in v1).

This is because both `aead_expansion` and `sample_size` are constants of a cipher-suite. All cipher-suites that we have defined now use 16 for the two; therefore, the right-hand-side is 4. If we adopt AES128-CCM8, (aead_expansion, sample_size) would be (16, 8), thereby the right-hand-side becomes 12.

-- 
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/2019#issuecomment-439788521

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Nov 2018 00:07:52 -0800

Could the sample size be defined to be the AEAD tag size always? There is no point strenght in sampling padding and the overall security is bounded. Padding just wastes space, adds complexity elsewhere.

Besides, there might cases where a short msg is more interesting than high security - even if CCM is not it, there might be future ciphers and the header protection design should be robust.

-- 
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/2019#issuecomment-439804464

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 19 Nov 2018 13:21:56 +0000 (UTC)

@mikkelfj I think that is a very good point. In other words, both of the following seem to be true to me:
* many of us not only do not want to spend the effort of defining AES128-CCM8 in QUIC v1
* we are not sure what the preference of the people looking for a constrained cipher-suite would be

Considering that, I tend to think that preserving agility (i.e. keep the definition for AES128-CCM8 undefined; do not talk about general restriction; let `length(pn) + length(payload)` be a per-cipher-suite constant) seems like the best approach.

-- 
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/2019#issuecomment-439890526

---

From: David Schinazi <[email-masked]>
Date: Mon, 19 Nov 2018 18:41:45 +0000 (UTC)

@mikkelfj I believe your point about padding is incorrect. The PNE algorithm samples the ciphertext, so whether it was padding or application data is irrelevant.

I still think there's value in always padding to ensure `length(packet number) + length(payload) >= 4`, but I agree that we should ignore CCM8 in the QUICv1 specs.

-- 
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/2019#issuecomment-439998334

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Nov 2018 10:43:52 -0800

It matters if the packet is short, and thereby defines the security bound.

-- 
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/2019#issuecomment-439998954

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Nov 2018 18:44:48 +0000 (UTC)

And since the importance of packet integrity is larger than the importance of packet number secrecy, the security bound is also the tag length.

-- 
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/2019#issuecomment-439999241

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Nov 2018 15:30:30 -0800

Closed #2019 via #2029.

-- 
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/2019#event-1988175407