Subject: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

From: Joseph Salowey <[email-masked]>
Date: Tue, 21 Feb 2017 10:22:17 -0800

Here are the open issues for draft-ietf-tls-ecdhe-psk-aead

1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead of
SHA384 like the other 256 bit cipher suites? (From Russ Housley)

2.  Since the security considerations mention passwords (human chosen
secrets) it should mention dictionary attacks. (From Russ Housley)

3.  Section 2 and 3 of the document contains more detail about TLS 1.3 than
necessary.

Section 2: This document only defines cipher suites for TLS 1.2, not TLS
1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
1.3 specification.

Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
section 4 that states:

"TLS 1.3 and above name, negotiate and support a subset of these cipher
suites in a different way."  (TLS 1.3 does not support
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384
and TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)

4. Section 3 should contain a bit more detail about relationship to 4492
bis and RFC 4279:

Something like the following may be enough.

"This messages and pre-master secret construction in this document are
based on [RFC4279].  The elliptic curve parameters used in in the
Diffie-Hellman parameters are negotiated using extensions defined in
[4492-bis]."

Thanks,

Joe

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 17:42:18 +1100

On the interaction with TLS 1.3, we probably need a decision to be made:

1. strike TLS 1.3 from the document and only mention it in the way Joe
suggests, TLS 1.3 doesn't get the CCM suites (it already has the
equivalent of the GCM suites)

2. strike TLS 1.3 from the document, and add new TLS 1.3 CCM cipher
suites to TLS 1.3 proper

3. add new TLS 1.3 CCM cipher suites to the document

It seems like 1 is a no-go on the basis that this document wouldn't
exist if CCM suites weren't at least a little bit interesting.

On 22 February 2017 at 05:22, Joseph Salowey <[email-masked]> wrote:
> Section 2: This document only defines cipher suites for TLS 1.2, not TLS 1.2
> or later.  A subset of equivalent cipher suites is defined in the TLS 1.3
> specification.
>
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and
> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256)
>
> 4. Section 3 should contain a bit more detail about relationship to 4492 bis
> and RFC 4279:
>
> "This messages and pre-master secret construction in this document are based
> on [RFC4279].  The elliptic curve parameters used in in the Diffie-Hellman
> parameters are negotiated using extensions defined in [4492-bis]."
>
> Thanks,
>
> Joe
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Feb 2017 08:04:13 +0000

Why not just say
	The CCM cipher suites are not (currently) defined for TLS 1.3

And leave it at that.  We're all quite proud of the fact, and deservedly so, that we only have three ciphers defined for TLS 1.3.  Let's try to hold that position as long as possible.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 22 Feb 2017 13:43:21 +0200

> On 22 Feb 2017, at 8:42, Martin Thomson <[email-masked]> wrote:
> 

Wait, what am I missing?

From appendix A.4 in TLS 1.3:

              +------------------------------+-------------+
              | Description                  | Value       |
              +------------------------------+-------------+
              | TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
              |                              |             |
              | TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
              |                              |             |
              | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
              |                              |             |
              | TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
              |                              |             |
              | TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
              +------------------------------+-------------+

So, how do we not have CCM in TLS 1.3 given that things like ECDHE and PSK are now orthogonal to ciphersuites?

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Feb 2017 19:11:56 +0200

On Wed, Feb 22, 2017 at 08:04:13AM +0000, Salz, Rich wrote:
> And leave it at that.  We're all quite proud of the fact, and
> deservedly so, that we only have three ciphers defined for TLS 1.3.
> Let's try to hold that position as long as possible.

Well, AES-128-CCM with 8 and 16 byte tags does exist in editor's
copy (0x1304 and 0x1305).

No AES-256-CCM tho.

-Ilari

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 23 Feb 2017 21:38:12 -0800

The difference between what is defined in 1.3 and this document is the 256
bit CCM cipher suites.   The document does not specify cipher suites for
TLS 1.3.

Is it important for TLS 1.3 to have support for these cipher suites?

If it is then we either need to add the cipher suites to this document or
to TLS 1.3.  At this point I would like to minimize the changes to 1.3,  so
I'm advocating that if the AES-256-CCM ciphers are necessary we update the
current document instead of TLS 1.3.  If the cipher suites are not
important then we should remove them from the document.

There is also confusion on what hash function to use with AES-256-CCM (it
seems it should be SHA384).

---

From: Yoav Nir <[email-masked]>
Date: Fri, 24 Feb 2017 09:52:41 +0200

> On 24 Feb 2017, at 7:38, Joseph Salowey <[email-masked]> wrote:
> 
> The difference between what is defined in 1.3 and this document is the 256 bit CCM cipher suites.   The document does not specify cipher suites for TLS 1.3.
> 
> If it is then we either need to add the cipher suites to this document or to TLS 1.3.  At this point I would like to minimize the changes to 1.3,  so I'm advocating that if the AES-256-CCM ciphers are necessary we update the current document instead of TLS 1.3.

I’d like to push back on that. It’s literally adding one or two lines (do we need a 256-bit version with an 8-byte tag?) to a table in Appendix A.4. The alternative is to make this document apply to 1.3.

Assuming 256-bit AES-CCM suites are needed, I think the better place to put them is in the TLS 1.3 document.

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 24 Feb 2017 14:07:19 +0000

> them is in the TLS 1.3 document.

That's a really big assumption. ;)

I think the burden is on folks to *prove* (yeah, I know) that additional cipher suites are needed.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 24 Feb 2017 14:55:30 +0000

> There's an argument that it's worth building in a 256-bit cipher for quantum resistance. Not clear that AES-256 is the best 256-bit cipher though.

Yes, I get that.

"not clear" is a highly uncompelling argument, tho.

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 24 Feb 2017 09:59:13 -0800

TLS 1.3 currently has AES-256-GCM and ChaCha20-Poly1305 as 256-bit
ciphers.  AES-CCM ciphers are more oriented towards an IOT niche where CCM
is implemented for lower layer protocols.  I'm not sure if there are
implementations of AES-256-CCM or AES-256-CCM_8  in use.

Joe

On Fri, Feb 24, 2017 at 7:12 AM, William Whyte <[email-masked]>
wrote:

> Right. I fee l strongly that it'd be wise to bless a single 256-bit cipher
> as part of the core TLS 1.3 family of techniques, but I don't feel strongly
> that it should be AES-256. ChaCha?
>
> Cheers,
>
> William
>
> On Fri, Feb 24, 2017 at 9:55 AM, Salz, Rich <[email-masked]> wrote:
>
>> > There's an argument that it's worth building in a 256-bit cipher for
>> quantum resistance. Not clear that AES-256 is the best 256-bit cipher
>> though.
>>
>> Yes, I get that.
>>

---

From: William Whyte <[email-masked]>
Date: Fri, 24 Feb 2017 10:12:17 -0500

Cheers,

William

---

From: William Whyte <[email-masked]>
Date: Fri, 24 Feb 2017 09:53:29 -0500

William

On Fri, Feb 24, 2017 at 9:07 AM, Salz, Rich <[email-masked]> wrote:

> > Assuming 256-bit AES-CCM suites are needed, I think the better place to
> put
> > them is in the TLS 1.3 document.
>