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

[Eric Rescorla <[e-mail]>]

On Sat, Jul 11, 2015 at 5:14 PM, Ilari Liusvaara <
[e-mail]> wrote:

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


This is just editor error.



> I thought only signature-capable ones
> do. Which would mean that certificate_types could be deprecated
> entierely.


Yes, I think i observed this before but just haven't gotten around to
updating
the spec to remove it.

-Ekr



>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>