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

Hi Benjamin and Dave,

Thanks for the clarification. Considering also Roman' s and Ben' s comments
the section is built as follow. 1) Limit cipher suites to TLS1.2, 2)
explain how TLS1.3 and higher version negotiate them 3) bring all
explanation foe the previous versions.

Yours,
Daniel

The text is as follows:

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

<t> TLS version 1.3 and later negotiate these features in a different
manner. Unlike TLS1.2, TLS1.3 separates authentication and cipher suite
negotiation <xref target="I-D.ietf-tls-tls13"/> Section 1.2. TLS1.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 TLS1.0
<xref target="RFC2246"/> and TL1.2 <xref target="RFC4346"/> splits teh
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 TLS1.0 and
TLS1.1 SHOULD NOT be used with ECDHE_PSK.  Clients MUST NOT offer these
cipher suites defined in this document if they do not offer TLS 1.2 or
later. Servers that 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.</t>

On Fri, May 19, 2017 at 10:39 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:

> On 05/19/2017 02:16 AM, Dave Garrett wrote:
>
> On Friday, May 19, 2017 12:38:27 am Benjamin Kaduk wrote:
>
> 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.
>
> Probably should be: "the cipher suites defined in this document
> MUST NOT be negotiated for any version of TLS other than 1.2."
>
> The sentence mentioning TLS 1.3+ could be moved up to right after
> and just say: "TLS version 1.3 and later negotiate these features in
> a different manner."
>
>
>
>
> That's probably best, yes.  The interaction between this document and TLS
> 1.3 is a little weird, and it's not entirely clear to me that this one
> needs to say much of anything about TLS 1.3, given that TLS 1.3 changes all
> the relevant messages and key hierarchy and such.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>