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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
