Re: [websec] Certificate Pinning via HSTS

Phillip Hallam-Baker <hallam@gmail.com> Wed, 14 September 2011 16:44 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8307721F8BB9 for <websec@ietfa.amsl.com>; Wed, 14 Sep 2011 09:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.464
X-Spam-Level:
X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84z3xTdc6XYe for <websec@ietfa.amsl.com>; Wed, 14 Sep 2011 09:44:44 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E392821F8BB2 for <websec@ietf.org>; Wed, 14 Sep 2011 09:44:43 -0700 (PDT)
Received: by yxt33 with SMTP id 33so1755914yxt.31 for <websec@ietf.org>; Wed, 14 Sep 2011 09:46:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RorZ0UeDNpbU65vPv9tKUML34Z/bY3fkHOkUtAYFLc8=; b=emn58RfR1LKXWCQ+635Ra+WF+of60FxzLC4QMbFGUnZzD13UolGTZRrcRSbmZEvpQM fda5SdM5Tu6fr5kphVre//hxOslnWyTQlI2lQdJnaCLiYO6c8+8grWUFyRUpQOHxO9UC Ccg92Bw41EbVH2Jva/LTNtGudPQe2v00OsGI0=
MIME-Version: 1.0
Received: by 10.100.192.5 with SMTP id p5mr40963anf.96.1316018812976; Wed, 14 Sep 2011 09:46:52 -0700 (PDT)
Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 09:46:52 -0700 (PDT)
In-Reply-To: <4E70C8E2.3050604@fifthhorseman.net>
References: <CAOuvq22p2qNnXRsK=PS=mxknnq4MrCWt0Np-N8su-iHXaWHqpg@mail.gmail.com> <4E6F5056.800@fifthhorseman.net> <CAOuvq22E-OvU_53gf_go8Nf_jXX_=wbTf7rn2XEa+GAWHTU+7w@mail.gmail.com> <4E70A8F8.80102@fifthhorseman.net> <CAMm+Lwj4LMjivR0nHWQ4eqkTz_WVTq8w5+QWGPSOat0KgvM3HA@mail.gmail.com> <4E70C4AB.7050206@fifthhorseman.net> <4E70C8E2.3050604@fifthhorseman.net>
Date: Wed, 14 Sep 2011 12:46:52 -0400
Message-ID: <CAMm+Lwi7KjcYjzGKCMyct31m7Gso0C9ZnUFUpUWcHrvb_BpZTw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: IETF WebSec WG <websec@ietf.org>
Content-Type: multipart/alternative; boundary="0016e6440216dd7d6504ace98187"
Cc: Chris Evans <cevans@google.com>
Subject: Re: [websec] Certificate Pinning via HSTS
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2011 16:44:44 -0000

They claimed 600 CAs on the Internet.

Their claim was disproved, the intermediate roots are not under direct
control of the customers.

They did not retract or clarify


That is not how reputable academics do their work. They were making a
political statement using Fox News type tactics.


On Wed, Sep 14, 2011 at 11:31 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net
> wrote:

> On 09/14/2011 11:13 AM, Daniel Kahn Gillmor wrote:
> >> This is why the bogus EFF study came up
> >> with the absurd number of 600 CAs. What they have never come clean on is
> the
> >> fact that 150 of those 'CAs' are in fact merely intermediate roots tied
> to a
> >> single customer that are managed in the same infrastructure as the root
> CA
> >> operations.
> >
> > if those intermediate authorities are not explicitly domain-restricted
> > *in their own certificate*, then yes -- the risk is larger.  i don't
>
> sorry -- this got cut off somehow.
>
> ... i don't think EFFs study is bogus in its analysis.  "the same
> infrastructure" doesn't mean "using the same access controls" --
> certainly customers in control of an intermediate root have more access
> to that root than other people, so there are additional risks to relying
> parties from them if they're not explicitly domain-restricted.
>
> Were these 150 intermediate certs explicitly domain-restricted in the
> certificates themselves?
>
>        --dkg
>
>


-- 
Website: http://hallambaker.com/