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:09 PM, Dave Garrett <[e-mail]>
wrote:

> On Saturday, July 11, 2015 04:48:10 pm Viktor Dukhovni wrote:
> > Largely close enough.  Feel free to borrow any text from the below
> > that you find to be an improvement.
> >
> >     ========================================
> >
> >     Whenever possible, all certificates provided by the server
> >     SHOULD be signed by a hash/signature algorithm pair indicated
> >     by the client's supported algorithms extension (or the defaults
> >     assumed in its absence).  If the server cannot produce a
> >     certificate chain that is signed via only the indicated supported
> >     pairs, then it SHOULD continue the handshake by sending the
> >     client a certificate chain of its choice that may include
> >     hash/signature algoriths that are not known to be supported by
> >     the client.
> >
> >     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.
> >
> >     If the client cannot construct a satisfactory chain using the
> >     provided certificates and decides to abort the handshake, then
> >     it MUST send an "unsupported_certificate" alert message and
> >     close the connection.
> >
> >     ========================================
>
> The middle bit is already in existing text above the section in question.
>
> New version with a little rewording and a typo fix.
>
> \/
>
> ========================================
> All certificates provided by the server SHOULD be signed by a
> hash/signature algorithm pair indicated by the client's
> "signature_algorithms" extension (or the defaults assumed in
> its absence), where possible. If the server cannot produce a
> certificate chain that is signed only via the indicated supported
> pairs, then it SHOULD continue the handshake by sending the
> client a certificate chain of its choice that may include algorithms
> that are not known to be supported by the client. If the client
> cannot construct an acceptable chain using the provided certificates
> and decides to abort the handshake, then it MUST send an
> "unsupported_certificate" alert message and close the connection.
> =======================================
>

I'm not happy with this. There should be a MUST-level requirement to provide
a conformant chain if possible.

-Ekr



>
> Dave
>