[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Eric Mill]

On Tue, Aug 27, 2019 at 9:24 AM Christian Heutger via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi,
>
>
>
> > For example, I don't think we'll ever find consensus when a CA is
> arguing that users should have to sacrifice their privacy and disclose
> their browsing activities to CAs to be secure online, which is what you've
> clearly advocated. That sort of fundamental misunderstanding suggests a
> misunderstanding of the role CAs play, and is not easily corrected, no
> matter how carefully dispelled.
>
>
>
> OCSP stapling doesn’t require to do so.
>
>
>
> > It sounds like some basic explainer documentation about how the whole
> ecosystem factors in, which CAs may miss due to their narrow focus on their
> specific set of users, may help, but I also suspect it's unlikely to
> convert anyone to care about the forest rather than their specific tree.
>
>
>
> Maybe it’s worth to explain your full view of the ecosystem as it seems to
> differ from all other point of views. Maybe it’s most reliable, if you
> could underline your point of view with references from institutions e.g.
> NIST, that it should be considered as given status quo. I’m afraid, it’s
> just your point of view and others exist as well, but it looks like the
> resulting solutions should be enforced either accepting your position or
> not.
>

Ryan's point of view is not at all unique. He's just the one spending the
most time debating the issue with you in the CA/B Forum. Automation is
commonly understand by many technical and security experts, as well as
leaders throughout the IT and cybersecurity domain, as a best practice for
enterprises which want to reduce attack surface and maintain internal
stability.

This website contains the official implementation guidance for the US
government's HTTPS-only policy, and it specifically calls out automation
and shorter-lived certificates:
https://https.cio.gov/certificates/#what-kind-of-certificate-should-i-get-for-my-domain


"“Domain Validation” (DV) certificates are usually less expensive and more
amenable to automation than “Extended Validation” (EV) certificates. EV
certificates generally result in the domain owner’s name appearing in the
browser URL bar visitors see. Ordinary DV certificates are completely
acceptable for government use.

Certificates can be valid for anywhere from years to days. In general,
shorter-lived certificates offer a better security posture, since the
impact of key compromise is less severe. Automating the issuance and
renewal of certificates is an overall best practice, and can make the
adoption of shorter-lived certificates more practical."


More recently, NIST's Cybersecurity Center of Excellence is in the final
stages of publishing a document on TLS certificate management best
practices:

https://csrc.nist.gov/publications/detail/sp/1800-16/draft
https://www.nccoe.nist.gov/sites/default/files/library/sp1800/tls-serv-cert-mgt-nist-sp1800-16-draft.pdf


The document is huge, but it talks extensively about automation and shorter
lived certificates. It recommends certificates of 1 year or less for
organizations which are having *difficulty* automating, and recommends
shorter certificates for those that can.

"...ensuring certificates and their corresponding private keys are changed
regularly is important, as shorter validity periods reduce the amount of
time that a compromised private key can be used for malicious purposes.
However, validity periods that are too short may increase the risk of
outages. Organizations should determine the ideal validity period that
balances security and operational risks for their organization. In general,
due to the regular reassignment of administrative staff, it is recommended
that validity periods be one year or less. The automated management of
certificates can enable a more frequent renewal of certificates."


On the subject of automation, the guidance is quite clear that automation
reduces both security and availability risk:

"The broadening use of and reliance on TLS server certificates to secure
important applications is rendering manual certificate management
impractical. Risks such as certificate-related outages are often the result
of errors made while manually managing certificates. Organizations are
unable to manually replace large numbers of certificates in response to
large-scale cryptographic incidents, such as CA compromises, in a timely
manner. Consequently, organizations should work to automate certificate
management on as many systems and applications as possible to decrease
security and operational risks."


(I haven't read the full document - it's huge - this isn't meant to be an
endorsement of the document in full.)

But again, I really just want to emphasize that Ryan/Google is far from the
only person or company pressing for shorter-lived certificates, or starting
from a position that automation is a security benefit. And I'm comfortable
sharing that when I was a government official overseeing a large
multi-million-user public service, that system's authorization earned my
signature in part by demonstrating that as many controls and processes were
as close to fully automated as possible.

We need more important organizations to automate more of their important
processes, or defense and agility will continue to suffer and we'll
continue to see resistance to even basic ecosystem improvements that can
raise costs to attackers.

As I said in my last email - 1-year certificates are not an "automate or
die" proposition. But it's moving in the right direction. Additionally,
cutting cert lifetimes by half will statistically reduce the lifespan of
all compromised keys by a significant degree. I would love to see the
CA/Browser Forum support these changes, as the benefits of shorter-lived
keys and automated processes will only become more obvious and more clearly
the consensus view with each passing year.


>
> Regards,
>
> Christian
>
>
>
> On Tue, Aug 27, 2019 at 3:18 AM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>
>
> 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> 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:
>
>
>    - 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.
>
>    - 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:
>
>
>    - Teams with high turnover are better able to ensure continuity.
>       - Teams align other annual requirements with certificate issuance
>       so that manual issuances aren’t forgotten.
>       - 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.
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>


-- 
Eric Mill
617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190827/1b3556d4/attachment-0001.html>