[Servercert-wg] Ballot SC22: Reduce Certificate Lifetimes

[Tobias S. Josefowitz]

On Mon, 26 Aug 2019, Dimitris Zacharopoulos (HARICA) via Servercert-wg 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.
>
> 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. 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).
>
> 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.

In some sense, 100% secure revocation (from the browser perspective) 
involves finding out if the certificate presented by a server is still 
valid at the *then-current specific point in time*, and would require the 
browser to reject the certificate presented if it cannot receive such 
confirmation in pretty much real-time.

For OCSP this means to actively ask, for CRLs this means to make sure CRLs 
present at the client are up to date (by actively asking), update if not, 
and then to verify the certificate presented is not on the relevant CRLs.

In a 100% secure revocation scenario, both mechanisms require remote 
network services to be queried and results received and verified to be 
correct.

OCSP stapling has, in many ways, functional equivalences to extremely 
short-lived certificates that are automatically renewed.

All of these mechanisms, especially if used to reach 100% secure 
revocation, fundamentally change the nature of a certificate from 
something that on its own could vouch for the identity of a site to (yes, 
hyperbole) somewhat of a second factor in whatever online mechanism is 
chosen for revocation. One might even say to rely on revocation means to 
make certificates less certificate-y, maybe even to the degree where one 
might ask: If we talk about an online, realtime component - do we even 
need X509 certificates to begin with?

Now, 100% secure revocation is obviously quite a strict requirement 
compared to a 13 months certificate lifetime; and nobody has really 
suggested this anyway. Looking at this hypothetical scenario does however 
hint to me that for browsers to rely much more on revocation than they do 
today may have far-reaching implications for the ecosystem.

In comparison, how much does asking operators behind the 6% of 
certificates with a currently greater than 13 months lifetime (as 
according to Ryan) to renew more often actually burden them? I fully 
understand few operators will be *excited* by the prospect, or even by not 
having the option, and as demonstrated, there can be strong reactions from 
site operators.

But then really, how hard can it be? At most twice as hard as currently.

The amount of organizations and individuals that will actually be hit hard 
by the reduced lifetime, if it comes to pass here or is enforced some 
other way, especially in ways that are not remedied by changes in process 
and approach will be limited. This group will presumably mostly consist of 
those that operate devices/products that make it unnecessarily burdensome 
to replace SSL/TLS certificates.

Having such devices/products hold back the entire ecosystem could at best 
be described as tragic. In addition, for devices that really make it hard 
to properly and swiftly manage SSL/TLS certificates, one would think that 
they probably have other issues as well, I would assume one does not 
generally make devices or products that require special persuasion to 
update certificates but will have good and easy processes for applying 
firmware updates. Futher, I doubt such devices will frequently be supplied 
with firmware updates. That allegedly so many of these are operated with 
publically trusted certificates - which implies some might need to be 
globally reachable - is worrying as well.

I see no mechanism that we would have available to cause the producers of 
such devices/products to make updating SSL/TLS certificates less 
problematic in the future (so that we could adopt a 13 months lifetime at 
reduced operator cost), and to overall improve the overall security 
properties of their devices/products that would not burden the operator of 
such devices/products.

As stated above, SC22 will probably put a small amount of operators into a 
situation that will be tricky for them, arguably at no fault of their own. 
It will however also clearly generate market pressure that will lead to 
devices (and other products) to have better management options for SSL/TLS 
certificates in the future.

Tobi