[websec] dual meaning of "pinning" [was: Re: [Uta] Proposed list of deliverables]
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 20 January 2014 15:44 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D641A017C; Mon, 20 Jan 2014 07:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1jP2y74nP4T; Mon, 20 Jan 2014 07:44:45 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 487AC1A0162; Mon, 20 Jan 2014 07:44:45 -0800 (PST)
Received: from [192.168.13.107] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 68AD2F985; Mon, 20 Jan 2014 10:44:43 -0500 (EST)
Message-ID: <52DD4468.5010304@fifthhorseman.net>
Date: Mon, 20 Jan 2014 10:44:40 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>, "Orit Levin (LCA)" <oritl@microsoft.com>
References: <0bc674da169f4772b0fb2173ed679115@BY2PR03MB300.namprd03.prod.outlook.com> <52DD0DC4.4010207@isode.com>
In-Reply-To: <52DD0DC4.4010207@isode.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="rPbCbKfeVok3WFW9GofrT2o6GnxMuddjg"
Cc: "uta@ietf.org" <uta@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, Chris Evans <cevans@google.com>, IETF WebSec WG <websec@ietf.org>, Barry Leiba <barryleiba@computer.org>, Ryan Sleevi <sleevi@google.com>
Subject: [websec] dual meaning of "pinning" [was: Re: [Uta] Proposed list of deliverables]
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 20 Jan 2014 15:44:47 -0000
On 01/20/2014 06:51 AM, Alexey Melnikov wrote: > http://datatracker.ietf.org/doc/draft-melnikov-email-tls-certs/ > http://datatracker.ietf.org/doc/draft-moore-email-tls/ Both of these drafts use the term "pinning" in line with the way it is used in RFC 6125, which is in contradiction to the way the term "pinning" is used in websec's Key Pinning draft: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ In 6125 and the two e-mail drafts above, "pinning" is used to refer to the activity that firefox describes as "adding a security exception" and chrome calls "proceed anyway" -- where the user (or someone) overrides the TLS verification stack to indicate that a particular certificate is acceptable to them for a particular site, regardless of the name or other entity identifiers found in the certificate. I'd call this "permissive" pinning, since it increases the set of acceptable certificates in general. In the draft-websec-key-pinning, the term "pinning" is used to indicate a set of keys (not certificates) that the server communicates to the client which *must* be used for future connections to that server. I'd call this "restrictive" pinning, because it reduces the set of acceptable certificates in general (certificates that are signed by other trusted root authorities over end entity keys that aren't in the set of pins will be considered unacceptable). Even worse, these two "pinning" ideas could overlap for a particular browser/website: a site could use the restrictive key pinning to indicate which public keys are acceptable, and then offer a certificate over one of those keys which isn't signed by a root authority accepted by the client; so the client would need to "set a security exception" or "proceed anyway", which is forbidden by draft-ietf-websec-key-pinning (section 2.6). But it's also possible that the user already added a "permissive" pin (a "security exception") for that web site before receiving draft-ietf-websec-key-pinning pinning instructions from the web server :/ I think we're heading for trouble with this terminology overlap, in a space that is already difficult to understand for implementers, server administrators, and browser users. but i don't know how to best avoid further confusion. In the server administration circles i travel in, people who are security conscious tend to associate the term "pinning" with the ideas behind draft-ietf-websec-key-pinning. If you tell them that "setting a security exception" in firefox is also "pinning", it will cause no small amount of concern (since their goal in deploying public-key-pinningis to avoid having their users tricked by an MITM offering bogus certificates). OTOH, RFC 6125 itself is published, so its meaning of "pinning" won't be going away any time soon :/ At the very least, it seems like new drafts should make it clear that their meaning of "pinning" does not mean the other well-known "pinning". Any better suggestions for avoiding the ambiguiity? --dkg
- [websec] dual meaning of "pinning" [was: Re: [Uta… Daniel Kahn Gillmor
- Re: [websec] dual meaning of "pinning" [was: Re: … Chris Palmer
- Re: [websec] dual meaning of "pinning" [was: Re: … Daniel Kahn Gillmor