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 <bka...@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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
