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
- [saag] Pinning Sean Turner
- Re: [saag] Pinning Henry B. Hotz
- [saag] Fwd: [websec] Pinning Yoav Nir
- Re: [saag] [websec] Pinning Paul Hoffman
- Re: [saag] Pinning Steven Bellovin
- Re: [saag] [TLS] Fwd: Pinning Nikos Mavrogiannopoulos
- Re: [saag] [websec] Pinning Tobias Gondrom
- Re: [saag] Pinning Ben Laurie
- Re: [saag] [websec] Pinning Chris Palmer
- Re: [saag] [websec] Pinning Paul Hoffman
- Re: [saag] [websec] Pinning Trevor Perrin
- Re: [saag] [websec] Pinning Jeffrey Hutzelman
- Re: [saag] [websec] Pinning Tony Finch
- Re: [saag] [websec] Pinning Alexey Melnikov
- Re: [saag] [websec] Pinning Tobias Gondrom