Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

[[e-mail] (Martin Rex)]

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