[cabfpub] Concerns with the proposal for LV certificates

Eric Mill eric at konklone.com
Wed Dec 9 16:11:30 MST 2015


Hello,

While I greatly respect Cloudflare's and Facebook's security teams and
believe they are sincere about protecting access to secure connections for
vulnerable populations, their joint proposal for an "LV" (Legacy Validated)
certificate seems really problematic in the long run.

https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/
https://www.facebook.com/notes/alex-stamos/the-sha-1-sunset/10153782990367929

At a basic level, this proposal asks CAs -- and the public web -- to take
on prolonged systemic risk for an undefined period of time, without any
proposals to address the root issue of legacy clients.

Some immediate concerns:

   - Under any version of the LV proposal, CAs would be allowed to maintain
   code paths in their issuance infrastructure that support the SHA-1
   algorithm. The criteria for enabling SHA-1 issuance would be based on
   promises/audits of the org wishing to obtain one, which means the SHA-1
   issuance code would be relying on out-of-band factors (rather than an
   automatable algorithm) for determining whether SHA-1 is an acceptable
   signature algorithm for the requested certificate.


   - This proposal also adds operational constraints to site owners --
   their eligibility for an LV cert requires them to maintain downgrade-proof,
   thoughtfully designed code to provide different certs to different clients.
   To the extent the BRs apply operational constraints to CAs, these are
   accompanied by a system of audits that provide some degree of assurance the
   operational constraints are being carried out. CloudFlare and Facebook have
   both released, or pledged to release, the code that executes their
   certificate-switching.


   - However, there are no assurances that the public code they release is
   in fact the code that is running in production. For the strength of LV
   issuance to meet the standards the CA/B Forum tries to uphold for other
   forms of validation, organizations requesting them would need to submit to
   an audit regime, along with defined consequences (and meaningful leverage)
   for a failed or qualified audit. Whether or not FB or CF are willing to
   enter such a regime, this adds additional complexity and resource cost --
   and an entirely new class of political actors (beyond FB and CF).


A healthier approach would be for affected companies to collaborate with
other large/affected institutions to meaningfully address the long tail of
legacy clients.

As challenging and expensive as that may sound, that is already the
approach that some global internet companies are taking to provide internet
access to populations that have trouble getting it. These are massive
subsidies being given to parts of the world that need it, because
businesses have seen that it is in their professional (and perhaps
personal) interest to ensure that that happens. To the extent internet
companies are coming to perceive legacy endpoints as a business risk, it
doesn't sound unreasonable for them to pursue similar approaches.

And there will be time. Just as members of the CA/B Forum informed some of
their enterprise customers that they should probably stock up on SHA-1
certificates before the deadline, this option is still open. These certs
could be long-lived in duration (it looks like it can go up to 39 months,
since the expiry deadline is a SHOULD NOT and not a SHALL NOT), and backups
could likely be obtained at the same time to reduce risk.

While this is a rigid approach, it is an approach where affected
stakeholders could absorb the risk, rather than place it on the ecosystem.
And in 39 months, legacy client use will diminish regardless of the actions
affected stakeholders take.

And at the very least, these SHA-1 certificates will provide a time buffer
for the CA/B Forum to decide on future changes in a calmer setting.

Ryan Sleevi has proposed another approach, of allowing for name-constrained
subordinate intermediates, along with the context of why this hasn't been
allowed this far:

https://twitter.com/sleevi_/status/674658891955703808

Tackling legacy clients in remote, underserved, wartorn areas of the world
is obviously a tremendous challenge. Inventing and deploying a new system
in 3 weeks for reliably blessing specific companies to serve publicly
trusted certificates also sounds like a tremendous challenge.

I recognize it's very easy for people and companies who don't directly
serve vulnerable populations to not attribute enough weight to the
on-the-ground political reality for those populations. However, pushing
affected companies to channel their business and personal desires to help
the vulnerable in a direction that improves those populations' long-term
security seems to me like a far healthier reaction than adding weighty
process, complexity, and risk to the global CA ecosystem.

-- Eric

-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151209/0b72fb7f/attachment.html 


More information about the Public mailing list