[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Dimitris Zacharopoulos (HARICA)]

On 26/8/2019 4:20 μ.μ., Ryan Sleevi wrote:
>
>
> On Mon, Aug 26, 2019 at 12:35 AM Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg <servercert-wg at cabforum.org 
> <mailto:servercert-wg at cabforum.org>> wrote:
>
>     HARICA does not agree with further reducing the lifetime of TLS
>     Certificates as it creates unnecessary burden to site operators.
>     If the main problem we are trying to solve is Domain Validation
>     and the fact that some domains are "changing owners", thus putting
>     at risk the new Domain owners as BygoneSSL demonstrated, we should
>     look for alternatives rather than having millions of site
>     operators replace millions of Certificates at a shorter timeframe.
>
>
> This is not the "main goal".
>
> During earlier drafting, it was suggested by some members to provide a 
> list of the numerous benefits. This list is at 
> https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html , 
> which includes many suggestions from Apple previously, at 
> https://cabforum.org/pipermail/validation/2019-August/001296.html

Apologies for the long reply, but I had to include the previous 
references for completeness.

Benefits of reduced lifetime:

  *    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.

Re-validating Domain Names seems to solve this problem, so this goal is 
achieved.

  *    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.

Such a risk will always be there, I don't see how it can be reduced by 
shortening the lifetime of Certificates. Even if a Certificate is issued 
for 1 month, it could create the necessary "damage". The BRs already 
have rules for such cases, which is revocation within 5 days. We saw 
that clearly in the serialNumber entropy case. For improperly validated 
certificates, again the re-validation process would be executed within 
12 months with the updated validation methods, so this goal is achieved 
as well.

  *    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.

You claim that checking for the status of a Certificate is externalized 
to Relying Parties (users and browsers). Yes, this is how X.509 was 
designed. It's not a perfect technology and some solutions might suffer 
from privacy, performance and stability. I also don't see how reducing 
certificate lifetimes helps reduce the overall costs paid by users. 
Users will continue to check for the status of every certificate 
presented to them, these are the rules. If a browser decides not to 
check for the status of a certificate for performance, or other, 
reasons, then this browser adds a more significant risk to the user. 
This browser would reduce the cost (privacy, performance, stability) but 
would open a risk window for exposing the user to a 
malformed/unvalidated/fraudulent/incompatible Certificate.

  *    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.

Replacing certificates more frequently, opens the (greater than zero) 
risk of mis-configuration. We are not discussing about meaningful 
security improvements like configuring a web server to support TLS 
1.2/1.3 and removing 1.0/1.1. We are discussing about a Certificate 
replacement that provides "zero" security benefit to Relying Parties. 
They won't even detect this change. According to HARICA's experience, 
site operators tend to align Certificate replacement in certain weeks 
and this can be achieved even with 2-year Certificates. They usually 
receive expiration warnings ahead of time to remind them that 
Certificates are about to expire. I don't see a significant improvement 
here by reducing the certificate lifetime to 13 months.

  *    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.

This kind of repeats the second bullet and I believe is the most 
important argument driving this ballot, which is precisely the reason 
HARICA focused on this one and called it the "main goal". Re-validating 
Domains is critical and the ecosystem can greatly benefit from such a 
requirement. This doesn't mean that the associated Certificate(s) need 
to be replaced creating all the extra headaches for site operators with 
"exotic" equipment.

  *    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.

Requiring annual re-validation of Domain Names seems to achieve this 
goal as well.

  *    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.

CT logging seems far better mitigation to counter this risk. All CAs 
that are trusted by at least Apple and Chrome need to log their 
Certificates anyway, I am not aware of any CA/B Forum CA Member that 
doesn't log TLS Certificates. In any case, what you describe here is 
strictly prohibited at least by the Mozilla Root Program 
(https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date). 
Reducing the certificate lifetime provides no protection for a malicious 
CA that will issue a certificate in the past to bypass new requirements. 
However, re-validating the Domain Names with the latest validation rules 
should leave an auditable trail.

  * Security:
      o Long lived certs present a longer lived threat. We have seen
        this presented in the BygoneSSL report/brief. We would like to
        work towards having the domain validation validity align with
        the certificate validity.

Apple is also more concerned about Domain Validation and rightfully so. 
This is what BygoneSSL presented. Performing Domain Validation more 
frequently is a solution to this problem.

      o Since most software fails open when performing revocation
        checks, the best safeguard is the validity period of the
        certificate.

I believe this has already been addressed. For the benefit of software 
that actually does what the underlying technology requires them to do, 
which is revocation checking, we should not abandon revocation as a 
tool. It is already in the requirements and has caused significant pain 
to CAs to support it, as I'm sure most of this group is aware of.

  * Operational:
      o Teams with high turnover are better able to ensure continuity.
      o Teams align other annual requirements with certificate issuance
        so that manual issuances aren’t forgotten.
      o Encourages adoption of automation that reduces opportunity for
        human error and reduces operational cost overall.

