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