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

[Joseph Salowey <[e-mail]>]

Hi Daniel,

Please submit a revised draft with the changes below.

Thanks,

Joe

On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
[e-mail]> 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
> <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
>>
>>
>