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

[Joseph Salowey]

The chairs are forwarding this document to our AD to progress towards
publication.

Cheers,

Joe

On Tue, Apr 11, 2017 at 8:21 AM, Joseph Salowey  wrote:

> Hi Daniel,
>
> Please submit a revised draft with the changes below.
>
> Thanks,
>
> Joe
>
>
> On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> 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
>> ]
>> 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/m
>> aster/draft-ietf-tls-ecdhe-psk-aead
>>
>> Yours,
>> Daniel and John
>>
>>
>> On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey  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 

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

[Daniel Migault]

Hi Joe,

Thanks for the reminder. I just posted it. Let me know if there is anything
I have to do.

Yours,
Daniel

On Tue, Apr 11, 2017 at 11:21 AM, Joseph Salowey  wrote:

> Hi Daniel,
>
> Please submit a revised draft with the changes below.
>
> Thanks,
>
> Joe
>
>
> On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> 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
>> ]
>> 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/m
>> aster/draft-ietf-tls-ecdhe-psk-aead
>>
>> Yours,
>> Daniel and John
>>
>>
>> On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey  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 

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

[Joseph Salowey]

Hi Daniel,

Please submit a revised draft with the changes below.

Thanks,

Joe

On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
daniel.miga...@ericsson.com> wrote:

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

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

[Daniel Migault]

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

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

[Yoav Nir]

> On 1 Mar 2017, at 15:06, Aaron Zauner  wrote:
> 
> 
>> On 24 Feb 2017, at 14:07, Salz, Rich  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.

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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Aaron Zauner]

> On 01 Mar 2017, at 14:29, Yoav Nir  wrote:
> 
> 
>> On 1 Mar 2017, at 15:06, Aaron Zauner  wrote:
>> 
>> 
>>> On 24 Feb 2017, at 14:07, Salz, Rich  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.
> 
> 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?

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


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

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  wrote:
> 
> 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.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Thomas Pornin]

On Wed, Mar 01, 2017 at 01:06:27PM +, 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Aaron Zauner]

> On 24 Feb 2017, at 14:07, Salz, Rich  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[William Whyte]

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.

William

On Fri, Feb 24, 2017 at 9:07 AM, Salz, Rich  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.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[William Whyte]

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  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.
>
> "not clear" is a highly uncompelling argument, tho.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

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 
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  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.
>>
>> "not clear" is a highly uncompelling argument, tho.
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

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



On Wed, Feb 22, 2017 at 9:11 AM, Ilari Liusvaara 
wrote:

> On Wed, Feb 22, 2017 at 08:04:13AM +, Salz, Rich wrote:
> > 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.
>
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Wed, Feb 22, 2017 at 08:04:13AM +, Salz, Rich wrote:
> 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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 22 Feb 2017, at 8:42, Martin Thomson  wrote:
> 
> 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

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___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

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.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

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  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
>
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls