[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Thu Aug 22 10:45:45 MST 2019

  *   Unfortunately, this is a bit like arguing it's best not to apply security patches until you're exploited. I understand that we'll not see eye-to-eye here, and that's OK. I'm concerned about ensuring our users, and the Internet at large, is sufficiently secure and robust when CAs mess up, which they do on a regular basis, and to minimize the impact to any organization: both those using that CA, and which may need to respond accordingly, and those that may not be using it, but nevertheless placed at risk by such CAs.

I don’t say, not to do anything. But if there are other measurements, which don’t enforce enterprises to adopt a not yet proven (and for reasons rejected) way of performing “updates” (which finally also updating certs is), in this kind automation, it’s better to choose such measurements. Additional, if it’s not proven, that this measurement will have the effect, which should be provided by this measurement, if it’s just “in case”, again, it’s better to work on alternatives. Not to do nothing, but if it has such strong effect, effort and impact, it’s worth to work on alternatives. It’s the lowest hanging fruit chosen here, but that’s typically not the best solution.

  *   This is a much needed, preventative measure. It's unconscionable to suggest that it's inappropriate to take measures that are known to secure users are sites, and instead wait for the compromises, which happen on a regular basis.

Thanks for confirming, that it’s a preventive measure. Preventive measures should reduce probability meanwhile reactive measures should reduce impact. But there are much better measures, which are detective measures, so there is no need to reduce probability, if there are measures in place, which increase detection probability. That’s well established information security management. I provided you a set of ideas for detective measurements, which outweight this preventive measurement at all. You confirm, that it’s just for in case, and to follow the argumentation, it could only work, if you reduce the lifetimes much more than 1 year, so you end up in the requirement for automation again.

  *   You are correct. Browsers do not trust audits to detect or prevent these issues. Audits are not a preventative measure, they are defense in depth. There have been multiple auditing firms that have been distrusted from providing audit reports to browsers, and there have been years of efforts to improve these issues. However, audits are merely a component of a holistic security story. Relying on audits alone is not, nor has it ever been, a sensible security practice.

Thanks again for confirming. Any management system is based on audits, any IAF organized ISO certification is based on audits. So if the audit system does not work in your point of view, it should be improved. Auditors need to be chosen on a trust base, otherwise all this audit scheme is unusable. In the ISO environment it has been shown, that it’s possible to setup a valuable system, so this topic should be worked on as again, it’s the primary issue and no low hanging fruit of a quick actionism fix, it’s a real fix on the real pain point. For sure, audits are just showing the current state and there need to be ongoing measurements(!), but also this one should be set to work on the primary issue and not walking around and just use the best picking low hanging fruit.

  *   I think your frustration may be a misunderstanding of audits and the goals and value they provide, which is understandable.

If audits won’t provide any value, I won’t think, that this ecosystem exist or have any value, so that governments, companies etc. require others to be audited against. For sure again, audits aren’t solely the one and only measurement, but if they are not trustable, it’s a bit confusing and it need to be improved. And for sure, other factors could be added as well, as CT did, as CAA did, so you also don’t trust this measurements?

  *   As noted, "correction" involves both addressing existing certificates that exist out there and having CAs ensure no new certificates with the issue are issued. Addressing existing certificates is /only/ reliably addressable on the Internet via expiration. No other technology has been shown to be consistency reliable for a wide-variety of users, on a wide variety of networks. I would be shocked if the organizations opposed to this would find it acceptable if all of their user data may be accessible or exposed for 27 months, and yet that is the current risk. Similarly, I would be shocked if organizations opposed found it acceptable that an attacker who compromised their system for a few minutes would be able to persist the attack, and attack all traffic, for 4.5 years. Yet that is the world today.

Again, therefor revocation as a mechanism exist and if it’s not working well (yet), it need to be improved. Expiration is no correction mechanism, as otherwise you run in the infinite loop of being forced by yourself to lower down validity period down to days, hours, minutes to be able to fix a few minutes attack for the next minute, latest hour or day. Otherwise, you will, if using your word, stay your internet browser users at risk always (validity period timeframe minus risk detection period), so you will always be in trouble until you end up in days or hours, and that really looks confusing and that this measurements doesn’t look like valuable.

So are you able to provide the validation period, you expect, at the end, would be able to fix the problems you arise? Improving certificate lifetimes by reducing looks like a process being kicked off, which should have an expectable end but is still working on. In the discussions two years ago, there I’m still not seeing any positive result of reducing lifetime from 3 to 2 years, I remember I read anything about days (7 or sth. like that), is this the goal, you’re working on?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/6b81ee86/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3860 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190822/6b81ee86/attachment-0001.bin>