So how does this little detour tie into the LV clause that they be suspended if a path is found that modern clients will accept, and that no software change will correct? Well, as mentioned, the way virtually every certificate validation library works is that you’re limited on what you can tell it — you can no more tell it to avoid Las Vegas than you can tell it to disable SHA-1. Worse still, if you disable SHA-1, these certificate validation libraries will act like they’ve encountered a one-way street — they’ll simply give up, even if there’s another route to the destination. So, in practice, it’s impossible to guarantee a modern client won’t trust an LV cert.

Which gets to the second part of the clause — whether or not it can be fixed with a change to software. Software is, ultimately, infinitely malleable — it does exactly what we tell it to, regardless of whether or not that is what we intend. So it is always possible to argue that a change can be made to fix this, just like it is always possible to argue that if you want to get to New York from Los Angeles, and avoid Las Vegas, you could construct a highway that follows a straight line, building bridges over every river, tunnels through every mountain, and buying every bit of land necessary to accomplish this. Is it economical? Absolutely not. Is it possible? Surely so.

As it stands, none of these policy controls are very effective — they’re largely there because they fit the pattern of how certificates are issued, serving no particular purpose other than making the proposal look more robust and detailed than it is, and hiding the scarcity and ineffectiveness of the technical controls.

Technical Controls

The real heart of LV rests on its technical controls, which the proponents argue are sufficient for the risks posed.

The one easiest to show as inadequate is the validity period requirement. This does nothing to prevent the attacker from obtaining a collision, it just limits the harm that they can do to the Internet to being a little more than three years. The idea that it would be acceptable to leave billions of users at risk for three years is not at all viable. This requirement doesn’t try to prevent damage, just limit it, but the limit is so unreasonably high that it’s effectively unlimited. Even if the validity period was reduced to a day, if an attacker was able to successfully mount one attack, they could presumably repeat it indefinitely until detected; it may slow the attack, but it does not stop it.

The next technical control is in requiring a distinct intermediate to be used for LV certificates. Similar to the validity period, this doesn’t attempt to thwart the attack at all; rather, by requiring a distinct intermediate, it makes it easier for software to distrust that intermediate, should an evil cert be detected. It’s as if the only time you would ever drive through Las Vegas is to get to New York — if you want to stop people getting to New York from Los Angeles, you could close all roads in to and out of Las Vegas, and your “problem” would be solved. What the metaphor here hides is that this control relies on detecting the problem first, which is both difficult and unreliable, especially for the users in the war-torn and repressive regimes that Matthew Prince wrote about — or those affected by targeted interception attacks revealed by nation-state adversaries like the NSA and GCHQ.

This leaves the only technically effective control being the requirement of entropy in the serial number. The twenty bits that LV proposes has no academic or technical background to its selection; it was merely inherited from the existing Baseline Requirements, which itself was the result of unfortunate compromise necessary to appease CA members of the CA/Browser Forum. It’s not known whether or not twenty bits is enough, and that’s largely a question of the work-factor of the attacks, in that it is assumed an attacker would need to mount 2²⁰ parallel attacks to guarantee success.

Even if twenty bits is acceptable, it’s a proposal that is entirely incumbent upon CAs to implement properly. As the previous post considered, CAs routinely and comprehensively fail to implement the necessary security protections, which leads to them misissuing certificates. It’s not something that can be detected by a client who validates the certificate, as there is no way to know whether or not the entropy was random. It doesn’t set standards for what the entropy source is either, such that a CA that actively wanted to collude with a nation-state attacker could, for example, chose to use something like DUAL_EC_DRBG as the entropy source. If they did, they would be creating a cryptographic back door that would allow some parties to determine the state of the random number generator, and thus predict what the chosen-prefix would be. The attacker — or anyone else who found or discovered the backdoor — could then intercept secure communication for large portions of the Internet, practically (though not technically) undetectably.

Conclusion

This really gets to the crux of the problem with LV — its only security control relies entirely on CAs properly implementing it, as soon as possible so as to minimize disruption, and fails to acknowledge that CAs routinely fail to implement the necessary security controls, or that when such controls fails, billions of users are put at risk.

