[cabfpub] [cabfman] Improving the security of EV Certificates

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Thu Dec 19 04:07:09 UTC 2013

Ryan – out of curiosity, how did you come up with an estimated cost on CAs of CT implementation of $10,000 per year per CA?

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Wednesday, December 18, 2013 1:11 PM
To: Eddy Nigg (StartCom Ltd.)
Subject: Re: [cabfpub] [cabfman] Improving the security of EV Certificates

Hi Eddy,

Thanks for allowing this to be posted to the public list. I've attempted to reply to your points below.

On Wed, Dec 18, 2013 at 9:55 AM, Eddy Nigg (StartCom Ltd.) <eddy_nigg at startcom.org<mailto:eddy_nigg at startcom.org>> wrote:

On 12/18/2013 07:28 PM, From Jeremy Rowley:
Pinning is more risky for unsophisticated users who could brick their systems.

I don't think so....such users would never use it, the same way such users would never investigate a log or list of certificates.

Plus, pinning becomes a market divider so I’d worry about anti-trust violations if the recommendation came from the CAB Forum.

How come, can you explain?

Much in the same way that some CAs object to CAA. Any notion of having the CA/Browser Forum encourage that users use technological means to say "I have relationships with these CAs, and I would prefer [other CAs] not issue" seems to scare some members. I do not believe this is at all warranted, and is more likely a mischaracterization of the technology, but that's something to be deferred for your own legal counsel.

Both pinning and CAA are ways for customers to take control of the "Every CA is capable of issuing for every site" issue, which we see year after year, incident after incident to be the root cause of the continued erosion of trust in the CA ecosystem.

Transparency, in my view, is better because it requires a change only by the CAs and browsers, not by the users.  The information is then available for any researcher to digest and evaluate, not just the end user.

It's mostly the competing CAs!!!, software vendors, Netcraft and friends, and some researchers that care about it (EFF, Qualsys and some others). It's the same crowd that would use pinning too.

This is not true at all.

Auditors are not equivalent to site operators. Site operators carry great risk in pinning and getting it right - it certainly provides preventative benefits, but with an operational complexity cost. Further, organizations like EFF, Qualsys and others cannot defer those costs on behalf of the site operator. It's a risk they bear on themselves.

Pinning offers the ability for anyone, without risk to their operational capability, to look to examine for misissuance - past or present. This presents zero risk for the site operator, at a cost born by the CA, whereas today's system of global issuance capability with no auditing is a zero-cost-to-the-CA, with risk and cost born by every single site that would ever wish or does use SSL.

A headache is when another DigiNotar is compromised , issues a couple thousand certificates fraudulently, and covers it up for several months.

Truly a problem, but may be attacked from a different angel (how about different approach  to auditing?). I mean, we are doing our utmost to comply to all the various requirements and much more than that - a price we are willing  to pay because for this we are here. Now this proposal has a significant price tag for something that hasn't been tested and used over time with the "only" goal to detect the next DigiNotar.

Every single public CA security incident we have seen in the past 3 years would have been detected immediately from a system like CT. Trustwave, Diginotar, Turktrust, and most recently, ANSSI were all detected through luck and vigilance, and only because they happened to affect a large site whose engineers are using every means capable to them to attempt to detect such mis-issuance.

For all we know, there may be thousands of other misissuances from existing CAs - whether well-meaning or not - that have gone unnoticed, simply because they did not decide to affect one particular site. CT makes it possible for anyone - from Joe Schmo on the street with his $10 certificate, to the multi-billion dollar multi-national with engineers committed to dealing with just this issue - to detect misissuance.

I think you're pretty grossly understating the benefit here.

IMO pinning can achieve the same way cheaper (for me). And again, if we could combine revocation for example, the benefit would be much bigger and trade off the expenses/efforts...

Assume the cost of pinning is $100/year/site.
Assume the cost of CT is $10,000/year/CA.

By any measure, CT has a far bigger benefit with far fewer expenses, efforts. And that's using a very generous understatement of pinning's costs (operationally), which is likely several orders of magnitude higher as the profile of the site increases. And even if CT itself carries with it several orders of magnitude more cost, the math *still* works out, because there are *millions* of sites that use SSL, and *millions* more that should, and if your idea is pinning is right for everyone, then you're asking inordinate amount of costs to be born for all users, many of which who may and are happy with "detection" over "prevention" for their risk/reward profile.



Eddy Nigg, COO/CTO

StartCom Ltd.<http://www.startcom.org>


startcom at startcom.org<mailto:startcom at startcom.org>


Join the Revolution!<http://blog.startcom.org>


Follow Me<http://twitter.com/eddy_nigg>

Management mailing list
Management at cabforum.org<mailto:Management at cabforum.org>

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131219/05f39935/attachment-0003.html>

More information about the Public mailing list