Re: [TLS] secdir review of draft-ietf-tls-ecdhe-psk-aead-03

[Daniel Migault <[e-mail]>]

Hi Martin,

Thank you for the proposed text. It was very clear and I took it entirely,
just changing s/TLSv1/TLS 1/.

Yours,
Daniel


The current text is as follows:
<section title="Applicable TLS Versions">


<t> The cipher suites defined in this document MUST NOT be negotiated
for any version of (D)TLS other than TLS 1.2.</t>

<t> 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 <xref target="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. </t>

<t>The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS 1.2
<xref target="RFC5246"/> and DTLS 1.2 <xref target="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
<xref target="RFC2246"/> and TL1.2 <xref target="RFC4346"/> splits the
pre-master in two parts. The PRF results of 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
pre-master 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 TLS 1.0 and
TLS 1.1 SHOULD NOT be used with ECDHE_PSK.</t>

<t>A client that offers the cipher suites from this document in
ClientHello.cipher_suites in combination with (3,1) "TLS 1.0" or (3,2)
"TLS 1.1" in ClientHello.client_version MUST support TLS 1.2 and MUST
accept the server to negotiate TLS 1.2 for the current session.  If the
client does not support TLS 1.2 or is not willing to negotiate TLS 1.2,
then this client MUST NOT offer any of these cipher suites with a lower
protocol version than (3,3) "TLS 1.2" in ClientHello.client_version.</t>

<t>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. The server MUST NOT
negotiate these cipher suites with TLS protocol versions earlier than
TLS 1.2. Not requiring clients to indicate their support for TLS 1.2
cipher suites exclusively through ClientHello.client_hello improves the
interoperability in the installed base and use of TLS 1.2 AEAD cipher
suites without upsetting the installed base of version-intolerant TLS
servers, results in more TLS handshakes succeeding and obviates fallback
mechanisms.</t>


On Fri, May 19, 2017 at 10:17 AM, Martin Rex <[e-mail]> wrote:

> Benjamin Kaduk wrote:
> >
> > Some other editorial nits follow.
> >
> > In section 4, "these cipher suites MUST NOT be negotiated in TLS
> > versions prior to 1.2" should probably clarify that "these" cipher
> > suites are the new ones specified by this document.
>
>
> This reminds me of the specification goofs in several TLSv1.2-related
> documents about AEAD cipher suites which are responsible for the viability
> of the POODLE attack and other exploitable fallback hacks.
>
> It would be much preferable to avoid/fix those problems and facilitate
> the migration to and use of TLSv1.2 without failing TLS handshakes and
> band aids such as TLS_FALLBACK_SCSV
>
>
> Suggested improvement:
>
>    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, these cipher suites MUST NOT
> -  be negotiated in TLS versions prior to 1.2.  Clients MUST NOT offer
> -  these cipher suites if they do not offer TLS 1.2 or later.  Servers,
> -  which select an earlier version of TLS MUST NOT select one of these
> -  cipher suites.  A client MUST treat the selection of these cipher
> -  suites in combination with a version of TLS that does not support
> -  AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
> -  'illegal_parameter' TLS alert.
> +                                               A client that offers
> +  the cipher suites from this document in ClientHello.cipher_suites
> +  in combination with (3,1) "TLSv1.0" or (3,2) "TLSv1.1" in
> +  ClientHello.client_version MUST support TLSv1.2 and MUST accept
> +  the server to negotiate TLSv1.2 for the current session.  If the
> +  client does not support TLSv1.2 or is not willing to negotiate TLSv1.2,
> +  then this client MUST NOT offer any of these cipher suites with a
> +  lower protocol version than (3,3) "TLSv1.2" in
> ClientHello.client_version.
> +  A server receiving a ClientHello and a client_version indicating
> +  (3,1) "TLSv1.0" or (3,2) "TLSv1.1" and any of the cipher suites from
> +  this document in ClientHello.cipher_suites can safely assume that the
> +  client supports TLSv1.2 and is willing to use it.  The server MUST
> +  NOT negotiate these cipher suites with TLS protocol versions earlier
> +  than TLSv1.2.
> +
> +  Not requiring clients to indicate their support for TLSv1.2 cipher
> +  suites exclusively through ClientHello.client_hello improves the
> +  interoperability in the installed base and use of TLSv1.2 AEAD
> +  cipher suites without upsetting the installed base of version-intolerant
> +  TLS servers, results in more TLS handshakes succeeding and obviates
> +  fallback mechanisms.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>