Andrei Popov wrote: > I'm not happy with this either. I liked that proposal.
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. While this may seem true, the problem that you're ignoring here is that it changes the original meaning&semantics of ClientHello in a backwards-incompatible and undesirable fashion, which creates either an interop failure or a security problem or both. In TLS up to TLSv1.1, the absence of a TLS signature_algorithms extensions indicates *ONLY* the algorithm that has to be used a the TLS protocol layer (for digitally-signed), and it says *NOTHING* at all about the algorithms that may be used within certificates. As you might know, support for server certificates signed with sha256WithRsaEncryption was added to Windows XP with Service Pack 3 (21-Apr-2008) and into Windows 2003 with KB938397. So the lack of a TLS signature_algorithm extension ought to apply semantics exclusively to "digitally-signed". Applying any restrictive semantics to server certifcates is a backwards-incompatible dumb idea (in rfc5246) that needs to be fixed. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
