Re: [websec] Certificate Pinning via HSTS (.txt version)

Phillip Hallam-Baker <hallam@gmail.com> Tue, 13 September 2011 22:32 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 AE00E21F8CAE for <websec@ietfa.amsl.com>; Tue, 13 Sep 2011 15:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level:
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 RrXFuQYXCKs9 for <websec@ietfa.amsl.com>; Tue, 13 Sep 2011 15:32:33 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5021F8C43 for <websec@ietf.org>; Tue, 13 Sep 2011 15:32:27 -0700 (PDT)
Received: by yie12 with SMTP id 12so1006407yie.31 for <websec@ietf.org>; Tue, 13 Sep 2011 15:34:34 -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=4zI8xxXCrDLhaNly1AaErBOHVAHE3RvzfWCFVNFo7ow=; b=EYgCPSi3EmOjO515bOA4SP6fuDwPNqHoYH1DkoCn27oD0eifXu9cQfb9BywXRxzgX9 XBpSVR5BYnp7oaa0JjVbceXICroph+W4Dr4hv8INJX18wvPM3yY4Rm4s6IhQjJyT5rzN +84LtdWJLb4TGazE+BjvIh9dR+8j/DfeBZdWs=
MIME-Version: 1.0
Received: by 10.101.11.36 with SMTP id o36mr5799472ani.74.1315953274824; Tue, 13 Sep 2011 15:34:34 -0700 (PDT)
Received: by 10.100.120.20 with HTTP; Tue, 13 Sep 2011 15:34:34 -0700 (PDT)
In-Reply-To: <6D3E0CA6-E990-4D89-9AEE-C03066D0656E@gmail.com>
References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im> <FA8A58ED-DD2B-446B-9F01-9D1D25140569@checkpoint.com> <4E6FB7CB.3020309@extendedsubset.com> <CAOuvq20H+pG1AF0u-=-Ow9oR=uGRb-wDwrFE6dPmT=HbvnO6VA@mail.gmail.com> <6D3E0CA6-E990-4D89-9AEE-C03066D0656E@gmail.com>
Date: Tue, 13 Sep 2011 18:34:34 -0400
Message-ID: <CAMm+LwgmXOFcqYzv4_PaCHfwemV_okQR4hFbX8rgG8ZE93+k2w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: davidillsley@gmail.com
Content-Type: multipart/alternative; boundary="0016e68ef4577ca9cc04acda3f52"
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Certificate Pinning via HSTS (.txt version)
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: Tue, 13 Sep 2011 22:32:37 -0000

I think that all this pinning stuff works a lot better if there is a
mechanism that allows a return to ground truth.

Since we are developing an Internet protocol, the mechanism for ground truth
should be DNS in my opinion.


It may be impractical to require DNSSEC secured responses in every case.
There are Denial of Communication issues (DoC) and there are real
performance concerns.

If however we are dealing with a case where an exception has occurred, it
seems reasonable to me for the response to be to attempt to pull DNSSEC
records via whatever guerilla mechanisms we end up deploying to bypass
censorship.


In other words, use pinning via HTTP header to provide pinning with minimal
performance impact but solve the tricky max age issues by relying on the DNS
and DNSSEC to provide ground truth when a policy violation is detected.

On Tue, Sep 13, 2011 at 5:24 PM, <davidillsley@gmail.com> wrote:

>
> On 13 Sep 2011, at 21:35, Chris Palmer wrote:
>
> <snip>
> sites; small sites may have to choose no pinning or potentially
> bricking their site (up to the maxAge window). This is not worse than
> the status quo."""
>
>
> What about sites which don't currently use https at all? The DNS records
> for theregister.co.uk were redirected the other week. An attacker who
> could do that could redirect to https, then set a very long max-age pin. At
> that point, they'd be dependent on the browser vendor unpinning affected
> users, right?
> David
>
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>
>


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