Stamos and Prince present it as a matter of finding a solution for the extremely old and outdated clients, and that leaving behind the fraction of users is an unacceptable trade-off, but in doing so, they propose a solution that presents risk to the billions of users. While the topic of path building was only lightly addressed, due to its technical complexity and nuance, it is perhaps the core of the problem: LV presupposes clients, whether they be users’ browsers or the backend systems that servers communicate with, can safely disable SHA-1, without any risk or consequence to compatibility or operation. They fail to understand or acknowledge the path building problem, or the fact that billions of users still trust MD5 signatures in certificates because of it. The only thing protecting these billions of users is that no CA is permitted to issue them — in effect, relying on hopes, prayers, and the good nature and technical abilities of CAs.

Further, the proposal introduces procedural barriers that accomplish no security benefits. These procedural barriers no doubt appeal to CAs, which can use them to justify a high premium, much like SGC certificates. While Prince and Stamos propose LV as a type of certificate intended to help the downtrodden, they ignore the years of context for which CAs are clamoring to sell such certificates not to mainstream sites, but to enterprises and internal customers, whose implementation and controls are unquestionably woefully inadequate for the risk presented.

The entirety of the proposed mitigation hinges on entropy in serial, which is one of those things that was painfully obvious as necessary in 2010, but for which CAs were still struggling to implement in 2015. If that fails, whether to be implemented at all or implemented securely, attackers can mount successful attacks, against any domain, and with more or less total impunity.

While CloudFlare, Facebook, and Twitter have tried to present this as a battle between serving the impractically ideological needs of modern users buying new phones and new computers every year versus that of the economic and social underdog, the proposal is effectively asking the 97% to bear the risks of the 3%, and with the only mitigation being a belief that this time, despite over a decade of failure, CAs won’t screw up.

Worse still, the argument is made without supporting data or review; that is, the presumed conclusion is that there is nothing to be done for these users but to accept the risk, without exploring why the problem exists in the first place. CloudFlare presents the problem as old Android devices and feature phones, yet Android supported SHA-256 since the first public release. What issues existed were not a matter of algorithm, but of path building — yet the two are lumped in the same. The only data that’s been publicly shared has not been from the proponents of LV, but from those opposed; Peter Bowen of Amazon Trust Services notes that, from data he’s both seen and shared, many users who had trouble with SHA-256 were not because the client device didn’t support it, but because there were one or more network-level intermediates disrupting the connection. This could be anything from antivirus to corporate firewall to state-level attack, but such data radically changes the conclusions, in that it suggests rather than needing to update millions of users of devices, we may be talking on the order of hundreds or thousands of targeted enterprises. The arguments from CloudFlare, Twitter, and Facebook don’t provide the data necessary to support the conclusions they make — for example, it’s unclear whether the 3%–7% quoted are completely unable to access these sites, or only partially unable due to situational and environmental factors: like being unable to access while at work, but having no problems at home.

When evaluating Legacy Verified certificates, it’s necessary to keep in mind that “extraordinary claims require extraordinary proof” — and so too should calls for extraordinary risk. LV, as a whole, fails to mitigate against this risk by ignoring the historic context surrounding it, understates the risk posed, and underestimates the serious technical complexity faced by any and all applications that wish to validate certificates and avoid LV’s risks. While understandably it comes from an earnest desire to find a solution, it fails to explore the alternatives and fails to mitigate the incredible risks, and so ultimately needs to be rejected as unsafe at any speed.

Perhaps the saddest part of this proposal is that it was necessary for CloudFlare, Facebook, and Twitter to make it. That is, in the beginning of the Web PKI, the CA ecosystem wasn’t the profit driven sales and marketing machines they have become, but actually had solid engineering and were concerned about designing solutions that actually enhanced security, rather than giving the appearance of it. It is CAs that should have the technical knowledge and expertise to recognize not only the flaws in this proposal, but also the ways in which it could be bolstered, limiting the risks and potential negative impact. Unfortunately, today’s CAs are largely a shadow of themselves; only a few invest in solid engineering and have the technical know-how to design a solution that balances these tradeoffs.

In the next post, I hope to explore what steps can be taken in order to find a solution, as well as examine the other solutions and why they too fail. While it’s easy to throw an idea out and say “something should be done,” with little more thought than an idea sketched on the back of a napkin, it requires much more discipline, care, understanding, and data to actually find a path that balances the risks and encourages, rather than undermines, security. I also hope to look at what’s needed of Facebook, CloudFlare, and Twitter — more than just grandstanding and press releases, the actual data necessary to make informed and calculated assessments of the risks and trade-offs, and that can help find a solution that doesn’t just foist all risk and cost onto the 97%.

Thanks again to the invaluable feedback and editing for those that reviewed this post, especially over the holiday period.