I'm not happy with this either. The spec already says: "If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key exchange), it MUST send the signature_algorithms extension, listing the algorithms it is willing to accept."
This seems to be pretty clear: if the client properly advertises the algorithms it supports, then the handshake has a deterministic outcome. Cheers, Andrei -----Original Message----- From: TLS [mailto:[email protected]] On Behalf Of Dave Garrett Sent: Saturday, July 11, 2015 4:29 PM To: Eric Rescorla Cc: [email protected] Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek) On Saturday, July 11, 2015 07:18:01 pm Eric Rescorla wrote: > I'm not happy with this. There should be a MUST-level requirement to > provide a conformant chain if possible. Yeah. "SHOULD" & "where possible" aren't both needed. We only really want one or the other. I'll change it to "MUST" & "where possible". Dave _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
