[Cryptography] Why Alexander Hanff won't be using "Let's Encrypt"

ianG iang at iang.org
Fri Dec 12 09:57:03 EST 2014

On 4/12/2014 14:34 pm, Phillip Hallam-Baker wrote:
> On Wed, Dec 3, 2014 at 2:00 PM, Tony Arcieri <bascule at gmail.com> wrote:
>> On Wed, Dec 3, 2014 at 7:09 AM, Henry Baker <hbaker1 at pipeline.com> wrote:
>>> 'It is an insane strategy by all parties involved - it removes all
>>> confidence in TLS certificates as far as I am concerned and I will
>>> absolutely not be using the service and have to strongly recommend others
>>> refrain from doing so as well.'
>> This is a silly argument. It presumes Let's Encrypt is going to have a
>> bigger problem with misissuance than commercial CAs. Turns out that
>> commercial CAs are good at misissuing certificates too.

He is making an assumption that existing CAs don't also have the 
problems he claims.  I don't know how he would go about proving that 
assumption, and I'm pretty sure it is dead wrong.  My working assumption 
would be the reverse.

>> Whether or not misissuance will be a big problem with Let's Encrypt remains
>> to be seen, but it's always been a problem with the CA system, and Let's
>> Encrypt probably isn't going to change that. Can they do any worse than,
>> say, DigiNotar?
> Well they seem to be making a push to remove the most important CA
> operational criterial which is the insurance requirement.

I'd say that Verisign removed that component themselves from 
architectural consideration by writing their contracts to eliminate 
liability to their clients.  To the extent that they did, other CAs 
followed suit, whether they understood or not.  If there is no 
liability, insurance is easy to get, and is only marketing.

As an aside, I don't think in my time in CAs (mostly 2005 to 2012) I 
came across a serious discussion of insurance.  There was one 
requirement about insurance written into EV but it included such a 
blatant "Verisign exemption" written into it (wte $bn companies could 
elect to self-insure), I don't know if anyone took it seriously.

> When I worked with Michael Baum, Warwick Ford and Michael Myers at
> VeriSign we established a system that was designed to provide a
> demonstration that a CA was demonstratively in compliance with its
> certificate policy. One aspect of that was audit, but audit is
> actually a fairly weak requirement on its own as the existence of
> corrupt audit firms like Arthur "Enron-Deloran-Sunbeam' Anderson.

Right.  Also, audit has been part of the game for so long they've 
ensured that their work is expensive, has little liability blowback, and 
is impenetrable to others.  It is no surprise that audit adds little, 
that's no longer its purpose.

I wrote all this logic up in a 7 part essay:
with comics ;)

> Putting the insurance requirement in was a meta control on the audit
> control. The reason insurance makes a difference is that the insurer
> has skin in the game while the auditor does not. There is no penalty
> for a sloppy audit but an insurer could be out a lot of money in the
> case of a failure.

OK, so to point:  how much can a user get back from such a insurance? 
Has Verisign or any other CA ever paid out to a user from an insurance 
contract?  Or even self-insurance, by covering losses from their own 
pocket?  Has an insurer ever been claimed against?

If the answer to these questions is NONE, NEVER then we have to ask what 
the point is.  If it shows no evidence of actuarial mechanics, it's 
there for another purpose.

> In the event DigiNotar failed in a manner that was not anticipated by
> our original architecture which was to provide a commercial service to
> enable e-commerce. Government actors were not considered in the design

This is Europe v. North America.  In the former, the regulator exists 
and is very prominent in their documentation and thoughts.  Considered 
essential.  In the latter, not.

> and at the time most people thought that we were being overly
> paranoid. Which given the number of failures since, we probably were.

Yeah.  So, up until the late 2000s, there was no real evidence of much 
attack against the system.  It was put in place on a theoretical 
security model pulled from some old text book.

But around about 2011 (I date it) the scene hotted up dramatically.  The 
problem then was that the industry had pretty much atrophied into its 
structure and had no capability to migrate.  One could not have said 
that about the mid 1990s when people were thinking about these threats 

> The browser providers find a security bug in their code every week. CA
> misissue is much rarer, so rare in fact that they decided they didn't
> need to bother with the revocation/status controls.

:)  See fig 6. here:


> One consequence of the manner in which DigiNotar was breached is that
> the company was shut down and put into bankruptcy through government
> decree. As a result the insurance controls were never activated, there
> wasn't time.
> The bigger problem with LetsEncrypt is understanding their finances
> and whether they can support free certificates at Internet scale. And
> while the marginal cost of issuing a certificate is negligible, the
> fixed costs are far from negligible. It does not cost Intel very much
> to run raw silicon through their fab. The biggest variable cost in a
> chip is actually the carrier. But I just paid $500 for one of those
> chips because Intel has to recoup the multi-billion dollar cost of
> development and the fab.


> Open source software works fine because a billion times zero is zero.
> A billion times a 'negligible' cost starts to add up. Which is why
> open services tend to be free on introduction and gradually become
> limited and paid. My Verizon modem lets me subscribe to one of five
> built in 'free' dynamic DNS providers. Guess what, none of them is
> free any more for an unrestricted service. I have to keep renewing my
> account every 30 days to get free.

As an aside, CAcert which is arguably a forerunner to LetsEncrypt, was 
able to scale up to deliver the certs en mass.  However it wasn't able 
to crack a revenue model that enabled it to climb the audit barrier (*).


(*) noting of course that, as auditor, I was biased towards the question 
of increasing remuneration, to the extent that I failed them.

More information about the cryptography mailing list