[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

philliph at comodo.com philliph at comodo.com
Mon Feb 6 19:56:34 UTC 2017

> On Feb 6, 2017, at 10:46 AM, Ryan Sleevi <sleevi at google.com> wrote:
> On Mon, Feb 6, 2017 at 7:34 AM, philliph at comodo.com <mailto:philliph at comodo.com> <philliph at comodo.com <mailto:philliph at comodo.com>> wrote:
> Ryan,
> Browsers have never agreed to anything ever. Browsers do not have thoughts. Browsers are not sentient. Not even in Westworld. Some engineers working for a Browser company have come to the conclusion that they can better meet their page load performance goals if they dispense with safety checks.
> I appreciate this logic, if only because it supports the argument that CAs are thoughtless, soulless, careless entities with no respect for security ;)
> Yes, I'm being facetious, if only to point out that the linguistic nitpicking is an entertaining but otherwise unrelated aside, so that hopefully we can focus on substance rather than style.

It is more than nitpicking. One of the biggest problems in Internet security has been the tendency to anthropomorphize inanimate objects. Adi Shamir pointed this out at RSA a while back, Alice is not a Turing machine. The difference between Alice and the device she is uses becomes critical when we are discussing the security properties of the system. If we anthropomorphize, we blind ourselves to the real security issues.

The weak point in the four legged model of TLS is the assumption that the Browsers can be proxies for the security needs of the users. Which is obviously a false assumption because they don’t all have the same security needs. It gets even worse when we realize that the root stores of the WebPKI are re-used for applications that have nothing to do with Web browsing. 

> As an industry, we failed users and certificate subjects. Right now I am getting certificate security warnings from Mass DoT due to a validly issued 3 year certificate that uses SHA-1. That should not be acceptable to us. But where does the problem really lie and does reducing the certificate validity window really address it?
> It lies in long certificate periods, and yes, it does address it.

Does it really? The fact that browsers didn’t support SHA-2 until quite a while after the need was proven had nothing at all to do with it?

It reminds me of the Chip and Pin transition in the US. For ten years, the US banks told me that they had no plans to implement Chip and Pin, they didn’t need it, didn’t want it, it was absolutely no use. Then one morning, Visa and MasterCard announced that they would be changing the merchant acquirer agreement to require Chip and PIN in 18 months time or the merchant was on the hook for fraud. What had changed in the background was not even the Home Depot and Target breaches, it was the sudden and unpleasant discovery that the banks rather than the merchants were probably on the hook for the consequences.

> I predicted a bumpy transition to SHA-2 in 2002 when I noticed that browsers were not adding it to the list of supported hashes. Which was even more strange at the time as the crypto libraries were filled with all manner of garbage algorithms. This was still an uphill struggle after the 2005 Wang et. al. attack was published. I developed and proposed a scheme that would enable a smooth transition from SHA-1 to SHA-2 and nobody was interested until the SHAppening in 2015 when it was suddenly decided that this had to happen yesterday and the CAs were of course to blame for not insisting on issuing certificates that the browser providers had refused to support.
> Right now I am trying to persuade people that we should be supporting SHA-3 as a backup to SHA-2 but of course nobody is taking any notice. Not even the people insisting that we must wind down the validity interval to a year to enable faster changeover.
> I'm aware of your (technically flawed) IETF proposal, but I'm not aware of any substantive contribution from you that can be argued as "trying to persuade people". I'd be curious for such links, particularly relative to the CA/Browser Forums' activities, since naturally, one might expect that to be an ideal venue for such persuasive discussions.

I don’t remember people pushing back claiming that the proposal was flawed. Rather the pushback came from folk telling us that the MD5 transition wasn’t a problem therefore there was no reason to think about the reason that the SHA-1 transition would be different.

> What we need is a technology architecture and a technology roadmap.
> That sounds like "We need to boil the oceans to make a cup of tea." Which, I must grant you, allows you to effectively reach your end goal, but at substantial cost to the ecosystem. Which is, I suppose, a natural state for reactions from the CA members - attempts to make the good the enemy of the perfect, and thus reject positive steps forward, in ever elusive search of a comprehensive solution that allows the current status-quo to remain, while having all the positive appeal of saying "We're doing something!" without actually doing anything meaningful.

