On Sun, Oct 11, 2015 at 07:13:03PM -0400, Dave Garrett wrote:
> A wording change might be helpful here. Instead of no sending of SHA1 certs:
> 1) SHA1 signatures must not be trusted
Excellent.
> 2) servers must not send cert chains they do not trust
Pointless overreach that breaks things.
> Yes, I know you'll say that the client can of course trust things the
> server might not be able to, but the core of what I'm concerned about is
> servers making an attempt to get clients to accept a chain it knows very
> well is not trustworthy and thus encourage implementations to accept it
> anyway.
You're still ignoring the fact that in many environments the client
(correctly) does not validate the chain via trust-anchors of any
kind, so signatures of certificates by some "issuer" are of interest
to the client. There is no reason for the server to avoid sending
the chain even if some "signer" in the chain happened to use SHA-1.
At a minimum a leaf cert signed with SHA-1 may still be valid by
means other than trust of its signature.
> > They'll notice right away if the client stops trusting them and is doing
> > authentication.
>
> "if"
> If servers keep on sending SHA1 indefinitely, we risk clients keep on
> accepting SHA1 indefinitely, no matter what it says in the spec.
Some implementations might even ignore any misguided text telling
them to not send the chain. :-) We can't design for non-conformant
implementations. You sure want that cherry on top. However right
it might feel, it would still be counterproductive.
> > Once clients don't get to advertise SHA-1 in supported algorithms, servers
> > will use SHA-1 only when they have nothing else to offer.
>
> If servers still commonly send SHA-1, then clients will never stop offering
> support for it.
No, that conclusion is unwarranted. TLS 1.3 clients will not trust
SHA-1. All the key implementors are reading this interminable
thread. They understand the issues. If we get consensus for at
least the minimal version (no trust in SHA-1) we're done. There's
no reason for pessimism, we're not trying to deprecated deployed
functionality, there is no TLS 1.3 deployed base. We can start
"clean" and keep it that way.
> > Breaking opportunistic TLS connections typically leads to cleartext
> > fallback (not progress).
>
> Prohibiting TLS 1.3 implementations from using SHA1 certs does not break
> OE.
It does when the SHA-1 leaf certificate is pinned, and/or the server
has nothing else to send, and its clients rightly don't care.
> > Where's the win in you're proposing beyond a "feel good" posture that've
> > deprecated SHA-1 "harder".
>
> My goal is to have fewer systems using SHA1 within a reasonable timeframe.
That happens automatically in the minimal version of the PR.
1. Recall that the SHA-1 certs are not trusted by TLS 1.3
clients, so the vast majority of servers will need SHA2-256 certs.
2. Recall that public CAs are phasing out SHA-1 certs sooner
than a non-negligible number of systems is likely to deploy
TLS 1.3
> The current TLS 1.3 draft completely delegates that issue away in a manner
> which does not put any onus on servers to upgrade, instead relying entirely
> on unspecified outside forces to deal with the issue (e.g. CA/Browser
> Forum; clients hopefully saying no, eventually).
We've agreed to require clients to not trust SHA-1 signatures. That's
quite enough, and is a smaller, simpler change.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
