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

[[e-mail] (Martin Rex)]

Ilari Liusvaara wrote:
> 
> E.g. if client advertised {sha256, ecdsa} + <others> in its
> signature_algorithms and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> + others in its ciphersuites, then the server MAY pick
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and then proceed to
> sign the handshake with ECDSA/SHA-256. Despite there being
> no DHE_ECDSA ciphersuites.

Which part of which RFC makes you believe that such weird
behaviour would be allowed?

The key exchange algorithm in the TLS cipher suites requires
a specific kind of asymmetric key in the server certificate.

A DHE_RSA key exchange requires a server certificate with an RSA key.

The key of the CA that signed the server certificate ought to be
irrelevant -- it *WAS* irrelevant in SSLv3, and the words in rfc2246
that suggest otherwise are a defect in rfc2246 (a defect, for which
I haven't yet seen an implementor who got it wrong and implemented
it in the obviously bogus fashion that rfc2246 suggests).


-Martin