Eric Rescorla has entered the following ballot position for draft-ietf-tls-ecdhe-psk-aead-04: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The following text appears to have been added in -04 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. This is a major technical change from -03, which, AFAIK, prohibited the server from negotiating these algorithms with TLS 1.1 and below and maintained the usual TLS version 1.2 negotiation rules. This is a very material technical change. I don't consider it wise, but in any case it would absolutely need WG consensus, which I don't believe that it has given the recent introduction. The discussion of dictionary attacks here seems inferior to that in 4279. In particular, you only need to actively attack one connection to capture the data you need for a brute force attack despite the text there referring to trying "different keys". Please correct that. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The citations to TLS 1.3 still seem pretty muddled. I think you should just stop referencing and discussing 1.3. S 2. I'm not sure that the discussion of the PRF is helpful here in mandating the non-use of these cipher suites with TLS 1.1 and below. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
