From dkg@fifthhorseman.net Mon Jan 20 07:44:47 2014 Return-Path: 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 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 , "Orit Levin (LCA)" 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" , Pete Resnick , Chris Evans , IETF WebSec WG , Barry Leiba , Ryan Sleevi 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 15:44:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rPbCbKfeVok3WFW9GofrT2o6GnxMuddjg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 --rPbCbKfeVok3WFW9GofrT2o6GnxMuddjg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS3URoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc+uAP/3a5mDvgXNTk2TRLOJFh6kOT tWxswcoiJNI7j9j0WL4xQI4wpdyCtJ8nzACIyMhFmK+E2k9c+sZ2rP69HF9e56Bg V1OTl2D/j5ZXbtme23hTOPrVLu0BvrvqAhSCvEYYP3AeAN9AXO9onNRMxfOQa76J gCF5KoT2ABv9yu2sOCA4UZyKFhVOirptOozPjk8CoVOGgsSQl6d+nLgclCYZafx7 iSouZcXPqyK8q3cmfiRNLw42ijChngnYNrQ8eNKZFPvMujrgi7dzBChmFXJwpyGQ xe0UccCrf8rEozE3fDbPVGMR9W6FoAVSMflg58jlLj08WxiRIR+7mKFucOPW6hiO e2iMSfMW3M0ymtwy7iHtPLQF9njqaSajgr7ZyWQGQ5IJusNHH3bmOZMDS6Gq29sz 5J+oHJvG5H8ajz+5rc39taAZ+g5TjK77uycoN7AC0QD28MlHPWYF8R4hfvSfa0F3 fkZ6utwdFLZCPCjyy6O6aJ5NyirkeLtWkqtEUAtDNgRGLu2Qhnfqh4aAgjZqLNUP 9I/e00sj08eGY+5Ob6zz/Mr+i0jc5Keqi0Xi+YmDmHczRt4oKVew0mf/sQw3CqOk 7gclcnFFWyP9hkwgLmT57p3+SmdAhKa8iHSM9oNKEUAueK9SzDAu9hr9pnceEI/x Sq5Rqv7OgQyoQWtru3MF =wygm -----END PGP SIGNATURE----- --rPbCbKfeVok3WFW9GofrT2o6GnxMuddjg-- From palmer@google.com Mon Jan 20 10:57:55 2014 Return-Path: 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 575D71A0247 for ; Mon, 20 Jan 2014 10:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=unavailable 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 ESUP3egvdQLa for ; Mon, 20 Jan 2014 10:57:54 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD761A0249 for ; Mon, 20 Jan 2014 10:57:53 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id ar20so3886680iec.24 for ; Mon, 20 Jan 2014 10:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=05B8X3+hvgin/A2p7gddY0Hp5+udUyMoZyPfVERJzqQ=; b=aEu13V/HEqYPCkGLrLozuYyqqJsl3n6HdX5kZzcBoPqNuETonzsXV3ic0H/53NYRF+ vS1OkHSALNwtNzsKShUkjsJoYrBlJ8hajCoPX0F/qfT99BlP2U6RbV+mgujTTIS+85qU QRLet/VMNZnLutkFvPB4OoSPoEJRtB1cd0N3jb43GCHSrMEmKAObfSOAFrE92GcdhSG3 oq3KHMY0DiFjmcioOwV10zO8FwlBn04+Pgj3AWHu586s1wB39l9Cq1xaGwPLoKretitZ nK7Ba3RYhghYubUdgxd5bmwlYfvNwzf9yjnjEXWQPXc7ORjntk3XiVwd9eH2SKP1afal mrkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=05B8X3+hvgin/A2p7gddY0Hp5+udUyMoZyPfVERJzqQ=; b=R3IlXHPjTcLzvbjXDpxDrKNXgs36CExzN2k26RfWOXwl106E+bD7z/pmj2yZBo7suA P3/VQciOJ22BbqwSgtYUzKT5OulfzCZ9H3mnZ97PP07AvgnuipPJGCArfFTIsWq0+vPC Xl2GSfu20w/GOeOqEjkSwvsIdJ+SSRJ9C2pM/onvVhG4QhDpYF0ohA5JvITy6A2ytrNT xZPsBrCyvw35K+L721eDih5pDMSvd3Hz+jfW3ybvyFjGNtvjd1L9h0rElRySR6nyvMG0 K8iF4mWxZMtncVd5KFCBqnO1j7e2RGOSRcLhD2MzI+7X0QYzKs7xFb1QCtXUGkNn74Pc Ex0A== X-Gm-Message-State: ALoCoQm7fxXGTwh1S90xZeCGfgBiI483OicD/JKU+iHJtKcOIg/gFAIvn8MV402DGVUwjXiRv3tKufskcRC2A43SmfJhZvdLlzoAMVXQP6xOMSjFOHWCExEA1pxwRWInLPZZFq3ZDFNcDUGHl+xEeMAcS/NeErCIFvjhleRoHe93nNCrOR/dW7ivxIRHkKKmAPsjNn7WiW8l MIME-Version: 1.0 X-Received: by 10.50.60.99 with SMTP id g3mr4366039igr.13.1390244273421; Mon, 20 Jan 2014 10:57:53 -0800 (PST) Received: by 10.64.81.16 with HTTP; Mon, 20 Jan 2014 10:57:53 -0800 (PST) In-Reply-To: <52DD4468.5010304@fifthhorseman.net> References: <0bc674da169f4772b0fb2173ed679115@BY2PR03MB300.namprd03.prod.outlook.com> <52DD0DC4.4010207@isode.com> <52DD4468.5010304@fifthhorseman.net> Date: Mon, 20 Jan 2014 10:57:53 -0800 Message-ID: From: Chris Palmer To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Cc: "Orit Levin \(LCA\)" , "uta@ietf.org" , Pete Resnick , Chris Evans , IETF WebSec WG , Barry Leiba , Ryan Sleevi Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 18:57:55 -0000 On Mon, Jan 20, 2014 at 7:44 AM, Daniel Kahn Gillmor wrote: > 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 (Note that Chrome does not remember your decision to Proceed Anyway, although we are working on that.) > 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". Perhaps "key pinning" vs. "exception pinning"? I wanted to call "exception pinning" "name pinning" at first, until I remembered DNS pinning (to defend against http://en.wikipedia.org/wiki/DNS_rebinding). So maybe we have 3 pinnings. :) It's worth noting that 2 of the 3 (key pinning and DNS pinning) refer to *reducing* the number of trusted entities. Anyway, I consistently refer to the behavior described in the key pinning draft as "key pinning", if that helps. (Probably not.) I can add an explanatory note to our draft, if that would help. From dkg@fifthhorseman.net Mon Jan 20 13:55:26 2014 Return-Path: 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 CEA541A0254; Mon, 20 Jan 2014 13:55:26 -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 R8ecgb2nmD1h; Mon, 20 Jan 2014 13:55:24 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF31A024B; Mon, 20 Jan 2014 13:55:23 -0800 (PST) Received: from [192.168.13.107] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 93311F984; Mon, 20 Jan 2014 16:55:20 -0500 (EST) Message-ID: <52DD9B46.2090803@fifthhorseman.net> Date: Mon, 20 Jan 2014 16:55:18 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Chris Palmer References: <0bc674da169f4772b0fb2173ed679115@BY2PR03MB300.namprd03.prod.outlook.com> <52DD0DC4.4010207@isode.com> <52DD4468.5010304@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IwGj5cNxbFjxRx92KLlRcSgtDJKQbsxiX" Cc: "Orit Levin \(LCA\)" , "uta@ietf.org" , Pete Resnick , Chris Evans , IETF WebSec WG , Barry Leiba , Ryan Sleevi Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 21:55:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IwGj5cNxbFjxRx92KLlRcSgtDJKQbsxiX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/20/2014 01:57 PM, Chris Palmer wrote: > On Mon, Jan 20, 2014 at 7:44 AM, Daniel Kahn Gillmor > wrote: >=20 >> 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" a= nd >> chrome calls "proceed anyway" -- where the user (or someone) overrides= >=20 > (Note that Chrome does not remember your decision to Proceed Anyway, > although we are working on that.) ah, that's good to know, thanks for the heads-up. >> 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= ". >=20 > Perhaps "key pinning" vs. "exception pinning"? I wanted to call > "exception pinning" "name pinning" at first, until I remembered DNS > pinning (to defend against > http://en.wikipedia.org/wiki/DNS_rebinding). So maybe we have 3 > pinnings. :) It's worth noting that 2 of the 3 (key pinning and DNS > pinning) refer to *reducing* the number of trusted entities. Hm, RFC 6125 pinning is also about certificates, not just public keys, so maybe it's "certificate exception pinning" -- but really it seems like a flavor of permissive TOFU (trust on first use) more than anything else. so we have: * DNS pinning: maintain DNS records in the browser (possibly past their TTL) to avoid DNS rebinding attacks. * key pinning: binds public keys to domain names (at the request of the origin server), forbids the use of certificates that do not include the pinned public keys somewhere in the cert chain. * certificate pinning: associate an otherwise non-valid End Entity (EE) certificate with a domain name (at the request of the user), permitting that certificate to be used with the domain name, but *without* forbidding any other certificate from use. > Anyway, I consistently refer to the behavior described in the key > pinning draft as "key pinning", if that helps. (Probably not.)=20 I think it's a start, at least. > I can add an explanatory note to our draft, if that would help. I think a clarifying note in draft-ietf-websec-key-pinning is necessary (i don't know that it is sufficient). it could be just something to indicate that the key pinning described in the draft has entirely distinct semantics and characteristics than "RFC 6125 certificate exception pinning". --dkg --IwGj5cNxbFjxRx92KLlRcSgtDJKQbsxiX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS3ZtGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpchEkQAJnOvgwA4oR6+Ss7fxUtsuR0 oouL2mMtcy5EBdnb/lmvbENbFkyNCxKTVmDCfdoO5Zf+ft5Fc9JlA/bjcuY/i+76 XBT7Dm6juZETMMjpKn5h8IoqCB/4lbxXzpK3VSu+AAPYKsPUjOkKpjrZTjoXcH1C QrFRD2DM1ryuPU6IDYm+dZZTpw9nBT5beQaNboMSF4n+0309DqIbiRHZbW7iYxMw H8b8gFE2b3Z0yhBnmqwCnlzdWThUTPFayvKYXEMl1xcMg/lHsDoOOiXdi2WZgv1A QBokPflCIAYRnk3s0GglRh8k8S9rn5qYe0coZXHH2WwZLxiuQlC/IcsOI6Ri2/+A jfUPPk81cucOJxtQKW5LMNpICV2n3ZoVNDNHJ7fgM9JbQbTXMWdgxHye6fnFIQ2Q nhiWFNQz5wTfnHDq1x7onCRa7PBrxMtTLmxLENq747rxxrbeWpIQuLIV6XIpGusE BxhfKdYRH0a5FfhBhWVE+fVe5SInccDLJz5bpPvlQeJxO4LOIEAxbLoolu/gvXeR 5T//toSClBDta018RfufOPOZSH+dz5BOCbqfSkRAQ1J7tqpC3axxgWrufdUoexJt IepZVIJSVCxpgZ7Aqld+HDgA0CK0aDx0hviZuB+pVmsLINaDVd9f823CXp9hwDi8 DmcUDmi7brgzycEN4GvU =jwSy -----END PGP SIGNATURE----- --IwGj5cNxbFjxRx92KLlRcSgtDJKQbsxiX--