Re: [saag] [websec] Pinning

Trevor Perrin <trevp@trevp.net> Sat, 11 August 2012 18:16 UTC

Return-Path: <trevp@trevp.net>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F8921F84C9 for <saag@ietfa.amsl.com>; Sat, 11 Aug 2012 11:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRzpacrWdPBp for <saag@ietfa.amsl.com>; Sat, 11 Aug 2012 11:16:03 -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 490F321F84C8 for <saag@ietf.org>; Sat, 11 Aug 2012 11:16:03 -0700 (PDT)
Received: by yenm5 with SMTP id m5so2652919yen.31 for <saag@ietf.org>; Sat, 11 Aug 2012 11:16:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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=Z0F4Suuho3f1sneZiERcGOe7ad4YSMGgTX7zhwzhzS+50hX3orCmMEXZu5REORWOzQ xsIaDTk0G1LVz/dJRjdpaYDtt8Zfhdhj6067qU3PwodFnCm76i1T+Z8cO67LfV3MUvGk P4xinTB8nHadL8dkKB+piOC3QE392poD2wux1Uw/2dhVIRdhLfmgYYajZutg69mU6kPo u3xEtB9xRs4Zwkce2N19SwTiJZrfUwkLHVysg2HoVZmPqux2QNfk2BA8k8hNGdZkojVZ KEwOeDbvRUyp9ZQ4Nz1yrFncen6lxLwx2I0qoIpiTrfqhxO7zmvBMpEvtYWz/tcU6Hz1 w9QA==
MIME-Version: 1.0
Received: by 10.42.92.17 with SMTP id r17mr4403742icm.39.1344708962627; Sat, 11 Aug 2012 11:16:02 -0700 (PDT)
Received: by 10.64.78.200 with HTTP; Sat, 11 Aug 2012 11:16:02 -0700 (PDT)
X-Originating-IP: [67.127.59.13]
In-Reply-To: <CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com>
References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> <CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com>
Date: Sat, 11 Aug 2012 11:16:02 -0700
Message-ID: <CAGZ8ZG0K+R93mQFtmQns0ahSbNqwXv+rSO78nEXNn=UweZqsrg@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Chris Palmer <palmer@google.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnLAgTD2rtcEuZm9ux5x3kVG9lIY5/dTmPVZuaaBL9CcpByOPpiLunoadrwKepiO4s4zvR9
Cc: Chris Evans <cevans@google.com>, websec@ietf.org, saag@ietf.org, Moxie Marlinspike <moxie@thoughtcrime.org>
Subject: Re: [saag] [websec] Pinning
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=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 <palmer@google.com> 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,
generations)...


> 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).


Trevor