4 ms·

So the TL;DR would be "because we don't want to make changes on current clients, we break compatibility for old clients where we cannot make changes"?

by pilif 11y ago

hyperpape 11y ago
Seems like this comment is based on a bad assumption. A lot of what you call "current clients" won't be updated either--they're new enough to not be stuck with SHA-1, but that doesn't mean they're getting updated anymore.
- sleevi 11y ago
  This is exactly correct. 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-updates-to-certificate-verification-in-gecko/ 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.

So the TL;DR would be "because we don't want to make changes on current clients, we break compatibility for old clients where we cannot make changes"?

by pilif 11y ago

So the TL;DR would be "because we don't want to make changes on current clients, we break compatibility for old clients where we cannot make changes"?

hyperpape 11y ago

Seems like this comment is based on a bad assumption. A lot of what you call "current clients" won't be updated either--they're new enough to not be stuck with SHA-1, but that doesn't mean they're getting updated anymore.

sleevi 11y ago
This is exactly correct. 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-updates-to-certificate-verification-in-gecko/ 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.