Given what has happened in Internet security in the past 12 months and what is likely to come down in the next 48, I really don’t think that giving users just a cup of tea is going to cut it. Forget the question of who did the DNC hack, instead ask which governments are not going to be playing the same merry japes in the coming months and years.

Setting out an architecture and a roadmap is what I see as doing something useful, it only becomes meaningful if acted on of course.

Now you are entitled to see your proposal as consequential in its security benefits but I do not. In fact I think it could well be harmful because I don’t expect that it will enable rapid changes to the Internet security infrastructure but it might well create the illusion that they are possible. So we will see no improvement in deployment of SHA-3 or Curve-X or QCR, on the contrary we will see further resistance to change in the mistaken belief that change is now easy.

> Another point of a roadmap is to keep ourselves honest. I think that we should make a commitment to an infrastructure that people can build on relying on it to be stable over a five year period at the very least. Which is actually a rather short time for a non cryptographic infrastructure. Taking that decision would do a lot more for Internet security than winding down the issue interval because it would force us to be a lot more proactive in planning for deployment of successor algorithms. In fact we would probably decide now is the time to deploy SHA-3
> Respectfully, if that is your goal - "five year stability" - then frankly, I must suggest you're ignoring the world we live in or have lived in. Technological 'innovation' is not measured in five year durations, nor would anyone with any experience in computer security reasonably suggest that a system is stable under adversarial conditions under a five year period. I'd be curious for any information you have, whether in the digital realm of security or in the physical realm of security, where a system can reasonably be designed to "survive five years of attacks”.

Having been doing Web security for 25 years this year, I do not see the rapid change others see.

If PKIX was run as designed, with revocation checking turned on and new cryptographic algorithms had been deployed in the browsers within 2 years of publication, very few of the security crises of the past 25 years would have burned us.

It is of course instructive to look at the ones that would. Most of those being coding errors or design errors in the protocol.

> For that matter, and more for curiousity than relevance to this discussion, I'd be curious for any information for any historic events for which 'prospered and grew while under active attack for five years' was noted. In most cases, undergoing siege when unprepared generally results in destruction, whether we talk about cities and countries or we talk about CAs and industries. And it's worth noting that the CA industry, as a bulwark of Internet security, has very much been under active attack, and has very much been unprepared for that - as we have clear evidence showing.

How many times has a browser corrected a security bug in coding over the past ten years? Do you really think that CAs rather than browser code represents the achilles heel?

We knew how to write code that didn’t have buffer overrun vulnerabilities in 1980 when my college tutor used his Turing Award speech to warn people that the lack of array bounds checking would lead to tears. But the warnings were ignored and none of the browsers I am aware of are written in managed code.

> In short, I think many of your points are eloquent but not accurate, appealing but not relevant, and would hope we can focus on the more substantive question of asking whether you can demonstrate a counter-factual to the many assertions and benefits I noted related to certificate validity.
> And if you still believe 'stable for five year period' is an achievable goal, I simply have one word to say: Heartbleed.

As I just pointed out, that was avoidable using readily available technology. Write your Web Server in C# or Java or even LISP and it won’t have Heartbleed vulnerability.

Come to that, run the server on a platform that provides separation between the cryptographic keys and the processes making use of them and you can’t lose your private key that way. Windows has that built into the cryptography API, its been that way since the 90s. You can even get the same isolation in Linux if you use GPG Agent.

Until recently none of this mattered because we were still used to treating the Internet as a science project. The priorities have always been features and speed. Well maybe that is changing and maybe we are in a different situation.

Of course achieving five year stability will require resources. But it is a lot easier than a moon shot. And it is a requirement that I expect will be pushed down on the industry in the coming years regardless of whether we want to recognize it because IoT devices have even longer lifecycles and are being built by people with no understanding of security at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170206/a299f6c3/attachment-0003.html>

More information about the Public mailing list