[TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

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.