Andrei Popov wrote: > > I think a good design is to have the client explicitly advertise any > algorithms the client is willing/able to support, and for the server > to honor the client's capabilities.
A good design provides robust interop and good backwards-interoperability, and a reasonble default set of algorithms to be unconditionally available. Why TLSv1.2 did imply availability of sha256WithRsaEncryption by default, is beyond my understanding. The rfc5246 PDU Definition for ClientHello clearly makes HelloExtensions and optional (MAY) feature for clients and the acceptance of extension-less ClientHellos a mandatory (MUST) feature for Servers. Similarily, Appendix E allows the use of a SSL Version 2 CLIENT-HELLO instead of and extension-less TLS ClientHello, It has already been observed by others, a server can not make up signatures with client-requested signature schemes at will during the TLS handshake, but can only pick from the set of existing server certificates that have been preconfigured by the server admin -- and often this may be just one single server certificate. The server responding with an ambiguous "handshake_failure" if the admin-configured server cert does not fit the silly "implicit" algs that a server boldly assumes based on the design-flawed wording in rfc5246 7.4.1.4.1 in absence of ClientHelloExtensions is is a bad idea, and if the client-visible behaviour is a silent connection closure (this is what Microsoft IIS does) it is the worst possible outcome. This behaviour is completely indistinguishable from that of defective extensions-intolerant and TLS-version intolerant servers! Would the server respond with the next best fit (the way this has been and still is being done, even by Microsoft SChannel, for SSLv3, TLSv1.0 and TLSv1.1), then the client can at least produce a meaningful error message and show the certificates that it can not process. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