If only automation was that simple for every TLS server that wants to be 
publicly accessible... HARICA is probably one of the smallest CAs in the 
Forum yet we have encountered a great number of appliances/equipment 
that provide a very basic administrative interface. We are assisting 
site operators to install certificates in these devices and even have a 
hard time installing the Certificate Chain (for some cases where the 
hierarchy is more than 2 levels). These devices have no way of 
automating certificate installation. I don't know the percentage of 
these devices worldwide but I'm sure larger CAs have similar or better 
experience to share with us. We propose site operators to use web 
proxies but some of them have no experience how to properly maintain one.

If we consider the time to manually replace a certificate in such 
devices to 30', then the 6% of the total number of Certificates is a 
significant human effort for zero benefit to Relying Parties and very 
low benefit for Domain owners.


>     Certificates are used in far more systems than I could possibly
>     list. Routers, modems, cameras, scientific equipment, proxys, are
>     just to name a few that have zero (or close to zero) support for
>     automation in certificate renewal.
>
>
> Annual certificates do not require the use of automation. Certificates 
> with lifespans of <= 13 months, as this ballot proposes, make up 94% 
> of the existing valid certificate market.

I don't doubt the numbers but for sure LE's 90-day Certificate lifetime 
should significantly influence this number.

>     We could try to disconnect the Domain Validation part from the
>     Certificate Installation part. The Domain Validation part is
>     usually done via alternative channels and are easier for site
>     operators to handle. Perhaps we have discussed this before but we
>     could add rules in the BRs to re-validate Domain Names more
>     frequently, like every 12 months. If the Domain is not
>     re-validated within 13 months, the Certificate MUST be revoked
>     (leaving 1 month "grace period" for reminders to be sent to the
>     Domain owner).
>
>
> You are correct that we did not explore it, because as noted in the 
> ballot, revocation does not work for the Web, especially with respect 
> to privacy. Any solution that relies on revocation is thus 
> unacceptably broken.

A reasonable continuation of this though would be "let's get rid of 
revocation requirements", yet we are pushing for revocation whenever 
something as the serialNumber entropy issue (63 bits instead of 64 bits 
of entropy source) occurs. This seems to be inconsistent. Revocation is 
not unacceptably broken as demonstrated by at least some Certificate 
Consumers that effectively use revocation mechanisms. Perhaps the 
revocation check is not instant but in a short amount of time 
(hours/days, not months as the lifetime of the Certificate protects), a 
revoked Certificate is not trusted by these Certificate Consumers.

>     The fact that revocation doesn't work for some browsers is not
>     (IMHO) an excuse for requiring millions of site operators to
>     replace certificates in these "admin unfriendly"environments,
>     every year, just to check if the site is still owned by the same
>     individual/organization.
>
>
> Thank you for sharing. Considering the hundreds of millions of sites 
> which are exposed to harm, danger, and CA misissuance as a result of 
> the long-lived lifetimes, and for which as Subscribers, they have no 
> effective recourse, Google's position is that we put the user first. 
> In this case, this means that the minority of sites and users - 
> approximately 6% - may have to encounter annual replacement. However, 
> the industry has shown that this does not require automation to do, as 
> this is both the default for a number of CAs, and long wide-spread 
> before the rise of automated mechanisms like RFC 8555. Automation 
> simply improves things.

Perhaps I wasn't clear enough when I mentioned about "admin unfriendly" 
environments. These are devices and equipment that are manufactured with 
a specific firmware. All vendors would have to create new firmware to 
support implementations like RFC 8555. We are already seeing this make 
progress in newer equipment but it's slow.

>     As Christian supported, in case of emergency (like an algorithm
>     failure or a CA failure/misussuance), as demonstrated in the
>     recent serialNumber entropy issue, CAs and site operators can be
>     pushed to replace certificates sooner. Site operators understand
>     and respect the fact that there is an emergency or an anomaly, and
>     can re-allocate resources accordingly to deal with an *unexpected*
>     need for certificate replacement. Requiring the installation of
>     new certificates every year is not an "emergency" task and will
>     not be easy to justify and for site operators to accept.
>
>
> CAs that still think of certificate replacement as an "emergency" task 
> are doing their users and customers a significant disservice and harm. 
> Another objective, as noted, is to reinforce that this is not and 
> cannot be the case.

