Hi, So I have propose a fall back to the latest version. However, if we agree this is a better approach, I am fine adding it to the document.
Yours, Daniel On Tue, May 23, 2017 at 3:34 PM, Martin Rex <m...@sap.com> wrote: > Adam Roach wrote: > > draft-ietf-tls-ecdhe-psk-aead-04: No Objection > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with EKR's discuss -- specifying semantics for these ciphersuites > > with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in > > which servers are encouraged to infer 1.2 support even in the absence of > > explicit indication) is a bit baffling. > > It encourages (but does not require) servers to infer 1.2 support > from _very_explicit_ information: the offering of TLSv1.2-only TLS > ciphersuites is the very same TLS ClientHello handshake message. > > We know since rfc5746 that the most reliable scheme to indicate support > for certain TLS protocol features is a cipher suite value. It is far > from rocket science to infer support for 1.2 from 1.2-only cipher > suite codepoints in ClientHello.cipher_suites. > > > > I just realized that I suggested removal of a description of client > behaviour that can, and should remain in the document (I'm sorry): > > 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. > > > -Martin >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
