Re: [websec] [saag] Pinning

Trevor Perrin <> Sat, 11 August 2012 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10EA421F84A1 for <>; Sat, 11 Aug 2012 11:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ivIc82d72dPR for <>; Sat, 11 Aug 2012 11:16:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4432121F84B5 for <>; Sat, 11 Aug 2012 11:16:03 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so2482799ghb.31 for <>; Sat, 11 Aug 2012 11:16:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=lTUibbTXkpNEO56DtfydqlyEzmEq5SzjN79KjpgVv0U=; b=J6XRpB9uMRz1PaYkxHf/9MY81yha81SUwP/V11YgTtOyzK8k/X9rpxKfwY1i3LZGjk bVw22fJIYI8TjCfcmW2ap4KvZEN1gaS8ohruzU2RAA+tOb/57F8YAmNbnuPvJQkWhla7 smA6AaPD/bY5dbzhZitq1Ot3BNWf59OJ/rmEdQ84LhLeWnYttQisVRY4w+SJspsGsdad ZigobTevKmKXP1Xn+v7xsoKHbhBGsEEtnZ0RKgcXoV+BaQZxKNd2TKXqT/j8AKx+ffSW K8stXafnXQ6MW9lxyIRmyNR/gwSIROeXmXYbsTtYW0q6NBSb9UOg/t3b/WOKwKFKhvLZ u8zg==
MIME-Version: 1.0
Received: by with SMTP id r17mr4403742icm.39.1344708962627; Sat, 11 Aug 2012 11:16:02 -0700 (PDT)
Received: by with HTTP; Sat, 11 Aug 2012 11:16:02 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <>
Date: Sat, 11 Aug 2012 11:16:02 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Chris Palmer <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlagtxLrbLdB5q7zxWoZllZMxoN2emJJYE2n/4U7CQZbFjwdRFZz9X/VP/SkcVQmiW5/zCI
Cc: Chris Evans <>,,, Moxie Marlinspike <>
Subject: Re: [websec] [saag] Pinning
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Aug 2012 18:16:04 -0000

Hi Chris, all,

On Fri, Aug 10, 2012 at 3:20 PM, Chris Palmer <> wrote:
> So ultimately I do think we should decide on either HPKP or TACK, but
> that we should make that decision after there has been some real-world
> deployment experience with both (or, sadly, real-world non-deployment
> of one or both).

My 2c: We should keep exploring both TACK and HPKP.  I'd like to see
both proposals fleshed out, so we can do an in-depth comparison.
We'll try to send a draft-01 in a couple weeks.

> Additionally, HPKP and TACK might converge, more or less. I have plans
> to publish a new HPKP I-D that borrows some of TACK's pin activation
> and expiration ideas, for example.

Awesome, looking forward to it.

There's some things you'll have to grapple with (is pin activation
performed for each key individually, or for the keys as a set?  when
is it performed?  etc.)

> Additionally, one of the main criticisms of HPKP is that it is tied to
> HTTP. I currently don't consider that a huge problem — even though I
> consider TACK's TLS-generic-ness a nice benefit — for several reasons:
> * HTTPS is the big, important application that we need to secure right now.

Agreed: TACK's TLS-generic-ness is a nice benefit, but a good solution
for HTTPS is more important than reusability.

> * It's not clear that SMTP over TLS is very beneficial, because you
> can't stop delivery due to pin validation failure (or really even
> regular old X.509 failure).

Pinning for MTA-to-MTA SMTP seems useful.  Since receiving MTAs often
have invalid certificates, they're hard to authenticate any other way.
 If a sending MTA doesn't want to reject connections on pin failure,
it could run in "warn-only" mode.

> * SSH already has PKP. :)

Not proposing to change that.  But a TACK_Extension *could*,
theoretically, be embedded in non-TLS, non-X.509 protocols...  And
TACK *does* have some nice lifecycle features (activation, break sigs,

> And finally, as Ben Laurie pointed out, there is also Certificate
> Transparency. I personally consider the "public log" class of
> solutions (of which CT is a leading member, along with Sovereign Keys)
> to be The Real Solution. Pinning-like solutions (including HPKP and
> TACK) are a good, quick fix — as long as they are quick and simple.

I think pinning is likely to coexist or integrate with future trust systems.

For example, Cert Transparency is cool and would help detect bad
certs, but pinning would prevent their use.  I think sites would want
to deploy pinning even in a CT world.

Also, self-asserted pins like TACK and HPKP can be detected by trust
infrastructure (think Convergence or Google Cert Catalog) which
publishes them for auditors to review and for client apps to download.
 So, in a broad sense (pinning, CT, Convergence) are all "public
knowledge" systems which have some similar benefits.

Anyways, quick and simple is always good, but we shouldn't view
pinning as a disposable technology.  (Not that you're saying that, but
just don't want it to be misconstrued).