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

[Daniel Migault <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>