[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

Tue Aug 20 10:23:05 MST 2019

Hi,

On Tue, Aug 20, 2019 at 10:33 AM Christian Heutger via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
Against phishing or other certificate misuse 1 year won’t help, 90 days also won’t help (I got some spam with a Let’s Encrypt cert and this phishing site was operated for the full 90 days), you need to reduce lifetime to day or better hours. Is this really an idea, which could work? Also if automation would be able to handle that, it will arise additional new pain points. And still it arise the question, is it worth to fix a completely different issue?

I'm not sure, could you highlight where you heard that this was meant to address phishing? https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html certainly doesn't list that as a motivation, and that has never been a motivation with this ballot from any of the proponents, so perhaps you received inaccurate information?

I mentioned phishing as the most popular certificate misuse. But I can refer to all your points:

* Issues that result from the misinterpretation or misapplication of the Baseline Requirements are able to be more promptly resolved. Despite the best efforts of Browsers to ensure unambiguous requirements, there continue to be issues with CAs and their understanding and successful implementation of existing requirements. At present, due to the fact that validations may be reused for up to 825 days, and when they are reused, may be used to issue certificates valid for another 825 days, it may take up to four and a half years before issues are resolved. This proposal would halve that time, to a little more than two years, and represents a significant improvement.

It’s typical, what any changes to any ecosystem (you used the word yourself) requires some time to be adopted (on browser side, CA side and it seems that this is always forgotten here: also on user side (I mean by the user the one, who use certs). Therefor you can check, how the world works and will end up in e.g. management system certifications. Changes here as well have a three year period to be adopted, so if a new standard is released, there are three years to be able to adopt the change. Same you can see new laws as well take several years to be adopted, e.g. the GDPR, which was a huge requirement for many companies, has to been adopted in two years. Lowering from a typical adoption timeframe from three to two years was already a challenge, reducing it to lower periods to be adopted will make it much harder. But the same as written above about phishing, if you see a timeframe of four and a half years because of reuse of information, why change the certificate lifetime instead of thinking on the first directly topic to solve this issue by reducing the validation reuse possibility to just one year by keeping the certificate lifetime.

* Even when the Baseline Requirements are clear and unambiguous, implementation issues by CAs routinely introduces risks of improperly formed or validated certificates, allowing CAs to issue certificates which have never been permitted and should never have been issued. Reducing certificate lifetimes reduces the overall risk that the ecosystem is exposed to these improperly formed certificates, both in terms of usage and in the need for Relying Parties to support such certificates.

There are service - like Netcraft is offering some of them - to detect such certs and let the CA revoke and reissue such certs. Management systems include regulary internal audit requirements to solve non-confirmities, WebTrust and ETSI also include external audits. This are the right measurements at least to arise such problems and require them to be solved by the established mechanism of revocation and reissue. Reducing the lifetime is no direct solution therefor and could only protect the ecosystem as mentioned before, if we talk about lifetimes of hours or days, if the intended solution therefor (revocation and reissue) is rejected. So there are practices, which already exist and mechanisms, which already exist, reducing lifetime is just a workaround and one year won’t help such much as expected, you need to talk about days or hours to be able to get a valuable result, coming with negative side effects, which aren’t worth to be taken.

* CRLs and OCSP have long been shown to be non-viable at Internet-scale, in terms of how they externalize costs like privacy, performance, and stability to Subscribers and Relying Parties. While alternative, browser-specific methods also exist, they also allow CAs to externalize the cost of their practices onto users and browsers, growing as the number of unexpired certificates grow. Reducing certificate lifetimes meaningfully
protects users, regardless of the revocation method used, and helps reduce the overall costs paid by users.

So if they then don’t work on and improve CRL and OCSP or alternative solutions with the same outcome. What’s about the huge databases of CT, which will then need to log much more certs as they will be issued in hours or day and who should be able to still monitor them? Why don’t let the CA provide alternative methods for revocation check, I’m sure, they will be willing and able to provide them. Following discussions like the ones to reduce the lifetime, doesn’t look like the CA/B-Forum is like to be working together on reliable solutions but working against each other, the browser on one side, the CA on the other (beside your “own sponsored” CA, for sure). I’m also sure, that companies using certs e.g. would be happy to adopt OCSP stapling instead of having unnecessary effort on lifetime reduction or to be punished to automate. Also domain providers don’t operate the DNS zone files for each domain, they are hosted by registrars or the users, it’s as well customer and vendor working together on the same goal.

* Operationally, the current extensive certificate lifetime has repeatedly led to issues, in that Subscribers frequently forget how or when to replace certificates. Aligning on an annual basis helps ensure and streamline continuity of operations, reducing the number of errors users see and disruptions that sites face.

So automatism will stop them from forgetting to renew their cert? What about validation, which need to be redone, if we don’t just talk about domain validation, which isn’t worth more than just encryption? So you would like to help all the IT staff out there to get more routine by latest replacing certs every day or hour? If someone is ignoring all the services, information and possibility to renew in a timely manner, they also will do on annual renewal and on shorter timeframes it’s an administrative nightmare. And a government shutdown won’t also improve any routine, which timeframe it ever would have.

* Operationally, the prolonged reuse of validation information creates challenges in replacing certificates due to security risks identified with
the existing validation methods permitted by the Baseline Requirements. Reducing this validity period similarly helps streamline the validation
process, allowing site operators to ensure for relying parties that the certificates they use were meaningfully validated.

Same as mentioned above on other Baseline Requirement adoption requirements or phishing. Additional, you could add a field to certificates about their validation method and BR version based on, so it would be possible, if really required in a timely manner and you still reject revocation or would like to have a more soften phasing system, to show the “validation level” of the certificate based on such information. But isn’t Google the company, which already removed and validation value out of the certificate ecosystem? Looking a Twitter, Linkedin etc. there is a well established way to show validated information, for management level (and everyone, who participate in road traffic) as well signals like red, yellow, green are well established as well, so why don’t show red for no validation/self signed/…, yellow for low validation (domain validation or validation method deprecated) and green for high validation (by getting a validation method, which CA as well as browser see as valuable against alternative models, which try to rebuilt like WOT plugin, e.g. based on the new required LEI) in a symbol of a checkmark, which everyone understand, who uses Twitter, Linkedin etc. (so a really small customer base^^).

* As shown by issues such as BygoneSSL, the misalignment between certificate lifetime and the domain name system poses availability and security  risks to site operators. Despite such research being presented directly to the CA/Browser Forum, there have been no efforts by CAs, as an industry, to mitigate the risks posed to users. Certificate lifetimes currently represent the greatest mitigation to these risks.

Same, have solutions been proposed. My thought was, that this forum should establish solutions together.

* Existing certificate validity periods create risk for Relying Parties wishing to enforce the Baseline Requirements or Root Program requirements, by allowing CAs to “backdate” certificates in order to attempt to bypass date-based program requirements. Reducing certificate lifetimes reduces the window of exposure to such bypasses. As this has happened multiple times, by past and present members of the CA/Browser Forum, reducing certificate lifetimes represents the safest way to detect and counter this risk.

Same, no direct solution. Aren’t there solutions like CT to detect such changes? Including BR version to certificate and requiring every cert to be logged against CT, would prevent to be able to use an older version. Reducing cert lifetimes is a stupid solution therefor and as well would only really have an proofable impact on daily or hourly certs with the side effects mentioned already. There are other possible solutions therefor.

* While this ballot sets forward a proposal for an effective annual renewal and annual revalidation, both periods should be seen as a starting point for further improvements. In particular, multiple Browsers have noted that the current reuse of domain validation information represents a substantial security risk, and thus will seek to further reduce this in subsequent ballots. In general, CAs and Subscribers are recommended to pursue interoperable solutions for automation, such as RFC 8555, which allow for easier and seamless validation and replacement of certificates, and thus helping ensure users and Relying Parties are adequately secured.

And enforces automation, also if automation is against the adopted security and service management best practices. It’s still a workaround for all topics mentioned above. It’s nothing to be done and established, although mentioned to be no good solution, quick and fast. Can you proof anything, which got better by reducing lifetime down to two years recently? With removing of e.g. EV signal, Google themselves put end users at risk as there is no difference any more on a DV against a (maybe some issues arise, to be solved, so somehow still better validated) EV? Did you recognize the increased volume of phishing sites with DV which claim (as https always was the trained factor) to be valid and have success as of the “secure”/”non-secure” mislead of end users? Maybe that’s the more important point to work on to increase the reliability. Enforcing baseline requirements, enforcing policies etc. primary have one goal: Reduce misvalidation, so if such topics arise, you still have the weapon of revocation, which should be fixed, if it’s not working, as expected. Reducing lifetimes and introducing effort and/or pressure on automation adoption, “just in case” instead of using well established or easy to be adopted (BR, validation method cert value and requiring CT logging, revocation, stapling, …) is a worse idea.

* While Browsers will be able to technically enforce these reduced validities as early as March 2020, they will not fully benefit from the reduction until 825 days after the last day such certificates can be issued, or June 2022. As a consequence, any delays to the implementation period of March 2020 would represent an even greater security risk to users and Relying Parties.

Not been able to adopt the requirement for many companies would represent a much greater security risk, if looking at this solution just to be a “just in case” short shot, doesn’t make it better.

* This ballot further attempts to resolve ambiguities between the expectations of Root Programs and the interpretations of CAs. Namely, it attempts to clarify time periods in days and seconds, to avoid confusion with respect to months, fractional seconds, leap seconds, and other forms
of date calculation, while also allowing an additional 86,400 seconds between the recommended period and the required period. To address issues
with Validity Period, it defines the Validity Period in a way that can be objectively technically enforced and verified, by measuring the period
between the notBefore and notAfter of certificates, as specified by RFC 5280. While historically the Forum has not specified timezones for
effective dates, and thus this ballot continues the trend, consistent with the requirements of X.690, X.680, and X.509, the time and timezone for
effective dates shall be interpreted as midnight, Coordinated Universal Time.

Maybe BR should be improved to a clearly consensual requirements catalogue before enforcing such changes like this ballot with uncertain benefits and to be there “just in case” but with such a big impact, effort and pressure on all certificate users?

Regards,
Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190820/7b37a4ec/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/20190820/7b37a4ec/attachment-0001.bin>