CAs that follow the rules, explain to their Subscribers that in case of 
violation of the CP/CPS or the revocation reasons listed in 4.9.1.1 and 
4.9.1.2 of the BRs, the Subscriber Certificate would have to be replaced 
within 5 days (and in some cases within 24 hours). Other than that, the 
Certificate is good for as long as it is valid for. I don't see anything 
wrong here. Asking Subscribers to replace certificates "just for the 
sake of it", seems unnecessary and disrespectful for their time and effort.

>
> Luckily, some CAs have recognized this, and in light of 
> misissuance events have already taken steps - before this ballot was 
> circulated or proposed - to reduce the lifetime of the certificates 
> they issue to an annual basis. I can think of one CA, which primarily 
> targets government and enterprise users, which recognized the 
> challenges they and their customers had with timely replacement of 
> certificates, and saw a reduction in lifetime as the most significant 
> mitigation they could put in place.

HARICA has been issuing publicly-trusted certificates since 2011. We 
have always kept a maximum lifetime of 2 years because that was a 
reasonable balance between site operator effort to replace certificate 
and the duration of most of the Domain registrations we had seen. The 
majority of Domains (at least the ones that we encountered) were 
registered for 2 years. However, I would be curious to see more citation 
and experience for government and enterprise users that described how 
the CA and these Subscribers approached this challenge and reached such 
a conclusion (that the reduction of lifetime was the most significant 
mitigation they could put in place).

>
> It is understandable for CAs, given their direct dealings with 
> customers, to put their customers and business interests first, over 
> the safety and security of the ecosystem and users. It can be 
> difficult to articulate to them and their customers that the Web PKI 
> is only as secure as its weakest link, and that they are directly 
> harming many countless tens of millions of users and certificate 
> holders that wish to have improved security. Similarly, it can be 
> difficult to explain to these customers the importance of routine and 
> regular certificate maintenance, as part of any cohesive 
> infrastructure readiness or disaster preparedness scenario, as they 
> may be relying on antiquated notions that certificate replacement is 
> difficult. That's why it's incumbent upon us, the CA/Browser Forum, 
> and in particular, the Browser Root Store operators who are tasked 
> with ensuring the CAs in their program are trustworthy and the 
> certificates issued by these CAs meaningfully secure users' 
> connections, to lead and ensure that the minimum bar of security is 
> adequate.

This is probably the hardest to answer. Some CAs have demonstrated that 
the wider ecosystem good is above the benefit of the CA and its 
customers. They have done that by following the rules to the point, even 
if this created difficulties in customer relations due to a revocation 
requirement. If you consider that all Subscribers "out there" should be 
ready for a disaster scenario, this is probably the strongest argument 
to support reducing certificate lifetime to 13-months and even lower 
than that. Unless Google knows something the rest of the ecosystem 
doesn't know, I would kindly ask you to elaborate on what a disaster 
scenario looks like. Would the Quantum Computing scenario fit the 
description? A SHA2 deprecation? I think keeping the same algorithms for 
CA Certificates that are good for 10, 15 or 20 years makes reducing the 
lifetime of end-entity certificates a moot point. I am only saying this 
because the Forum has taken careful considerations to support secure 
algorithms, secure standards that have been tested thoroughly by the 
engineering and academic community. If there is a risk that the 
standards currently used or referenced in the BRs have a high likelihood 
to be broken, we must certainly focus on that. The SHA1 deprecation gave 
the CAs and the browsers a lot of useful experience so that we don't 
repeat previous mistakes. In case of a SHA2 deprecation the CAs and 
browsers should follow a significantly faster timeline.

>
> I'm shocked and dismayed to see CAs advocating against any lifetime 
> reduction, as it suggests outdated or incomplete understanding of the 
> core business they're in. While I'm sympathetic to discussions about 
> when best to make these changes, and have tried earnestly to highlight 
> repeatedly why it requires no substantive process changes for any 
> individual Subscribers before 2021, I would have hoped the years of 
> discussion that clearly identified this was the end-goal would have 
> prepared adequately.

HARICA will support any ballot that provides good and clear benefit to 
the ecosystem, taking into account all associated costs, risks, impact 
and effort. That includes CAs, Browsers, Certificate Subscribers, Site 
Operators, Domain owners and Relying Parties. Each "Participant" in the 
ecosystem has a certain amount of "weight". Relying Parties have the 
highest. The current proposal of ballot SC22 doesn't demonstrate 
significant security improvement for Relying Parties (they will see a 
renewed certificate more frequently than before). Re-validating the 
Domain Names annually, from HARICA's perspective, seems to be a better 
solution that meets the same goals as SC22 (thus RPs are more certain 
that they connect to the properly-owned Domain) without the additional 
burden for site operators to replace certificates more frequently. They 
just need to re-demonstrate control of the Domain Name otherwise their 
Certificate will be revoked.


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190827/074b7e1f/attachment-0001.html>