Subject: Re: [quicwg/base-drafts] Bring back AEAD_AES_128_CCM_8 now that we pad the plaintext (#2581)

From: Martin Thomson <[email-masked]>
Date: Tue, 14 May 2019 20:22:50 -0700

I don't think that we need this.  The reasons offered thus far amount to "because we can".  I'd like to see some analysis suggesting that shorter authentication tags are OK in the general case.  Or text explaining constraints on deployments that choose to use a shorter tag.

I understand the benefits of CCM over GCM; I understand that this includes an ability to have a shorter tag, unlike GCM which fails badly.  I understand the desire to save bits.  But it isn't really that many bits, and the shorter tag changes the odds of an invalid packet being accepted fairly significantly.

-- 
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/2581#issuecomment-492488640

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 10:48:24 -0700

@martinthomson can you elaborate on what makes QUIC different from TLS that suggests AES_128_CCM_8 is useful in TLS but not in 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/issues/2581#issuecomment-492755452

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 15 May 2019 11:41:18 -0700

It's worth remembering that QUIC packet sizes are (typically) smaller than TLS record size which means that the consequences of saving bytes are larger in QUIC than in 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/issues/2581#issuecomment-492775203

---

From: ekr <[email-masked]>
Date: Wed, 15 May 2019 14:04:23 -0700

Well, we generally discourage the use of CCM_8 in TLS as well. We mostly
only added it for IoT purposes.

On Wed, May 15, 2019 at 10:48 AM David Schinazi <[email-masked]>
wrote:

> @martinthomson <https://github.com/martinthomson> can you elaborate on
> what makes QUIC different from TLS that suggests AES_128_CCM_8 is useful in
> TLS but not in QUIC?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2581?email_source=notifications&email_token=AAIPLINSIBZDOXBXQRCEFMLPVREGHA5CNFSM4HC3I4QKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVPNT7A#issuecomment-492755452>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAIPLINNMNR2H6V4M2HVBF3PVREGHANCNFSM4HC3I4QA>
> .
>

-- 
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/2581#issuecomment-492823179

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 15:35:37 -0700

@ekr QUIC is also applicable to IoT, CCM_8 should be supported but discouraged here as well.

-- 
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/2581#issuecomment-492849231

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 May 2019 17:07:08 -0700

Is there a strong argument to diverge from existing TLS practice here?

-- 
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/2581#issuecomment-492867597

---

From: MikkelFJ <[email-masked]>
Date: Wed, 15 May 2019 22:44:43 -0700

CCM_8 is better suitet for a separate QUIC version for IoT where header protection and padding is also dropped and where the traffic volume is low. A cheaper habdshake would also be needed.

Someone said CCM_8 is commonly used with video AFAIR.

-- 
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/2581#issuecomment-492925490

---

From: David Schinazi <[email-masked]>
Date: Thu, 16 May 2019 18:50:31 +0000 (UTC)

@mikkelfj I don't think encouraging protocol fragmentation is a good idea. The reason TLS 1.3 has CCM_8 is to allow IoT use-cases to use TLS 1.3 instead of making them develop new protocols. The same argument applies to 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/issues/2581#issuecomment-493188584

---

From: ianswett <[email-masked]>
Date: Fri, 17 May 2019 04:20:27 -0700

Q: Should we allow it for QUIC, but not allow it for HTTP/3?

-- 
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/2581#issuecomment-493418795

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 May 2019 04:53:31 -0700

No, the application layer shouldn't deal with transport security. If the security properties changes, it should be a new QUIC version.

-- 
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/2581#issuecomment-493426393

---

From: David Schinazi <[email-masked]>
Date: Fri, 17 May 2019 05:35:29 -0700

I agree with @mikkelfj on this one. HTTP/2 doesn't disable CCM_8 when run over TLS 1.3.

-- 
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/2581#issuecomment-493437438

---

From: MikkelFJ <[email-masked]>
Date: Fri, 17 May 2019 05:38:12 -0700

But if I argue that CCM_8 changes security properties, you might disagree since that would move CCM_8 to a new QUIC version.

-- 
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/2581#issuecomment-493438133

---

From: ekr <[email-masked]>
Date: Fri, 17 May 2019 05:42:52 -0700

@DavidSchinazi this doesn't seem like a very persuasive analogy, given that HTTP/2 has a long list of rules about disabling ciphers that were present in TLS 1.2:

https://tools.ietf.org/rfcmarkup?doc=7540#section-9.2.2

The reason that it doesn't have that in TLS 1.3 is because (1) TLS 1.3 post-dates HTTP/2 and (2) the suites were chosen according to the same principles

Second, as a practical matter, most browsers do not support CCM_8, and I suspect that will continue to be true for most stacks, partly because performance is not awesome (as it requires computing CBC). If, as @RyanAtGoogle implies, we want to have a cipher with a shorter authentication tag (I'm undecided on this topic myself at present) for general use then we should consult CFRG for one, rather than just use the one that happened to be the one that IoT devices supported.

-- 
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/2581#issuecomment-493439412

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 May 2019 10:12:56 +0000 (UTC)

I would personally have preferred to include AES_128_CCM_8 in the QUIC spec to have parity with TLS 1.3, but I can live with the text from #2743 because that allows someone to write a one-page spec on how to use AES_128_CCM_8 in QUIC without risking interoperability issues. I'm OK with closing this issue with no further action at this point.

-- 
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/2581#issuecomment-496454668