Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)

[Daniel Migault <[e-mail]>]

Hi Adam,

The text you mention is from version 04. Version 05 has been submitted, but
is somewhere in the datatracker. For some reason I am not able to confirm
the submission, so I have attached it to my response to Eric. The text of
the current version 05 is:

Yours,
Daniel
"""
4.     Applicable TLS Versions

   The cipher suites defined in this document MUST NOT be negotiated for
   any version of (D)TLS other than TLS 1.2.  Clients MUST NOT offer one
   of these cipher suites with a (D)TLS version that differs from TLS
   1.2.  Servers MUST NOT select one of these cipher suites with a TLS
   version that differs from TLS 1.2.  A client MUST treat the selection
   of these cipher suites in combination with a version of TLS as an
   error and generate a fatal 'illegal_parameter' TLS alert.




Mattsson & Migault      Expires November 24, 2017               [Page 3]
^L
Internet-Draft               ECDHE_PSK_AEAD                     May 2017


   TLS version 1.3 and later negotiate these features in a different
   manner.  Unlike TLS 1.2, TLS 1.3 separates authentication and cipher
   suite negotiation [I-D.ietf-tls-tls13] Section 1.2.  TLS 1.3 supports
   PSK with ECDHE key exchange and the cipher suites
   TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
   TLS_AES_128_CCM_8_SHA256 and TLS_AES_128_CCM_SHA256 are part of the
   specification.  As a result, TLS 1.3 and higher versions, negotiate
   and support these cipher suites in a different way.

   The cipher suites defined in this document make use of the
   authenticated encryption with additional data (AEAD) defined in TLS
   1.2 [RFC5246] and DTLS 1.2 [RFC6347].  Earlier versions of TLS do not
   have support for AEAD and consequently, the cipher suites defined in
   this document MUST NOT be negotiated in TLS versions prior to 1.2.
   In addition, it is worth noting that TLS 1.0 [RFC2246] and TLS 1.2
   [RFC4346] split the pre-master into two parts.  The PRF results from
   mixing the two pseudorandom streams with distinct hash functions (MD5
   and SHA-1) by exclusive-ORing them together.  In the case of
   ECDHE_PSK authentication, the PSK and ECDHE shared secret are treated
   by distinct hash function with distinct properties.  This may
   introduce vulnerabilities over the expected security provided by the
   constructed pre-master.  As such, all ECDHE_PSK ciphers, including
   those defined in this document, SHOULD NOT be negotiated in TLS
   versions prior to 1.2.
"""

On Tue, May 23, 2017 at 10:48 PM, Adam Roach <[e-mail]> wrote:

> On 5/23/17 9:33 PM, Daniel Migault wrote:
>
>> The current version does not consider that proposing the cipher suites of
>> the document implicitly assumes the client supports TLS1.2.
>>
>
> Really? Can you clarify the meaning of the following passage? Because I
> can't read it in any way other than to contradict your assertion above:
>
>
>    A server receiving a ClientHello and a client_version indicating
>    (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from
>    this document in ClientHello.cipher_suites can safely assume that the
>    client supports TLS 1.2 and is willing to use it.
>
>
>
> /a
>