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 03:00:40 pm Viktor Dukhovni wrote:
> On Sat, Jul 11, 2015 at 02:32:29PM -0400, Dave Garrett wrote:
> > ==============================
> > 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.

I was going based on Ilari's comments here:
https://www.ietf.org/mail-archive/web/tls/current/msg17022.html

The only scenario where having an EE cert that can't sign anything would be useful is opportunistic encryption. Using anon ciphers sounds better, but I guess attempting auth allows trust on first use so I agree that transmitting certs could be useful here.

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

We don't really have an official definition of what constitutes a "default" chain here.

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

I was also going with RECOMMENDED/MAY language based on ekr's recent comments.

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

I think the rope, as you put it, needs to be there in some form. On the public Internet, yes, I can see your point. In a more tightly controlled system with a potentially constrained environment, I don't see the point in forcing the server to send down certs that the admin can 100% know will just waste bandwidth and processing. So, SHOULD/RECOMMENDED is the level that I think this'll need to be at.

I think I understand all of your argued reasons better now. I'll come up with some replacement language that takes them into account.


Dave