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 03:36:49PM -0400, Dave Garrett wrote:

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

Not, not "can't signed anything" rather "is signed *by* its issuer
via an unsupported signature".  The server's public key is not
constrained to use the same signature algorithm that signed its
certificate.  Indeed it must, for example, sign EDH/EECDH parameters
with an algorithm that is supported by the client.

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

Whatever the server cares to use.  Implementation dependent.  Using something
minimally exotic would be wise, but I don't the standar can or should specify
how to choose.

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

That would be wrong.  It really MUST or at least SHOULD continue
the handshake.

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

I'll settle for SHOULD.

-- 
	Viktor.