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'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