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

[Ilari Liusvaara <[e-mail]>]

On Sat, Jul 11, 2015 at 08:48:10PM +0000, Viktor Dukhovni wrote:
> 
>     The public key in the leaf certificate must of course be
>     compatible with the chosen cipher-suite, and the subsequent
>     ServerKeyExchange message must be signed via a mutually supported
>     hash/signature algorithm pair.

Actually, it only needs to be compatible with ciphersuite if client
did not send signature_algorithms. If it did, then it needs to be
compatible with any algorithm pair signaled in that.

It also worked this way in TLS 1.2.


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.


Also, it occurs to me that analogous situation occurs with client
certificates. But there the rules are much less clear to me:

There are two fields that control supported certificate algorithms:
certificate_types and supported_signature_algorithms, both in
CertificateRequest.

Here's what TLS 1.2 says about interplay of those fields (and
TLS 1.3 wg-07 has very similar language, quite possibly exactly
the same):

"The end-entity certificate provided by the client MUST contain a
key that is compatible with certificate_types. If the key is a
signature key, it MUST be usable with some hash/signature
algorithm pair in supported_signature_algorithms."

Is say ECDSA key "compatible" with rsa_sign?


Also, it seems like TLS 1.3 draft allows fixed_dh certificate_types.
How would those even work? I thought only signature-capable ones
do. Which would mean that certificate_types could be deprecated
entierely. 


-Ilari