SHA-1 Certificates: A History of Hard Choices
medium.com
medium.com
Wouldn't that be enough already? Newer clients wouldn't be able to access sites that exclusively serve SHA-1 certificates, so that's the loss of the site-owner to only and unconditionally present the SHA-1 cert. IMHO no special handling on the side of the CA is required here.
I see no potential for a downgrade attack because a current client would only support SHA-2 anyways, so trying to MITM the connection to pretend the client supporting only SHA-1 in order to induce the server to present the SHA-1 cert would only lead the the up-to-date client to reject the connection.
However, if the site presents a SHA-2 cert where possible, falling back to the SHA-1 cert, then old and unsupported clients would still be able to access the site. Yes, the security would be reduced and it would certainly not be sufficient to protect against state-sponsored attacks, but it's still way better in protecting against FireSheep-like attacks done by individuals.
The problem is that most clients currently are not able to build up multiple trust chains. They hand OpenSSL the certificates the remote server gave them, a pile of root certs, and say "tell me if you can build a trust chain". To remove SHA1 support, they'd have to inspect the returned trust chain and check whether any certs have SHA1 signatures. If they do, you'd fail outright, even though there may have been a perfectly good SHA2-only path available that OpenSSL didn't take, because there's no way to tell OpenSSL "try again but don't use this cert".
This means that we're telling the 97% of users with "modern" clients to force all TLS stacks to add support for new path building logic with arbitrary certificate avoidance in order to avoid the pain of the 3% of users who didn't get upgrades.
Note that I said "OpenSSL" here, but it actually applies to a wide range of TLS stacks: OpenSSL is just one of the more widely deployed ones.
Also, this feels like the kind of thing which might happen again -- worth trying to get backwards compatibility right.
It's definitely an interesting idea to allow constraints to be set on what certificates can be used during chain construction, but the scope of the problem is very large: there are lots of fields in an X509 certificate, many with complex values that complex filtering may want to be done on. In principle this can be done using callbacks from OpenSSL, but because of the potential up-and-down nature of building these trees there will be a substantial amount of complexity in place.
And the reality is that backward compatibility is already right. OpenSSL, today, is backward compatible with SHA1 certs. The problem here is forward compatibility: making older SSL stacks meet the security requirements of the modern day, many years after they were written. That's hard, and may actually be impossible.
The answer is that we should build better routing into OpenSSL - and all the other PKI-validating products. It's complex and complicated, but if you only have a very narrow and particular purpose (e.g. just care about TLS), then you can get away with it with rather a little amount of code, as Mozilla's mozilla::pkix shows - https://blog.mozilla.org/security/2014/04/24/exciting-update...
But even if we were to change all systems tomorrow, that affects only the upper 10% or, to be generous, 25% of PKI clients (nb: numbers pulled out of my ass, but it's an experienced ass). We still have a LONG tail of systems running OpenSSL, earlier versions of Windows, or any number of custom solutions, and they support SHA-256 but won't ever be updated again. So stopping SHA-1 actually protects them, and is the only thing that CAN possibly protect them, and that's why LV is such a hard trade-off: we give up the protections for a large chunk of users, in order to regain access to a small group.
And that's ignoring that the data quantifying the size of the small group, or _why_ the small group exists (to see if there are other levers or alternatives than "replace device" and/or "keep issuing SHA-1" exist. Luckily, Jan 1 isn't going to be some SHApocolypse - 39 month certs issued on Dec 31 2015 will remain valid well into 2019, so there's time to have a reasoned, data-driven debate about "old-old" clients, "new-old" clients, and "new-new" clients.
That right there tells you everything you need to know about XPKI and the CA infrastructure. It's sad that a decade before the event above took place, we had a reasoned, well-thought-out alternative to XPKI, but because no-one cared it went absolutely nowhere.
I really, really hope that after these lost two decades the industry revisits and updates the ideas behind SPKI[1] and finally figures out how to actually secure Internet communications. Can't say that I'm holding my breath though.
There were some concerns that the larger keys could cause issues with some network equipment, but it looks like those concerns were overblown. Network engineers are a fairly conservative bunch and, perhaps contrary to your expectations, there are real systems in the real world that would break if the root zone broke. These systems tend not to be web, so they might not be as visible to an end user perhaps.