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

[Dave Garrett <[e-mail]>]

On Saturday, July 11, 2015 11:17:29 am Viktor Dukhovni wrote:
> On Sat, Jul 11, 2015 at 09:55:45AM -0400, Eric Rescorla wrote:
> > Perhaps the right text here is that if you have a conformant certificate,
> > you MUST send it, but if not, you MAY send a nonconformant one?
> 
> Correct.  It is important to try to match a supported algorithm,
> but failing that, send what you have.  It may well work just fine
> for the client, since the signatures in question are not made in
> real-time by the server, but rather at some previous time by some
> CA, which the client may not care about (pinned leaf cert, DANE
> leaf cert, opportunistic TLS, ...).
> 
> And the point about debugging also makes sense.  The client
> administrator can much more easily determine which additional
> algorithm is required to interoperate with the server.

Ok, draft language for new behavior here:

==============================
If a server receives a ClientHello, but the server cannot produce a valid
end-entity certificate using the hash/signature pairs known to be supported by
the client (via this extension or the defaults assumed in its absence),
then the server MUST send an "unsupported_certificate" alert message and
close the connection. In the event that a server can produce a valid end-entity
certificate known to be supported by the client, however the known supported
hash/signature pairs are insufficient to produce a known valid certificate
chain, the server is RECOMMENDED to send a complete valid certificate chain
which attempts to use supported hash/signature pairs where possible yet
includes certificates with unknown client support. If the client cannot build
a trusted chain using these certificates and any other trusted information it
has access to, then it MUST send an "unsupported_certificate" alert message
and close the connection. The server MAY instead choose to simply send an
"unsupported_certificate" alert message and close the connection.
==============================

Sound viable?

(this might be a bit too wordy, though; the wording throughout the document about fatal alerts could probably be simplified a bit)

I pushed the above to the morealerts WIP branch.


Dave