Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

Tao Effect <contact@taoeffect.com> Tue, 17 December 2013 20:35 UTC

Return-Path: <contact@taoeffect.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A0F1A9313 for <therightkey@ietfa.amsl.com>; Tue, 17 Dec 2013 12:35:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNmZBs0bxM0b for <therightkey@ietfa.amsl.com>; Tue, 17 Dec 2013 12:35:21 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 15A8F1ADF0E for <therightkey@ietf.org>; Tue, 17 Dec 2013 12:35:21 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id EE065208070; Tue, 17 Dec 2013 12:35:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=lGPw1voSkb0x0FYL6 ZY1W+vbjFQ=; b=gc7mc2xsEbhsEyr71YHRTPBfYOxWgH1CrxjeHfXrX/mkK9UMI UfFau/9ityCg0bc0f2fJimStg4+wpsUrHatrU19DKrjDfU2vzbEMtVvNlujZl0sj fIf0ymzJoxHwig0eVHRSYg2HtY9qygACV/I11F9pkLD89VrlvSOmOFiiZk=
Received: from [192.168.2.3] (ip98-180-48-204.ga.at.cox.net [98.180.48.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id 9A436208063; Tue, 17 Dec 2013 12:35:16 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1452B3D6-D97E-4210-89F0-0E2A3F861587"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <625EF7DC-7769-44AF-8D4D-2345DF841DD4@taoeffect.com>
Date: Tue, 17 Dec 2013 15:35:13 -0500
Message-Id: <673A824A-7A9A-47B5-845E-F0F60BF5A63D@taoeffect.com>
References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com> <CAMm+LwiMXdEnHqD0y_S-fP6081Tk=A=7-9LsJQhRuawmmmfdTg@mail.gmail.com> <FEFA307D-97E0-4C58-AB43-5B9AB8E8FC70@taoeffect.com> <CAMm+Lwjwww28tV_qvqQVH3xo1xqvjb6z++258+LOqgxWn-Oh9w@mail.gmail.com> <1D1AAD8E-3787-4E95-8694-6EB0B4A60890@taoeffect.com> <CAMm+LwgnMhtLZ6RhE0kioRF4qEZrzsT8c5zwyP4cR=R+g6z_qw@mail.gmail.com> <582F125D-03E5-4793-9F48-B68E9F23B7C3@taoeffect.com> <625EF7DC-7769-44AF-8D4D-2345DF841DD4@taoeffect.com>
To: Tao Effect Support <contact@taoeffect.com>
X-Mailer: Apple Mail (2.1827)
Cc: "therightkey@ietf.org" <therightkey@ietf.org>, Phillip Hallam-Baker <hallam@gmail.com>
Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 20:35:25 -0000

The list moderator asked a few participants (including myself) to let this issue go, but I just want to mention that I've posted a minor update to the PDF, and have included a link to this thread in it, as well as a footnote next to the 600+ figure, mentioning that, "Phillip Hallam-Baker disputes the EFF’s figure on [therightkey] mailing list, but did not provided citable references for his claims."

URL remains the same, but it should say Version 1.1 in the lower-left of the cover page:

http://okturtles.com/other/dnsnmc_okturtles_overview.pdf

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Dec 16, 2013, at 5:54 PM, Tao Effect <contact@taoeffect.com> wrote:

> Oh, sorry, I just saw (after sending that email), that I didn't answer your question.
> 
> Why bother quoting it at all? Because whether the number is 600+ or 300+, it still serves to support the point that browsers will take the word of any one of over a hundred potentially untrustworthy strangers as "proof" that a connection to a website is secure.
> 
> - Greg
> 
> --
> Please do not email me anything that you are not comfortable also sharing with the NSA.
> 
> On Dec 16, 2013, at 5:48 PM, Tao Effect <contact@taoeffect.com> wrote:
> 
>> On Dec 16, 2013, at 5:37 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>> 
>>> Since the 600 number is inaccurate and not particularly necessary, why bother to quote it at all?
>> 
>> Dude, how did you manage to ignore that entire email?
>> 
>> One more time, since you somehow missed it:
>> 
>>>> OK, in order for me to correct this in the paper I need the following information:
>>>> 
>>>> 1. A link to who "DFN" is.
>>>> 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are shipped with (and details about this, like, do all 3 major browsers include DFN?)
>>>> 3. A link to a paper, a blog post, or an article somewhere that describes in detail your side of the argument
>>>> 
>> 
>> 
>> You cannot just say "the EFF is lying", throw your hands in the air, and leave it at that.
>> 
>> Unlike you, the EFF provided sources and proof for their claim.
>> 
>> The then wrote a widely cited blog post containing their claim and their evidence for it.
>> 
>> Where is your blog post? Where is your evidence that the EFF is lying?
>> 
>> These emails of yours don't cut it. Heck, I'd even post a link to an archived email of yours if you provided the necessary information in it.
>> 
>> - Greg
>> 
>> --
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>> 
>> On Dec 16, 2013, at 5:37 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>> 
>>> When you make an assertion in a paper then you are accepting the burden of proof. 
>>> 
>>> 
>>> If the source for the '600' claim was lying then the claim has to be taken off the table completely. The DFN root issue demonstrates that the methodology is bogus rather than just being a single inaccurate data point.
>>> 
>>> If you want to make assertions about the number of CAs then the most accurate measure currently available is still the number of roots in the commonly used browsers. While there are a handful of CAs using roots cross certified by another CA, such CAs now have to have a full audit statement and meet all the acceptance criteria in their own right. So there would be little point in not applying to have the root entered in independently.
>>> 
>>> Since the 600 number is inaccurate and not particularly necessary, why bother to quote it at all?
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Dec 16, 2013 at 1:44 PM, Tao Effect <contact@taoeffect.com> wrote:
>>>> Which kind of calls their credibility into question. HALF the 'CAs' in their graph are from the DFN root. You can check that out for yourself, it is a German CA that issues certs to higher education institutions. As has been demonstrated (and agreed by the EFF people), DFN do not sign certs for key signing keys they do not hold.
>>>> 
>>>> You can't calculate the number of CAs the way the EFF tried to. An intermediate certificate does not equate to a CA. Pretending it does to peddle an alternative PKI scheme calls into question their veracity.
>>>> 
>>>> I have tried to get members of the EFF board to look into this but they never get back. Too much trouble to get it right.
>>> 
>>> 
>>> OK, in order for me to correct this in the paper I need the following information:
>>> 
>>> 1. A link to who "DFN" is.
>>> 2. A 'yes' or 'no' as to whether DFN is a root cert that browsers are shipped with (and details about this, like, do all 3 major browsers include DFN?)
>>> 3. A link to a paper, a blog post, or an article somewhere that describes in detail your side of the argument
>>> 
>>> Let me emphasize that none of this ultimately matters to the points that were made in the paper.
>>> 
>>> Whether the number is 600+ or 300+, it's still an insecure, broken mess.
>>> 
>>>> I was under the impression that Bitcoin was the preferred currency of libertopia. It is the only one that gets mention in the mainstream press. It is not clear to me how namecoin can be part of BitCoin and another currency.
>>> 
>>> 
>>> I'll be happy to clear this up:
>>> 
>>> - Bitcoin is not the "market leader" of distributed DNS systems. Namecoin is.
>>> - Namecoin and Bitcoin are designed with completely different goals in mind. They are not competitors.
>>> - Namecoin is not intended to be a bitcoin replacement, nor the other way around. It is not like "litecoin" or any of the other bitcoin competitors, because it is not a competitor to bitcoin.
>>> 
>>>> Gold Age, eGold, Liberty Reserve. All the ones that were taken apart by the Feds.
>>> 
>>> 
>>> I'll be happy to clear this up too:
>>> 
>>> None of these are comparable to Bitcoin or Namecoin.
>>> 
>>> Neither "Gold Age", nor "eGold", nor "Liberty Reserve" were truly decentralized, distributed currencies.
>>> 
>>> - "Gold Age" was not a currency: https://en.wikipedia.org/wiki/Gold_Age
>>> - eGold: Centralized currency with no "reliable user identification" (not a problem with Bitcoin or Namecoin)
>>> - Liberty Reserve: Centralized currency https://en.wikipedia.org/wiki/Liberty_Reserve#Background
>>> 
>>> People who are standing back and scratching their heads, wondering why Bitcoin is still around after years of being used to purchase illegal drugs, murder-for-hire, and weapons (continuing to this day btw), simply don't understand what Bitcoin is.
>>> 
>>>> I might be a little more inclined to make an effort if you hadn't attacked me as being 'fraudulent' in your opening.
>>> 
>>> 
>>> Do you represent a company that sells SSL certs? It seems like you might:
>>> 
>>> During twelve years as Principal Scientist at VeriSign Inc.,
>>> 
>>> Perhaps the paper is a bit harsh (and I welcome suggestions to improve its language), but the critiques it levies against companies that sell SSL certs are completely valid:
>>> 
>>> Companies that sell SSL certificates usually claim that their certificates provide customers with “security.” Customers are led to believe that these certificates protect browser-server communication from eavesdropping and tampering. As elaborated in this paper, this simply isn’t true today.
>>> 
>>> I have to say, that among the cert companies websites that I looked at, VeriSign's homepage makes the fewest claims about the security protections it provides.
>>> 
>>> The words "usually claim" leaves room for exceptions. I could not find, on the customer-facing pages on VeriSign's site, any claims that VeriSign's SSL certs "protect browser-server communication from eavesdropping and tampering."
>>> 
>>> Some close calls are:
>>> 
>>> In short, when it comes to securing online transactions, safeguarding customer information, and protecting business reputation, you're only as safe as the Certificate Authority you choose.
>>> https://www.symantec.com/ssl-certificates-advantages
>>> 
>>> Customers Gain Confidence with the Green Address Bar: Online shoppers recognize the green address bar as an easy and reliable way to verify the site identity and security.
>>> https://www.symantec.com/verisign/ssl-certificates/secure-site-pro-ev?fid=ssl-certificates
>>> 
>>> VeriSign's SSL certificates do not provide websites with meaningful protection as defined in the DNSNMC paper because they cannot be securely authenticated in the face of a fraudulent certificate that's presented to customers by a MITM.
>>> 
>>> If your certs can simply be replaced by any of the other CAs out there, then *all* of the security they provide is thrown out the window.
>>> 
>>> Furthermore, because VeriSign is a random third-party, not the company that user's visit when they visit a site using VeriSign's certificate, the protection offered by that certificate is inherently inferior to a securely authenticated self-signed certificate.
>>> 
>>> This is simply mathematics, and not a point that's up for debate.
>>> 
>>> When trust is distributed across more parties, that trust is diluted because it now depends on the least secure of those parties.
>>> 
>>> Sidenote:
>>> 
>>> It seems like I was sent "to the sharks" so to speak (perhaps as a practical joke?).
>>> 
>>> So far almost half of the replies to this thread have come from representatives of SSL companies.
>>> 
>>> The hostility is therefore no surprise.
>>> 
>>> --
>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>> 
>>> On Dec 15, 2013, at 9:21 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sun, Dec 15, 2013 at 8:50 PM, Tao Effect <contact@taoeffect.com> wrote:
>>>>> And for someone who is accusing others of being 'fraudulent', not a good move to start off repeating figures already exposed as bogus like the oft repeated but still untrue claim of 600 CAs.
>>>> 
>>>> 
>>>> I thought the EFF was a reputable source.
>>>> 
>>>> There has been no update or correction to their post: https://www.eff.org/deeplinks/2011/10/how-secure-https-today
>>>> 
>>>> Which kind of calls their credibility into question. HALF the 'CAs' in their graph are from the DFN root. You can check that out for yourself, it is a German CA that issues certs to higher education institutions. As has been demonstrated (and agreed by the EFF people), DFN do not sign certs for key signing keys they do not hold.
>>>> 
>>>> You can't calculate the number of CAs the way the EFF tried to. An intermediate certificate does not equate to a CA. Pretending it does to peddle an alternative PKI scheme calls into question their veracity.
>>>> 
>>>> I have tried to get members of the EFF board to look into this but they never get back. Too much trouble to get it right.
>>>> 
>>>> 
>>>>> Tying the notary log to namecoin seems to be completely pointless to me, unless the real objective is to promote namecoin. Why hook into namecoin rather than the market leader? 
>>>> 
>>>> 
>>>> What market leader?
>>>> 
>>>> I was under the impression that Bitcoin was the preferred currency of libertopia. It is the only one that gets mention in the mainstream press. It is not clear to me how namecoin can be part of BitCoin and another currency.
>>>> 
>>>>  
>>>>> Given the success of the US government in shutting down eGold type schemes I am very skeptical about the stability of 'namecoin'. If we accept the purported scenarios that motivate the scheme then namecoin won't last very long.
>>>> 
>>>> What eGold scheme are you comparing Namecoin to?
>>>> 
>>>> Gold Age, eGold, Liberty Reserve. All the ones that were taken apart by the Feds.
>>>> 
>>>>  
>>>> Are you sure you know what you're talking about here...? ;-)
>>>> 
>>>> I must admit that I find the scheme completely confused and assumes that I know a lot that I do not.
>>>> 
>>>> I might be a little more inclined to make an effort if you hadn't attacked me as being 'fraudulent' in your opening.
>>>>  
>>>> 
>>>> -- 
>>>> Website: http://hallambaker.com/
>>>> _______________________________________________
>>>> therightkey mailing list
>>>> therightkey@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/therightkey
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Website: http://hallambaker.com/
>>> _______________________________________________
>>> therightkey mailing list
>>> therightkey@ietf.org
>>> https://www.ietf.org/mailman/listinfo/therightkey
>> 
>> _______________________________________________
>> therightkey mailing list
>> therightkey@ietf.org
>> https://www.ietf.org/mailman/listinfo/therightkey
> 
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey