Subject: [quicwg/base-drafts] Don't allow use of AEAD_AES_128_CCM_8 (#2029)

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 20:20:05 -0800

Closes #2019.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2029

-- Commit Summary --

  * Don't allow use of AEAD_AES_128_CCM_8

-- File Changes --

    M draft-ietf-quic-tls.md (5)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2029.patch
https://github.com/quicwg/base-drafts/pull/2029.diff

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 20:21:17 -0800

@martinthomson pushed 1 commit.

120cfaa  Be clearer

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2029/files/a265516ae6e760f7585f52f05a1c4dd2b1d41849..120cfaae6e2be8b68b50d374327775b6cf288184

---

From: Marten Seemann <[email-masked]>
Date: Tue, 20 Nov 2018 20:41:03 -0800

marten-seemann approved this pull request.

Do we need to say anything about cipher suites that might get defined for TLS 1.3 after we ship QUIC?

-- 
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/2029#pullrequestreview-177074799

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 20 Nov 2018 20:57:09 -0800

kazuho approved this pull request.

-- 
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/2029#pullrequestreview-177076864

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 22:31:39 -0800

> Do we need to say anything about cipher suites that might get defined for TLS 1.3 after we ship QUIC?

We do elsewhere; for them to be used, they need a corresponding header protection algorithm.  That's all, but that's enough to prevents the CCM suite from being used.

-- 
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/2029#issuecomment-440552150

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 15:35:13 -0800

janaiyengar commented on this pull request.

> @@ -780,9 +780,12 @@ connection ID in the client's first Initial packet (see {{initial-secrets}}).
 This provides protection against off-path attackers and robustness against QUIC
 version unaware middleboxes, but not against on-path attackers.
 
-All ciphersuites currently defined for TLS 1.3 - and therefore QUIC - have a
-16-byte authentication tag and produce an output 16 bytes larger than their
-input.
+QUIC can use any of the ciphersuites defined in {{!TLS13}} with the exception of

use normative language perhaps?
```suggestion
QUIC can use any of the ciphersuites defined in {{!TLS13}} but MUST NOT use
```

-- 
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/2029#pullrequestreview-177462457

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 21 Nov 2018 16:24:38 -0800

kazuho commented on this pull request.

I'd leave it up to the editors but to me it seems that _not_ using normative language is better because what we want here is "unspecified" rather than "forbidden."

-- 
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/2029#discussion_r235572808

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 16:27:59 -0800

Why do we want unspecified? I thought we were actively disallowing this cipher.

-- 
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/2029#discussion_r235573156

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 21 Nov 2018 16:32:59 -0800

Yeah my understanding was that was the conclusion in #2019, but I might be incorrect.

-- 
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/2029#discussion_r235573750

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Nov 2018 16:46:12 -0800

martinthomson commented on this pull request.

I'm happy to say that it is not specified and leave it at that.  The effect is the same.

-- 
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/2029#discussion_r235575152

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Nov 2018 16:50:37 -0800

Is it still relevant to disallow this cipher now that padding up to sample length is required?

The argument for rejecting the cipher is: padding works against the idea of a short AEAD tag - better reject it now and come up with something better for short packets in future versions. Additional argument is simplicity and consistency of 16.

The argument for allowing the cipher is that that there is no reason for it to not work and it is odd to have one cipher that is not permitted.

-- 
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/2029#issuecomment-440870289

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 21 Nov 2018 16:55:34 -0800

@mikkelfj I do not think we have an agreement on how we support AES128-CCM8.

One option is to require `len(pn) + len(payload)` to be 20 for the cipher-suite. The downside is that you would be required to pad a certain amount of bytes when the message is small.

The other option in to require `len(pn) + len(payload)` to be less than that, however we would be required to state that the connection cannot send more than 2<sup>32</sup> packets to avoid birthday attack on header protection (note: header protection key is not updated by Key Update).

