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

From: Aaron Zauner <[email-masked]>
Date: Wed, 1 Mar 2017 13:06:27 +0000

> On 24 Feb 2017, at 14:07, 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.
> 
> That's a really big assumption. ;)
> 
> I think the burden is on folks to *prove* (yeah, I know) that additional cipher suites are needed.

+1. I'm against adding CCM based suites to the TLS 1.3 spec.

(I may be biased having worked on the OCB cipher-suite spec and patent exemptions for TLS - but for example; these were only aimed at TLS 1.2 at that time. I don't see why the IoT/embedded-world can't make use of ChaCha/Poly in future implementations?)

Aaron

---

From: Thomas Pornin <[email-masked]>
Date: Wed, 1 Mar 2017 14:57:54 +0100

On Wed, Mar 01, 2017 at 01:06:27PM +0000, Aaron Zauner wrote:
> I don't see why the IoT/embedded-world can't make use of ChaCha/Poly
> in future implementations?

IF the embedded platform is "generic" (say, it's an ARM Cortex M0+),
then ChaCha20 is faster than anything using AES. Poly1305 is less clear
because it relies on multiplications and multiplications can be
expensive on small microcontrollers; in my own tests with my own
implementations, ChaCha20 and Poly1305 run at roughly the same speed on
a Cortex M0+ (with the 1-cycle multiplier option). Even a table-based
AES (that is, formally "not constant-time", though on a cache-less
microcontroller it might be fine nonetheless) will be about twice
slower. Similarly, the GHASH part of GCM will be slower than Poly1305
(unless you use big key-dependent tables, which is not constant-time but
also rarely doable in small embedded systems, where RAM is a very scarce
resource).

HOWEVER, there are some microcontrollers with hardware acceleration for
AES, e.g. the ESP32 (a popular micrcontroller-with-WiFi) has some
circuitry that can do an AES block encryption in 11 clock cycles, which
is much faster than ChaCha20. Moreover, in the presence of such
hardware, CCM will also be much faster than GCM, the GHASH part becoming
prohibitively expensive (relatively to encryption). The push for CCM
mainly comes from that kind of hardware.

(EAX mode might be even preferable on AES-able hardware, but CCM has
a stronger legacy foothold.)

	--Thomas Pornin

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Mar 2017 14:28:36 +0000

You know what amazes about IoT?  No matter what someone tries to do there is a chip/SoC out there that can't do it.

Shrug.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Mar 2017 16:29:09 +0200

> On 1 Mar 2017, at 15:06, Aaron Zauner <[email-masked]> wrote:
> 
> 

Hold on.  CCM with a 128-bit key suites are already in the current version of the spec. CCM with a 256-bit key suites are not.

Are you advocating just not adding the 256-bit key ciphersuites, or removing those already in?

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Mar 2017 16:33:19 +0200

And they all cost 10 cents a piece, never get updated, and control the floodgates that hold back the biblical flood.

> On 1 Mar 2017, at 16:28, Salz, Rich <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 1 Mar 2017 14:35:11 +0000

> On 01 Mar 2017, at 14:29, Yoav Nir <[email-masked]> wrote:
> 
> 

Both. I don't see why we need to keep legacy cruft around in a new protocol because of some embedded corner case, sorry.

Also, OCB would be much faster as it's is a single-pass scheme (and all patent restrictions that had been the reason CCM was initially invented anyway have been resolved for TLS), but for the sake of not ending up with countless cipher-suites again I'm not advocating adding that either.

Also: what Rich Salz said.

Aaron

---

From: Daniel Migault <[email-masked]>
Date: Tue, 21 Mar 2017 14:08:20 -0400

Hi,

Thank you for the review and comments received. Given the discussion our
understanding was that the consensus was to remove CCM-256 so that suites
defined by the document apply both for TLS1.2 as well as for TLS1.3. The
draft available on github [1
<https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/master/draft-ietf-tls-ecdhe-psk-aead>]
has been updated as follows:

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)

MGLT: This was a mistake in the IANA section. The cypher suite was correct
in the remaining text. However, the current version does not  consider
anymore CCM-256* which also solves this issue.

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

MGLT: The issue of human chosen passwords and dictionary attacks has been
mentioned in the security consideration with the following text:

"""
   Use of Pre-Shared Keys of limited entropy may allow an active
   attacker attempts to connect to the server and tries different keys.
   For example, limited entropy may be provided by using short PSK in
   which case an attacker may perform a brute-force attack.  Other
   example includes the use of a PSK chosen by a human and thus may be
   exposed to dictionary attacks.
"""

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.

MGLT: CCM-256 has been removed from the specification so that suites can be
defined for TLS 1.2 as well as TLS1.3. The following text is considered.

"""
   This document defines new cipher suites that provide Pre-Shared Key
   (PSK) authentication, Perfect Forward Secrecy (PFS), and
   Authenticated Encryption with Associated Data (AEAD).  The cipher
   suites are defined for version 1.2 of the Transport Layer Security
   (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
   Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
   [I-D.ietf-tls-tls13].
"""

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)

MGLT: As CCM-256 has been removed, we do not have to deal with the
situation where TLS1.3 only considers a subset of the suites defined for
TLS1.2.

The following sentence in section 3 clarifies that codes points are only
defined for TLS1.2: “””The assigned code points can only be used for TLS
1.2.”””. The description of the TLS1.3 negotiation has been limited in
section 4 to the following sentence: “””TLS 1.3 and above version,
negotiate and support these cipher suites in a different way.”””

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]."

MGLT: The sentence mentioned above has been added with [4492-bis] mentioned
as normative.
“””
    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
   [I-D.ietf-tls-rfc4492bis].
“””

[1]
https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/master/draft-ietf-tls-ecdhe-psk-aead

Yours,
Daniel and John

On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey <[email-masked]> wrote:

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