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

Ryan Sleevi sleevi at google.com
Mon Feb 6 15:46:42 UTC 2017

On Mon, Feb 6, 2017 at 7:34 AM, philliph at comodo.com <philliph at comodo.com>

> 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.

> Of course reducing the validity interval will improve some security metric
> by some iota. But the real purpose of the change is to react to the SHA-1
> circumstance. Which is fine.

Well, it's false as well, so that's probably not fine. That is, I object to
your notion of attributing a specific intent and motivation to my proposal,
particularly when it's one at very odds with what I've stated. I appreciate
your perspective, but I don't appreciate you telling me what I am thinking
or intending or proposing.

> 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.

> 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.

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.

> 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".

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170206/5dda874f/attachment-0003.html>

More information about the Public mailing list