I think it would be wise to leave the discussion to the people who are really interested in having AES128-CCM, rather than debating among us who are not really interested in supporting the ciphersuite.

-- 
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/2029#issuecomment-440871757

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Nov 2018 16:56:18 -0800

The argument for rejecting it is that it isn't strong enough.  The padding thing is merely consequential.

(I say this knowing that in other, similar contexts, certain entities happily negotiate 32-bit authentication tags...  But we're trying very hard to eradicate that.)

-- 
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/2029#issuecomment-440871967

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 17:30:17 -0800

@kazuho @martinthomson : I trust your judgement here, so I won't push. It's still not clear to me why disallowing is an issue. Don't mind me though.

-- 
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/2029#discussion_r235579854

---

From: ekr <[email-masked]>
Date: Fri, 23 Nov 2018 10:40:45 -0800

ekr commented on this pull request.

-All ciphersuites currently defined for TLS 1.3 - and therefore QUIC - have a
-16-byte authentication tag and produce an output 16 bytes larger than their
-input.
+QUIC can use any of the ciphersuites defined in {{!TLS13}} with the exception of
+TLS_AES_128_CCM_8_SHA256.  The AEAD for that ciphersuite, AEAD_AES_128_CCM_8
+{{?CCM=RFC6655}}, does not produce a large enough authentication tag for use
+with header protection ({{header-protect}}).  All other ciphersuites defined in
+{{!TLS13}} have a 16-byte authentication tag and produce an output 16 bytes
+larger than their input.

It seems like there are two issues here:

1. What is sufficient to allow PNE.
2. What ciphers are secure enough.

It seems like for (1) we ought to say: "any cipher used with QUIC MUST have a minimum output size of at least X unpredictable bytes". That will exclude this cipher.

For (2) I think we ought to punt this to TLS.

-- 
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/2029#pullrequestreview-178007986

---

From: Martin Thomson <[email-masked]>
Date: Sun, 25 Nov 2018 19:30:33 -0800

8529d06  Just these header protection schemes, not more generally

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2029/files/120cfaae6e2be8b68b50d374327775b6cf288184..8529d06bbe155c7839e9a16d8aff34cdbf2866e3

---

From: Martin Thomson <[email-masked]>
Date: Sun, 25 Nov 2018 19:33:00 -0800

I broadly agree, though I don't think that we can do (1) here because we don't know what PNE scheme might be devised to be paired with some future AEAD.  It seems like we have a requirement now, but something like FFX might be OK with a smaller sample.  I would prefer, as this does, to simply say that CCM_8 doesn't have a large enough expansion to use with the header protection schemes we have defined.

Should someone address the second question (and the question of whom to convince of this is interesting, but within the IETF it's clearly TLS), and design an header protection scheme based on that, then my hope is that this text wouldn't prevent them from using that.

-- 
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/2029#discussion_r236113733

---

From: ekr <[email-masked]>
Date: Sun, 25 Nov 2018 19:43:09 -0800

Hmm.... This seems like it raises the broader issue of how we import new ciphers into QUIC. As a hypothetical suppose TLS were to adopt an AES-GCM-SIV-based construction. It seems like at present we would actually require some new document to explain how to use it with QUIC. That seems sort of unfortunate, but formally I think that's true, because this document specifies a very specific list of ciphers.

If we wanted to, we could probably generalize this to some extent by documenting the *properties* of given ciphers and then how header protection works (i.e., block ciphers are done like this, nonce-based stream ciphers are done like this...) Not sure it's worth it, thoguh.

-- 
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/2029#discussion_r236114739

---

From: Mike Bishop <[email-masked]>
Date: Mon, 26 Nov 2018 12:34:02 -0800

MikeBishop commented on this pull request.

Yes, this does currently require that a PNE algorithm be defined for any new cipher to be used with QUIC v1.

-- 
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/2029#discussion_r236415637

---

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

Merged #2029 into master.

-- 
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/2029#event-1988175403