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

[Viktor Dukhovni <[e-mail]>]

On Sat, Jul 11, 2015 at 02:32:29PM -0400, Dave Garrett wrote:

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

[ Reordered, feedback question before draft language ]

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

Not really viable, and yes, much too wordy and not quite right:

> ==============================
> 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.

The signature of the leaf certificate is just as irrelevant as
signatures up the chain.  With pinned leaf certificates, DANE-EE(3),
opportunistic TLS, ... even the leaf (end-entity) certificate
signature algorithm is of no consequence and is ignored by the
client.

Therefore, this qualification is not needed, and the server SHOULD
NOT send any alert or close the connection even when the client's
supported signature algorithms do not include the signature algorithm
used for some certificate in the chain (regardless of depth).
Instead the server MUST send whatever chain it has whose leaf public
key is compatible with the agreed cipher-suite.  (The server of course
chooses the agreed cipher-suite to make the last condition true). 

If at all possible, the server SHOULD choose a chain all of whose
signatures (excluding any self-signed root CAs) match the client's
signature algorith list.  If that's not possible, it SHOULD send
a default chain (often the only chain it has) with a compatible
public key.

[ Of course, perhaps worth mentioning, none of this applies with
RFC 7250 raw-public-keys, because there is no chain or signatures
to send, the server just sends its SPKI public key per RFC 7250. ]

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

As above: s/RECOMMENDED/SHOULD/.  It is NOT up to the server to decide
which chains the client can accept.  The server has insufficient
information, and therefore SHOULD NOT preempt the client's decision
of whether the chain works or not.

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

If the client chooses to authenticate the server's chain (i.e.
not unauthenticated opportunistic TLS) and fails to do so because
it does not support  the signature algorithm in one or more
certificates that are needed for said authentication, then it
MUST send ...

> The server MAY instead choose to simply send an
> "unsupported_certificate" alert message and close the connection.

No, the server SHOULD NOT preempt the client's decision.  I'd
personally prefer MUST NOT, but there are arguably servers whose
clients are all known to never use trust on first use certificate
pinning, DANE, unauthenticated opportunistic TLS, ...

If we need to weasel out and give some servers the choice to lock
out all clients that do anything remotely unorthodox, then SHOULD
NOT provides some rope.  I think such weaseling out is likely to
do more harm than good, but I'm open to concede the rope if need
be.

On the public Internet, such servers will be few and far between,
and the choice to preempt the client should not be a default choice
made by the TLS library.  If some particular application wants to
limit client support, that choice needs to be explicitly signalled
to the TLS library.

-- 
	Viktor.