From nobody Fri Oct 3 11:07:51 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 5F79F1A888E for ; Fri, 3 Oct 2014 11:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 CoiKdcc96cCo for ; Fri, 3 Oct 2014 11:07:46 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05F91A8887 for ; Fri, 3 Oct 2014 11:07:45 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so3305703igc.12 for ; Fri, 03 Oct 2014 11:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iOXrJp/i4Kw18QLXeFohH9ZRjGa3/nqQkYg4lbbQWaE=; b=HQ5SaVb/wNIpTkNCHUK7nUXgrf/EtKDlACfrAhHYuKAYOtKqyOEbB9imlH6PXhmY+2 OJQMUVX6XUMk6tnCqkVDMR5ujWmVoBWk5BygVn2cei5EgvvYREvG8JZf19Muy7IozcD0 Rp8fbcwA/Bgt5fOLIPCbxQ+Iu8QE2bnQiT9y5s3ws7K+o+gM4af9hsY80YUQqTAByvsK NNm0I0wRZvq5DbWMzfXDIgLoR/Eie/zsRRb5U5ofZqXxyi8S72C7krfIViPjCIuUmBU5 0qC2y73cv6YqcN0XfYfIkkimLQHYhqqpTKbWcCcIogY967Dw3Mtt4RMHEvcrC0KIThVD u8Ow== MIME-Version: 1.0 X-Received: by 10.50.117.65 with SMTP id kc1mr274224igb.34.1412359665119; Fri, 03 Oct 2014 11:07:45 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.153.66 with HTTP; Fri, 3 Oct 2014 11:07:45 -0700 (PDT) In-Reply-To: <7E8E7D4E-61D0-4C6B-B5CC-FFAE1BF80699@gmail.com> References: <7E8E7D4E-61D0-4C6B-B5CC-FFAE1BF80699@gmail.com> Date: Fri, 3 Oct 2014 14:07:45 -0400 X-Google-Sender-Auth: wy462nKPMsUHY5iVtwUg0NbDSiI Message-ID: From: Barry Leiba To: draft-ietf-websec-key-pinning.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/KzYz66iQjhvc3oPf7ZRNNh_mni4 Cc: IETF WebSec WG Subject: Re: [websec] DISCUSS positions on draft-ietf-websec-key-pinning 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: Fri, 03 Oct 2014 18:07:49 -0000 >>> How are we doing with this document? Any progress on dealing with the >>> DISCUSSes and other comments? It's now eight weeks since the telechat, and there has been no response of any kind to the comments from the ADs. The comments, and especially the DISCUSS positions, should have been discussed with the relevant ADs. Discussion and/or resolution has to happen in the next two weeks -- so, by 17 Oct. If it doesn't, I'm going to set the status of the document to "Dead", and close the working group without it. That would really be a shame, as it's almost done -- there's a few days' worth of work left and then it goes to the RFC Editor as a Proposed Standard. This seems sort of like running a marathon and being 200 metres short of the finish line... and then saying, well, 42 km is enough, let's just go to the pub now and leave it unfinished, no need to do the last .2. Please, let's not let this die. Authors, you're almost there. Eat some spinach, make like Popeye, and finish it. You have a deadline; please meet it. Barry, Applications AD From nobody Sun Oct 5 18:24:02 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 D23C81A0273; Sun, 5 Oct 2014 18:23:58 -0700 (PDT) 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 eShoN7yOy07O; Sun, 5 Oct 2014 18:23:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EE61A0275; Sun, 5 Oct 2014 18:23:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006012355.31175.78914.idtracker@ietfa.amsl.com> Date: Sun, 05 Oct 2014 18:23:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/xs6LccMNbOZIq7uDUIXDUY9EcTQ Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-21.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 01:23:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : Public Key Pinning Extension for HTTP Authors : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-21.txt Pages : 28 Date : 2014-10-05 Abstract: This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, UAs will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 5 18:24:04 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 E2E931A0273 for ; Sun, 5 Oct 2014 18:23:59 -0700 (PDT) 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 nSNBzynYiaH3; Sun, 5 Oct 2014 18:23:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1541A028A; Sun, 5 Oct 2014 18:23:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: websec-chairs@tools.ietf.org, draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org, barryleiba@computer.org, ted.lemon@nominum.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141006012355.31175.78117.idtracker@ietfa.amsl.com> Date: Sun, 05 Oct 2014 18:23:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/Xf5zieIflAXBz3B-xt8DPy3FArI Subject: [websec] New Version Notification - draft-ietf-websec-key-pinning-21.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 01:24:00 -0000 A new version (-21) has been submitted for draft-ietf-websec-key-pinning: http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-21.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Oct 6 08:08:41 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 170171A01D8 for ; Sun, 5 Oct 2014 17:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.249 X-Spam-Level: * X-Spam-Status: No, score=1.249 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 oVoE3klhEIez for ; Sun, 5 Oct 2014 17:57:54 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92991A0004 for ; Sun, 5 Oct 2014 17:57:54 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hq11so2467414vcb.7 for ; Sun, 05 Oct 2014 17:57:53 -0700 (PDT) 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=KmGX0sKy/lRyO8+Z5lXGqHXqHXKwhkbMDw1iqOh6VR8=; b=HubyrVxkN2s24xD6a1VWDYicAK6+MvJiXmBDyWmtrau/36kq6MlBN275CS3xmJzc09 qlwjlFj8JAQz2NL7Ss/iIAE7yAzzcMcasKtNB6IuLrIFtLmpadkkmsmivlp7F4ALFdBc ln7bEAa0TTJ5AOLRemJ/w6pv8TtGbTnxgR17H1GXjTQczDFk6KlTj5J2r2LiEKpP2Q7i MCGRMSwMvbH5dSugYbHiqXd+uLVw2H5Us61RYrFGak6NavTBFU6mhEcYra9FcYZXXQx4 PoZuErqx/zTGvT+gc9VgnY66Zl8tJ4NJLisPDIRAYjl5edydhEKOwXTe7PhD2DeaZiQ6 8vMw== 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=KmGX0sKy/lRyO8+Z5lXGqHXqHXKwhkbMDw1iqOh6VR8=; b=Y7e2VX8ALnGTVoczQCkpNXEA8QcZ2FJ8u5+IK62EuemBflOr23luDKKyR+P3z1xzW+ UbExAhvDgCjrg8rSqNYFUVQ20iCSBKDAFPIjBS8HNbpBAb3zgN1YwV4b87/YEFW6/MI3 jdrdfa0z6Fq4pgfMu7WEA9QJawYoN3IBHq2TdrzrC5bGFf35mif47LJGzcM/7SaIid+v HKMfxAP5EyOCOlUB3DQDITzixpiJkBKCXPxdwhNKFkFZnAlDP+hEeEBfxPYo+p+iBrBE 2SzSUqI2mYPdSUAEcTeOekgO8aHOxsEXWegtcOJ5pnCf373IcxS4wHd5DietGBpu8GK3 GiSw== X-Gm-Message-State: ALoCoQnpZUH5/d/ZVPcw+GaR3krEkVtg7fOuBAAhcHyzrK/NgHmCV/d+Qy9xAURhAI0bS0Vij0Zv MIME-Version: 1.0 X-Received: by 10.220.161.136 with SMTP id r8mr15542447vcx.21.1412557073674; Sun, 05 Oct 2014 17:57:53 -0700 (PDT) Received: by 10.52.14.42 with HTTP; Sun, 5 Oct 2014 17:57:53 -0700 (PDT) In-Reply-To: <54021B2F.7000108@dial.pipex.com> References: <53DA3F13.10007@dial.pipex.com> <549E489B-181F-48FA-867E-BA7C7FB3E32D@gmail.com> <53E8DC68.5010803@dial.pipex.com> <54021B2F.7000108@dial.pipex.com> Date: Sun, 5 Oct 2014 17:57:53 -0700 Message-ID: From: Ryan Sleevi To: Elwyn Davies Content-Type: multipart/alternative; boundary=001a11c214129a0cbb0504b69219 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/bNylOvuxyw0z876URqyRcEY2_Dw X-Mailman-Approved-At: Mon, 06 Oct 2014 08:08:38 -0700 Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, General area reviewing team , IETF WebSec WG Subject: Re: [websec] Gen-art LC review of draft-ietf-websec-key-pinning-19 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, 06 Oct 2014 00:57:57 -0000 --001a11c214129a0cbb0504b69219 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 30, 2014 at 11:42 AM, Elwyn Davies wrote: > Hi, Chris. > > A couple of remaining points and a couple of nits/queries in the fixes. > > I have deleted the items that we are agreed on below and added comments in > line. > > New nits: > s2.6, next to last para: s/previous/previously/ > > s4, lasta para: > >> and indeed MUST pin to issuers not in the chain >> > > Is this a requirements MUST? The protocol will be quite happy and > implementers can't (at least I don't think) they can check if the host > leaves it out. This is operational advice (admittedly highly relevant) but > still advice I think. > > On 25/08/14 21:23, Chris Palmer wrote: > >> On Mon, Aug 11, 2014 at 8:08 AM, Elwyn Davies >> wrote: >> >> <> > > Ok. Accepting that the host is expected normally to send the headers on >>> all >>> responses, when SHOULD it not send the headers? (from the previous >>> comments >>> a server that knows it is not multiplexed might be a candidate - or if it >>> knows it has already responded on this connection?) >>> >> >> I think it's easiest and simplest for servers to simply always send the >> headers. >> >> > Having thought about this a bit, I don't think this text fully reflects > what is going on in the server. If I understand correctly, we have: > - Server has a policy that it wants to be pinned if it can be (presumably > this ought to be configurable in the server). > - When a client sends a request over a new secure connection and the > policy says 'be pinned', the server sends back pinning header(s) in the > response. > - Thereafter, it MAY for simplicity send pinning headers in all subsequent > responses on the connection. Alternatively it can do something intelligent > and not bother sending the headers if it is the same connection - but of > course this probably means a layer violation. > > Thought: Does it make any difference if the client doesn't accept the pin? > Should success or failure be logged? Should the host always keep sending > the headers if the client didn't accept the pin on the first > exchange (is this a possible symptom of a MITM?)? > > Suggestion: > OLD: > 2.2.1. HTTP-over-Secure-Transport Request Type > > When replying to an HTTP request that was conveyed over a secure > transport, a Pinned Host SHOULD include in its response exactly one > PKP header field, exactly one PKP-RO header field, or one of each. > > NEW: > 2.2.1. HTTP-over-Secure-Transport Request Type > > If a host has a policy of becoming a Pinned Host whenever possible, > then on replying to an initial HTTP request that was conveyed over a > secure transport, a host intending to become Pinned Host includes in > its response exactly one PKP header field, exactly one PKP-RO header > field, or one of each. The host MAY include the same header(s) > with any subsequent responses using the same connection. > > > Just to cycle back on modifications, I've opted not to make this modification, as it violates the independence of HTTP Request/Responses. That is, each Request/Response over a given Connection is meant to be treated in isolation. The language proposed, while possible, also misses out on edge cases like HTTP pipelining (and figuring out when pinning takes effect) or the semantics of HTTP/2.0, which allows connection pooling ( https://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-9.1.1 ) > <> > > Also there may be some of the questions in s8.3.1 of RFC 7231 that need >>>>>> specific answers. >>>>>> >>>>> >>> There are still some of the questions that ought to be explicitly >>> answered. >>> >> >> To me, the only questions that might not have obvious answers are: >> >> o Whether the header field is useful or allowable in trailers (see >> Section 4.1 of [RFC7230]). >> >> Surely not? For the same reason we don't want it in meta http-equiv. >> > I'm ambivalent about this. I treat headers - leading or trailing - as part of the security boundary of a server. I'm not keen on violating any header semantics here. > >> o Whether the header field ought to be preserved across redirects. >> > I don't see any problem here, because it's a Response header, not a Request header. > >> Surely not? >> >> Any others? >> > > The point was that I guess you ought to explicitly say "not" in each case. > > >> <> > > Changes visible at >> https://code.google.com/p/key-pinning-draft/source/list. I won't push >> a version 21 until I've gone through the rest of the incoming email. >> >> Thank you! >> >> Cheers, > Elwyn > --001a11c214129a0cbb0504b69219 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 30, 2014 at 11:42 AM, Elwyn Davies <elwynd@dial.pipex.= com> wrote:
Hi, Chris.

A couple of remaining points and a couple of nits/queries in the fixes.

I have deleted the items that we are agreed on below and added comments in = line.

New nits:
s2.6, next to last para: s/previous/previously/

s4, lasta para:
and indeed MUST pin to issuers not in the chain

Is this a requirements MUST?=C2=A0 The protocol will be quite happy and imp= lementers can't (at least I don't think) they can check if the host= leaves it out.=C2=A0 This is operational advice (admittedly highly relevan= t) but still advice I think.

On 25/08/14 21:23, Chris Palmer wrote:
On Mon, Aug 11, 2014 at 8:08 AM, Elwyn Davies <elwynd@dial.pipex.com> wrote:

 <<snip>>

Ok.=C2=A0 Accepting that the host is expected normally to send the headers = on all
responses, when SHOULD it not send the headers? (from the previous comments=
a server that knows it is not multiplexed might be a candidate - or if it knows it has already responded on this connection?)

I think it's easiest and simplest for servers to simply always send the= headers.


 Having thought about this a bit, I don't think this text fully reflects= what is going on in the server.=C2=A0 If I understand correctly, we have:<= br> - Server has a policy that it wants to be pinned if it can be (presumably t= his ought to be configurable in the server).
- When a client sends a request over a new secure connection and the policy= says 'be pinned', the server sends back pinning header(s) in the r= esponse.
- Thereafter, it MAY for simplicity send pinning headers in all subsequent = responses on the connection. Alternatively it can do something intelligent = and not bother sending the headers if it is the same connection - but of co= urse this probably means a layer violation.

Thought: Does it make any difference if the client doesn't accept the p= in? Should success or failure be logged?=C2=A0 Should the host always keep = sending the headers if the client didn't accept the pin on the first exchange (is this a possible symptom of a MITM?)?

Suggestion:
OLD:
2.2.1.=C2=A0 HTTP-over-Secure-Transport Request Type

=C2=A0 =C2=A0When replying to an HTTP request that was conveyed over a secu= re
=C2=A0 =C2=A0transport, a Pinned Host SHOULD include in its response exactl= y one
=C2=A0 =C2=A0PKP header field, exactly one PKP-RO header field, or one of e= ach.

NEW:
2.2.1.=C2=A0 HTTP-over-Secure-Transport Request Type

=C2=A0 =C2=A0If a host has a policy of becoming a Pinned Host whenever poss= ible,
=C2=A0 =C2=A0then on replying to an initial HTTP request that was conveyed = over a
=C2=A0 =C2=A0secure transport, a host intending to become Pinned Host inclu= des in
=C2=A0 =C2=A0its response exactly one PKP header field, exactly one PKP-RO = header
=C2=A0 =C2=A0field, or one of each.=C2=A0 The host MAY include the same hea= der(s)
=C2=A0 =C2=A0with any subsequent responses using the same connection.



Just to cycle back on modifications, I= 've opted not to make this modification, as it violates the independenc= e of HTTP Request/Responses. That is, each Request/Response over a given Co= nnection is meant to be treated in isolation.

The = language proposed, while possible, also misses out on edge cases like HTTP = pipelining (and figuring out when pinning takes effect) or the semantics of= HTTP/2.0, which allows connection pooling (=C2=A0https://tools.ietf= .org/html/draft-ietf-httpbis-http2-14#section-9.1.1 )
=C2=A0<= /div>
<<snip>>

Also there may be some of the questions in s8.3.1 of RFC 7231 that need
specific answers.

There are still some of the questions that ought to be explicitly answered.=

To me, the only questions that might not have obvious answers are:

=C2=A0 =C2=A0 o=C2=A0 Whether the header field is useful or allowable in tr= ailers (see
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 4.1 of [RFC7230]).

Surely not? For the same reason we don't want it in meta http-equiv.

I'm ambivalent ab= out this. I treat headers - leading or trailing - as part of the security b= oundary of a server. I'm not keen on violating any header semantics her= e.
=C2=A0

=C2=A0 =C2=A0 o=C2=A0 Whether the header field ought to be preserved across= redirects.

I don&#= 39;t see any problem here, because it's a Response header, not a Reques= t header.
=C2=A0

Surely not?

Any others?

The point was that I guess you ought to explicitly say "not" in e= ach case.


<<snip>>

Changes visible at
https://code.google.com/p/key-pinning-draft/source/list<= /a>. I won't push
a version 21 until I've gone through the rest of the incoming email.
Thank you!

 Cheers,
Elwyn

--001a11c214129a0cbb0504b69219-- From nobody Wed Oct 8 08:02:20 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 126631A1BE5; Wed, 8 Oct 2014 08:02:13 -0700 (PDT) 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 LHkpwQPVOwNP; Wed, 8 Oct 2014 08:02:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A14191A1BE4; Wed, 8 Oct 2014 08:02:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141008150209.2897.72243.idtracker@ietfa.amsl.com> Date: Wed, 08 Oct 2014 08:02:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/mzJF0PIfa4zKRaDDivXM85d5Z-A Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Ted Lemon's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:02:13 -0000 Ted Lemon has entered the following ballot position for draft-ietf-websec-key-pinning-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I've cleared my DISCUSS. For the record, here it is, but there is no further action required: This mechanism relies on there being no MiTM attack from a compromised signing key either prior to a legitimate pinning, or in a situation where the host being "protected" doesn't actually do pinning. I think this should be mentioned in the security considerations section. I raise this to the level of DISCUSS because I think this actually creates a new attack surface for government censorship: you MiTM the host you're attacking, pin it to a cert signed using a compromised CA, and then that UA can't communicate with the host again for the duration of the pin. The scenario would be that the government has a transparent web cache in the path between the host and the UA, and the web cache pins false cert for hosts that are being censored. Now even if the user sets up a tunnel to bypass the transparent cache, they can't access the censored site, so they conclude that the site is down and abandon the tunnel. I could easily see this being used in a scenario like the recent DNS censorship in Turkey. Setting a lower maximum pin age mitigates the damage of such attacks if the user keeps the tunnel up for the duration of the pin, but I don't think it's realistic to assume that they will. I think that the only way to mitigate this attack is to have a mechanism whereby conflicting DANE TLSA information overrides the pin. This would allow a site being attacked in this way to securely inform the UA that the pin was invalid. The government could of course prevent DNSSEC validation, but the UA could take this as another signal to drop the pin: if the zone where the TLSA record should be fails to validate (as opposed to isn't signed, which wouldn't signify anything), the pin is likely a censorship attempt. From nobody Wed Oct 8 08:02:52 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 606611A1BF0; Wed, 8 Oct 2014 08:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 p4kJmr-HcJTt; Wed, 8 Oct 2014 08:02:37 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784171A1BDE; Wed, 8 Oct 2014 08:02:30 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6291E1B81BF; Wed, 8 Oct 2014 08:02:30 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 59CD953E072; Wed, 8 Oct 2014 08:02:30 -0700 (PDT) Received: from [10.0.1.10] (8.20.190.66) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Oct 2014 08:02:30 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <7E8E7D4E-61D0-4C6B-B5CC-FFAE1BF80699@gmail.com> Date: Wed, 8 Oct 2014 11:02:27 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <5BFFCA6A-F1FC-4A9D-82B2-CC5405C050BE@nominum.com> References: <7E8E7D4E-61D0-4C6B-B5CC-FFAE1BF80699@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [8.20.190.66] Archived-At: http://mailarchive.ietf.org/arch/msg/websec/JB6E8zqAgNZesrRTRnySAyzxRws Cc: draft-ietf-websec-key-pinning.all@tools.ietf.org, Barry Leiba , IETF WebSec WG , IESG Subject: Re: [websec] DISCUSS positions on draft-ietf-websec-key-pinning 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: Wed, 08 Oct 2014 15:02:48 -0000 On Sep 18, 2014, at 12:12 AM, Yoav Nir wrote: > I have heard from them. They said that they will finish the revision = this week or on the weekend. That'll do. I've cleared. Thanks! From nobody Wed Oct 8 08:55:36 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 09AE61A0301; Wed, 8 Oct 2014 08:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 qS4Aluc09LcT; Wed, 8 Oct 2014 08:55:29 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A537F1A6F85; Wed, 8 Oct 2014 08:55:28 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id q1so8709279lam.22 for ; Wed, 08 Oct 2014 08:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ecdotodtbNhTSf9TngVOjLxR9XU/3YVhDmMRFgjkopU=; b=RfYZrEst8MDQGEaMg9dY+nfUfBgsXftTX9OejT68TKaQdnkAMjZzfSrM+1jJJXvmUG HxBe0VfJevWX9jzITq/eGNjcugFWbnB/y6Zr+xQv65W2+qEOKMpVTcDCXPKtsPkeAYXs lyXHfvYB8kClZxgvlHop2hR7tvgXPXtDv8uKTPZQsVG5ERZKo7i9HQgCh8vYUzZiaoVU A2IJZv7N1lARpNbDK99/iaU1jS1UCCpNqK5HFL/dKRikeZL8eChBB4b5lwdVRrsb+g09 dOzbThXSY9BleIvgBsLrwPYUlqaFTizK9hEvQKJzBW/jjunA/oKQ532LH2WUK3qeGNA7 OqfA== MIME-Version: 1.0 X-Received: by 10.152.197.35 with SMTP id ir3mr12681974lac.82.1412783726279; Wed, 08 Oct 2014 08:55:26 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 8 Oct 2014 08:55:26 -0700 (PDT) In-Reply-To: References: <20140807031550.1175.40039.idtracker@ietfa.amsl.com> Date: Wed, 8 Oct 2014 11:55:26 -0400 X-Google-Sender-Auth: xDUhcsOB5lUKcZznvHfGiKRzAIY Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/xIgzQ5-dEAJeyqqrCkPWdmcHr-0 Cc: "websec-chairs@tools.ietf.org" , draft-ietf-websec-key-pinning@tools.ietf.org, "" , Ryan Sleevi , The IESG Subject: Re: [websec] Kathleen Moriarty's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT) 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: Wed, 08 Oct 2014 15:55:32 -0000 Hi, Kathleen. Can you retrieve context and see if version -21 resolves your issues (and restart the discussion if not)? Thanks. Barry On Mon, Aug 25, 2014 at 11:18 AM, Kathleen Moriarty wrote: > Helo Ryan, > > Thank you for your response. Please keep in mind that in most cases, I am > trying to help you clear up the language and ensure that the security and > privacy concerns are clearly understood in the draft to readers that might > include security professionals, CSIRT teams, security administration staff, > and others. I do think the draft is good and would like to help progress > it, but do think some language fixes would be beneficial. > > I read the draft again and will try to clarify the points below providing > suggested language where possible. > > > On Mon, Aug 25, 2014 at 1:44 AM, Ryan Sleevi wrote: >> >> >> >> >> On Wed, Aug 6, 2014 at 8:15 PM, Kathleen Moriarty >> wrote: >>> >>> Kathleen Moriarty has entered the following ballot position for >>> draft-ietf-websec-key-pinning-19: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> Overall the draft is very good, thank you for writing it. I just wanted >>> to discuss some of the security/privacy considerations and see if we >>> could improve the language and make sure the set of concerns are clear. >>> >>> The privacy consideration section reads more like possible attack >>> scenarios that would fit into the security considerations. What privacy >>> related concerns result from these attacks? Having that spelled out to >>> differentiate the risks as privacy only would be helpful (if appropriate) >>> or moving this into the security consideration section *IF* it is more >>> generically applicable. If I am missing something and this is only >>> privacy related, it would be good to understand that in this discussion. >>> Adding some text on how these attacks could be used to expose privacy >>> related information would be helpful too. >> >> >> The first paragraph spells out precisely why this is listed as a privacy >> consideration: >> >> Hosts can use HSTS or HPKP as a "super-cookie", by setting distinct >> policies for a number of subdomains. For example, assume example.com >> wishes to track distinct UAs without explicitly setting a cookie, or >> if a previously-set cookie is deleted from the UA's cookie store. >> >> Neither of these attacks undermine the protections afforded by HPKP. >> Indeed, they exist precisely BECAUSE of HPKP offering a new means of web >> storage. Essentially, all storage mechanisms introduced when dealing with >> sites - whether it be cookies, new APIs like IndexedDB, exposure of >> persistent storage such as cryptographic keys, or, as in both HSTS and HPKP, >> remembering data about a previously visited site - represent new and >> potential ways to uniquely identify a user, which the two examples spell >> out. >> >>> >>> >>> For the first example, it seems it is the possibility that a report goes >>> outside out the intended scope is the concern. The mitigation seems to >>> be provided in the last sentence of #4, but couldn't this be other >>> information leakage and not just privacy? Let me know if I am missing >>> something that explains why this is privacy specific. >> >> >> I'm not sure how that was reached, as the description of the risk was >> explicitly enumerated >> >> and the ability to pin arbitrary identifiers to distinguish UAs. >> >> This is also reiterated in the #2 and #3. >> >> The same applies to the second example, which hopefully the above >> explanation is sufficient to demonstrate how the spec already highlights, in >> several means, how this is a privacy issue (distinguishing the user >> independent of cookies, aka a "super-cookie") > > > In reading the draft again, the language issue for me was with the usage of > "report" in the text. After looking at this draft again, it seems the only > report type discussed is a "pin validation failure report", in reading up on > other uses of report-uri (W3C) it seems to be tied to a header, in this case > PKP-RO response header. The term report is pretty generic on it's own and > this is where my confusion came in, since that wasn't explicitly stated > (these are tied together and it's the only report discussed). When you get > to the privacy section, it just lists the term report on it's own and not as > a specific report. There is no mention of the report type in that section, > and yes, I probably should have realized that it was tied to the response > header. I do see that is the only report discussed in the draft, but was > not well-versed in this area, so it wasn't clear to me on first read. That > may be fine for most readers, but it wouldn't hurt to state the use of the > term 'report' in this draft is specific to "pin validation failure report" > in section 2.1.3 or to mention the report type again in the privacy section. > My discuss comments above were all related to the generic term "report". > I'll let it go if you feel strongly that this is not necessary since I was > able to figure it out on a second read. >> >> >>> >>> >>> In #3 of the second example, the last sentence includes the following >>> clause: >>> and giving some UAs no >>> Valid Pinning Header for other subdomains (causing subsequent >>> requests for m.fingerprint.example.com to succeed). >>> >>> Does this mean that these subdomains are succeeding when they should >>> fail? It might just be me, but that is not clear in the text (or if they >>> are supposed to succeed). It sounds like they are not supposed to >>> succeed and this is the security issue. How is this privacy specific? >>> Again, this may just be me, but an explanation would be helpful. >> >> >> Do the above references to the existing portions of the spec make this >> clearer? > > > In this case, I'd like to see clearer language that describes the issue and > includes why it is an issue. I am okay on the privacy specific questions as > that was because of the generic use of the term "report" and I was able to > figure out that was the cause of my concerns from my first read of the > draft. Bullet #3 is a run-on sentence and both fixing that and including > implications would go a long way. Here is the current bullet: > > 3. example.com can distinguish 2^N UAs by serving Valid Pinning > Headers from an arbitrary number N distinct subdomains, giving > some UAs Valid Pinning Headers for some, but not all > subdomains (causing subsequent requests for > n.fingerprint.example.com to fail), and giving some UAs no > Valid Pinning Header for other subdomains (causing subsequent > requests for m.fingerprint.example.com to succeed). > > > Here is a suggestion, please teak the language if I didn't get this quite > right: > > > 3. example.com can distinguish 2^N UAs by serving Valid Pinning > Headers from an arbitrary number N distinct subdomains. > > Assume in this example, Valid Pinning headers are assigned > > for subdomains n.fingerprint.example.com and the includeSubDomain > > directive was intended to cover all subdomains > > m.fingerprint.example.com. Where Valid Pinning Headers were > > assigned, some were given to UAs but not for all subdomains > causing > > subsequent requests for n.fingerprint.example.com to > fail. Valid Pinning Header are > > not given to some UAs for other subdomains, causing > subsequent > > requests for m.fingerprint.example.com to succeed. >> >> >> As noted above, the attack is about identifying and tracking users through >> means other than cookies. Such attacks are also known as "super-cookies", >> which is the term explicitly used in the introduction of these attacks. >> >> As noted, the attacker is the site serving the headers itself, which is >> why it's a privacy issue. > > Thanks. >> >> >>> >>> >>> In the last sentence of the privacy considerations section, what is meant >>> by the description "forensic attacker"? I find this term confusing. Was >>> this intended to mean that techniques used in forensic analysis could be >>> used by an attacker to discern information that could be of interest? If >>> that's the case, I think it would be clearer to the reader if that were >>> stated instead. >> >> >> This was in response to Alissa Cooper's YES vote, in which a threat model >> of an attacker with physical access to the machine attempts to recover state >> of the user's browsing history, which the UA had otherwise cleared. > > > Sure, I have no problem with the point, but would like to see the commonly > used terms for this attack type to avoid confusion for the reader. The term > "forensic attacker" isn't one used in the incident response space, so if you > could replace that term with what I think is the intended meaning, "forensic > analysis techniques could be used by an attacker to discern this information > that could be of interest (or useful)", would help. We don't usually cover > attack types that require full exploit of the system or physical access, so > if this got dropped, that would be fine too. The use of such tools isn't > limited to physical access, but also is possible once the host is > compromised and such tools can be installed and used by an attacker (much > higher likelihood than a physical access attack). The current text does not > make a distinction and that is good, I don't think you should be getting too > deep here anyway. > > Propose change from: > > A forensic attacker might > find this information useful, even if the user has cleared other > parts of the UA's state. > > > To: > > Forensic analysis techniques could be used by an attacker to discern > this information and > > may find it useful, even if the user has cleared other > parts of the UA's state. > > >> >> Per Eric Lawrence's feedback, this third section will be reworked into >> it's own privacy consideration bullet, and hopefully you'll find the >> clarification suitable. >> > > Thanks for you work on this section. >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I agree with Richard's comment that the document is well written and an >>> important document, thank you for writing it. The style changed a little >>> toward the end and I had some trouble with long sentences in the security >>> & privacy considerations sections. This should be easy enough to fix and >>> may be done with the RFC editor anyway. >>> >>> To Richard's point on operational concerns versus security concerns, are >>> there explicit security attacks that could occur with the max-age >>> variations described? >>> >>> In 4.2, I can't see this being more than an operational concern since it >>> fails when overlapping pin sets are not used. Are we missing a gap that >>> leads to a security concern? >> >> >> I suppose it depends on your threat model and how you view domain >> authority. >> >> In the example given, subdomain.example.com is bypassing the pins set for >> example.com+includeSubDomains, depending on timing. That is, if example.com >> is visited first, then subdomain.example.com MUST be equal-to-or-a-subset-of >> the pins for example.com, by virtue of the known pinned host evaluation. >> >> Thus if example.com wishes to administer pins for their domain (and all >> subdomains), it's necessary for them to prevent subdomains from setting the >> header. >> >> Now, you can see this as an operational concern if you view the >> example.com and subdomain.example.com as the same administrative entity, but >> that's sometimes not the case (e.g. shared hosting sites like Amazon AWS, >> GitHub's pages, or Google AppEngine) > > > Thanks for the explanation, it would be helpful to have something along > those lines in the draft This is a non-blocking comment, so ignore if you so > choose, but here is a suggestion to clarify this as a security concern (in > addition to an operational one). Perhaps if you explicitly stated that a > denial of service could result from this configuration issue, that would > help. Also stating the concern is heightened in a service provider > environment or one where a single domain is used across administratively > distinct applications, recommending that the includeSubDomain directive > should not be used in such circumstances to avoid this issue. >> >> >> >>> >>> >>> 4.3 makes sense to me as a security concern that drives operational >>> practices. >>> >>> >> > Thanks! > > > -- > > Best regards, > Kathleen From nobody Wed Oct 8 08:56:30 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 C8E311A0301; Wed, 8 Oct 2014 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 iVUJ2-ctsugo; Wed, 8 Oct 2014 08:56:14 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD30D1A1BA4; Wed, 8 Oct 2014 08:56:13 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so8818935lam.18 for ; Wed, 08 Oct 2014 08:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xQwonGaogqXx4CQe6JuLDBN91zAJr1zuvTeqfxsSBoM=; b=Loy/+QcCISTdOrs1NmrW34XBqI+6KHqx5m6a7nEY5Z7MlDlZsa89QaBV4rxTexmtNN 908YIoOaf3SH/BZhvNZF8o88H1GIDyQpMlrKygIYCDt1kDVkD0Pu3UB1IpvnCzp9PUDr zXhM/AJwHJKszGbklW+9bDe1iww/HXJoqHIQXlZ9vnP0jMibPG7bTNfhQebswVmUUSd3 bCDbQQLGCQPP+YLotKL0T6FQnImBa9e6pRx75Di2WyOqPy+3TB6gQ92MzQAcCmlko9lo +MVAic6Jr9N9fy06TjyaTXmLwqxZte5wktwVlacFPCePD0HETpWasdFkcY8QiVfPSJPu yi2Q== MIME-Version: 1.0 X-Received: by 10.112.54.130 with SMTP id j2mr11667917lbp.41.1412783772001; Wed, 08 Oct 2014 08:56:12 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 8 Oct 2014 08:56:11 -0700 (PDT) In-Reply-To: <53FB0AB1.1090109@cs.tcd.ie> References: <20140807110710.18212.14741.idtracker@ietfa.amsl.com> <53FB0AB1.1090109@cs.tcd.ie> Date: Wed, 8 Oct 2014 11:56:11 -0400 X-Google-Sender-Auth: AJPuVc_9tvHpJOSIL_R6LWYOupA Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/XAEzEXmKU84VukRpb6luCqFQeIY Cc: "websec-chairs@tools.ietf.org" , draft-ietf-websec-key-pinning@tools.ietf.org, "" , Ryan Sleevi , The IESG Subject: Re: [websec] Stephen Farrell's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT) 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: Wed, 08 Oct 2014 15:56:17 -0000 Hi, Stephen. Can you retrieve context and see if version -21 resolves your issues (and restart the discussion if not)? Thanks. Barry On Mon, Aug 25, 2014 at 6:06 AM, Stephen Farrell wrote: > > Hi Ryan, > > Thanks for the thorough response. A few bis'n'pieces below but > I'll clear once you've posted the update, so no need to keep on > chatting if you prefer that. (I'm happy to keep chatting too of > course.) > > On 25/08/14 06:51, Ryan Sleevi wrote: >> On Thu, Aug 7, 2014 at 4:07 AM, Stephen Farrell >> wrote: >> >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-websec-key-pinning-19: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> >>> Good doc. Two things I'd like to check before moving to a yes >>> ballot: >>> >>> (1) 2.1 - Can a simple-directive start with "pin-"? Seems like >>> yes it can, but then the ABNF is ambiguous about the RHS of the >>> "=" I think, is that right? Its no big deal since valid values >>> will parse anyway, so only an issue if you ever care about >>> simple-directive vs. pin-directive. Ah - does the last para of >>> 2.1 mean that this distinction is needed really? >>> >> >>>From the ABNF, yes, it does many any simple-directive can start with "pin-". >> >> I suspect the solution is to remove pin-directive entirely from the ABNF, >> as it's not necessary, and purely specify in terms of directives. The >> concept of a "pin-directive" can be explained via prose, which would be >> consistent to how HTTPbis restructured most of the header processing. >> > > Grand. That'll fix it. > >> >>> >>> (2) 2.1.3 says that "If the scheme in the report-uri is one >>> that uses TLS (e.g. HTTPS), UAs MUST perform Pinning >>> Validation when the host in the report-uri is a Known Pinned >>> Host;" That's generally ok, however, I think it may break for >>> alt-svc, where TLS is used but https is not, or if TCPINC >>> decided on a TLS based solution then some coder might get it >>> wrong. I think a simple re-statement in terms of http vs. https >>> URIs should fix this. I realise that neither alt-svc nor TCPINC >>> existed when this work started, but since they now do it'd pay >>> to think about them and I don't recall seeing that on the >>> websec list (apologies if I'm wrong there). The IFF in 2.5 >>> also seems related. 2.2 has same issues about alt-svc and >>> TCPINC. I do see that you only say "e.g. TLS" here but >>> wonder nonetheless, e.g. would 2.2.1 cover an alt-svc case >>> or not? >>> >> >> The suggested solution - being explicit that it applies to HTTPS - equally >> suffers from the risk of error being seen for alt-svc, in that it fails to >> account for schemes such as wss://, for which pinning also should apply. > > Fair enough. > >> >> I realize this is probably something you may not agree with, but I think >> the language choice here - that of "secure transport" - is already >> sufficient to exclude such proposals as alt-svc, which only provide >> encryption. That is, both in practice and intent, alt-svc is not considered >> to be a "secure transport" (which is as much evident by the lack of secure >> cookies) >> >> For example, with respect to 2.5, the second bullet point describes the >> connection as "authenticated", which alt-svc is not. > > You're right that I do think some more clarity would be good. Isn't > the fact that we both think coders are likely to make mistakes here > a good indicator of that? > > I'd suggest adding something like: > > Note that only server-authenticated TLS or mutually-authenticated > TLS are considered "secure transports" for the purposes of this > specification. In particular, any form of unauthenticated TLS such > as use of *ANON* ciphersuites or opportunistic security for HTTP > URIs (as in [1]) do not count as "secure transports". > > [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption > > I'm sure that's probably broken and needs fixing but some explicit > text would be good. (Nonetheless, since we've discussed it, I will > move to a Yes even if you don't add stuff for this.) > >> >> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> >>> abstract and elswhere: SubjectPublicKeyInfo doesn't usually >>> have spaces between the terms. No big deal. After the abstract >>> would a ref to 5280 be right for SPKI as well? >>> >> >> Sure. >> >> >>> >>> general: I think emphasising the backup pin requirement in the >>> intro would be good. It's a little hidden now and would be a >>> surprise to some I bet. >>> >>> 2.1 - pin-directive has the literal "pin-" but later you say >>> (in bullet #3) that directive names are case insensitive. Does >>> that apply to "pin-" as well or not? >>> >> >> It should. The above proposed removal of the ABNF for pin-directive should >> remedy this. >> >> >>> >>> 2.1 - has some typos: reistry and hahs >>> >>> 2.1 - "Known Pinned Host" would be a fine term to define in a >>> section 1.1 that was renamed via s/Requirements >>> Language/Terminology/ >>> >>> 2.1.1 - max-age is really defined against the time of reception >>> and not (in principle) from when its emitted? I know that >>> makes no difference now, but with a sufficient latency (e.g. >>> Earth->Mars, min 4 mins, max 20 mins, and yes my DTN heritage >>> is showing:-) it could, just about. I think to be pedantically >>> correct, max-age ought be defined versus the time of emission >>> and not receipt. >>> >> >> I don't see how this reasonably can be accomplished, short of requiring >> that the Date header ( http://tools.ietf.org/html/rfc7231#section-7.1.1.2 ) >> be present, which does not seem desirable. > > No, I don't think such a change would be needed. You only need > to re-define max-age as an offset from the time of reception. > For the current web that's close enough to the time of emission > that all's well. It'd only make a difference for a DTN-like web. > But, that last of course means that almost nobody cares, so I'll > stop now:-) > > Cheers, > S. > > >> >> >>> >>> 2.1.2 - uses the term "Pinned Host" which is not the same as >>> the previously used "Known Pinned Host" - is the distinction >>> meant to be significant or is that a typo? >>> >> >> Typo, although the difference is significant enough to provide >> clarification, in as much as it applies to PKP-RO (which doesn't note the >> pins, as discussed elsewhere) >> >> >>> >>> 2.1.3/section 4 - shouldn't the potential DoS issues be >>> discussed for cases where report-uri != same-origin? E.g. if >>> busy-site.example.net (is hacked and) sets report-uri to >>> victim.example.com (maybe with some HTML/JS that generates >>> loads of queries to the victimj) that'd be like getting /.'d I >>> think that's maybe worth noting in the security considerations >>> or in 2.1.3 where you (quite properly) say to rate-limit >>> reporting. If you'd rather not say why though, that's ok too. >>> >>> >> Sure. >> > From nobody Wed Oct 8 10:43:10 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 605231ACD62 for ; Wed, 8 Oct 2014 10:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 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.786, SPF_PASS=-0.001] 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 ydwX9rN36x9n for ; Wed, 8 Oct 2014 10:43:08 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59771ACD55 for ; Wed, 8 Oct 2014 10:43:07 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id g201so8330136oib.7 for ; Wed, 08 Oct 2014 10:43:07 -0700 (PDT) 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=oU9JUUFRBy4c6cyDs5fkvVj8+/7Gx6SVknZAONvjl6Y=; b=KCqwqnlRr61iFa+w+a1YX13hA2AQDsAmFWTskpTAXFIbBQQW4QRQFGNfFLHG3yJ4t4 2LSfgCd05UgVaY2+4Z2PJ2zsBJw8Std3yY5WNgm81alwrtkXas6IpsROJhNjzNZ3r/3x HWFjr9h1bFyx27rRS1wPYc0B51IoPOsYd6LvrKDwhJcuspv/TXWMaAheQgB5Z59l7YP7 CCAGjieMnW09kL9aIjJC1ZqkXEKWVQGraq8hT0QZvjjtHpjhxo/3PdI2a2ZRJeRb2Ppb o42bYQrOyTBVSXB3kAc3JjvEB29uHHGZQrWMyfwOsJDmL9tPUoAX2S4A03Cv2cF7pz1k 51fw== 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=oU9JUUFRBy4c6cyDs5fkvVj8+/7Gx6SVknZAONvjl6Y=; b=ipIq2KG6W0N6uEApaZUZQh59vSzJlGjbfRJeiEULT6Wg40mIkV+Tk+3gicTGp176Od CzO0nQI1JbGikPl3Y0CYObDbRpN34z1HYS2hVTUH4Kcmpo31Z9fc1j/yHu0l9j8NTBxn xhZ7uB9R7HpeIVRnCiXdFuqCVtklq3mGo7boggVCfT9H6covGmaqDugAyMbPd3dM4Y7Y EQ+oaqB6EQ5X4aCngE9KPHyT+h1BFnDcOdo3S5Atcvs718OTqxzixWSnlzzxUcXi8old fmFJP7l/w/DQcH7dpDqC90rlNtYhQnyEcOVZW66FtFc7At5wK/et7t7mV9AOmqt0JpMA Bgbw== X-Gm-Message-State: ALoCoQm0S0lj3JeuqLn7goXhvUWHx+Oe0+Y6GgWRRZ7vlM0jXF8EI7OFaWXQPvWbt7HU3ZB/EBWG MIME-Version: 1.0 X-Received: by 10.182.33.99 with SMTP id q3mr14440612obi.28.1412790187196; Wed, 08 Oct 2014 10:43:07 -0700 (PDT) Received: by 10.182.55.68 with HTTP; Wed, 8 Oct 2014 10:43:07 -0700 (PDT) In-Reply-To: <20141008150209.2897.72243.idtracker@ietfa.amsl.com> References: <20141008150209.2897.72243.idtracker@ietfa.amsl.com> Date: Wed, 8 Oct 2014 10:43:07 -0700 Message-ID: From: Chris Palmer To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/9SzpB1pNxb4-AkW82qlA4ijg3ao Cc: "draft-ietf-websec-key-pinning@tools.ietf.org" , IETF WebSec WG , The IESG , websec-chairs@tools.ietf.org Subject: Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT) 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: Wed, 08 Oct 2014 17:43:09 -0000 On Wed, Oct 8, 2014 at 8:02 AM, Ted Lemon wrote: > This mechanism relies on there being no MiTM attack from a compromised > signing key either prior to a legitimate pinning, or in a situation where > the host being "protected" doesn't actually do pinning. I think this > should be mentioned in the security considerations section. I raise > this to the level of DISCUSS because I think this actually creates a new > attack surface for government censorship: you MiTM the host you're > attacking, pin it to a cert signed using a compromised CA, and then that > UA can't communicate with the host again for the duration of the pin. > > The scenario would be that the government has a transparent web cache in > the path between the host and the UA, and the web cache pins false cert > for hosts that are being censored. Now even if the user sets up a > tunnel to bypass the transparent cache, they can't access the censored > site, so they conclude that the site is down and abandon the tunnel. I > could easily see this being used in a scenario like the recent DNS > censorship in Turkey. > > Setting a lower maximum pin age mitigates the damage of such attacks if > the user keeps the tunnel up for the duration of the pin, but I don't > think it's realistic to assume that they will. I think that the only > way to mitigate this attack is to have a mechanism whereby conflicting > DANE TLSA information overrides the pin. This would allow a site being > attacked in this way to securely inform the UA that the pin was invalid. > The government could of course prevent DNSSEC validation, but the UA > could take this as another signal to drop the pin: if the zone where the > TLSA record should be fails to validate (as opposed to isn't signed, > which wouldn't signify anything), the pin is likely a censorship attempt. http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-4.5 From nobody Thu Oct 9 05:42:40 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 737761ACE43; Thu, 9 Oct 2014 05:42:38 -0700 (PDT) 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 nxT20_vDx6WG; Thu, 9 Oct 2014 05:42:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEFE1ACE25; Thu, 9 Oct 2014 05:42:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141009124236.9721.74949.idtracker@ietfa.amsl.com> Date: Thu, 09 Oct 2014 05:42:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/oOPT3e4j56AI7HaWq8jJ9UJm2FQ Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Stephen Farrell's Yes on draft-ietf-websec-key-pinning-21: (with COMMENT) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 12:42:38 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-websec-key-pinning-21: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for clearing up my discuss points. One possible remaining nit though: - In 2.2 you say: "(1) the processing rules for HTTP request messages received over a secure transport (e.g. authenticated, non-anonymous TLS); " Should the "e.g." be an "i.e." ? It's probably fine either way but just wondered. -- OLD comments below, didn't check 'em abstract and elswhere: SubjectPublicKeyInfo doesn't usually have spaces between the terms. No big deal. After the abstract would a ref to 5280 be right for SPKI as well? general: I think emphasising the backup pin requirement in the intro would be good. It's a little hidden now and would be a surprise to some I bet. 2.1 - pin-directive has the literal "pin-" but later you say (in bullet #3) that directive names are case insensitive. Does that apply to "pin-" as well or not? 2.1 - has some typos: reistry and hahs 2.1 - "Known Pinned Host" would be a fine term to define in a section 1.1 that was renamed via s/Requirements Language/Terminology/ 2.1.1 - max-age is really defined against the time of reception and not (in principle) from when its emitted? I know that makes no difference now, but with a sufficient latency (e.g. Earth->Mars, min 4 mins, max 20 mins, and yes my DTN heritage is showing:-) it could, just about. I think to be pedantically correct, max-age ought be defined versus the time of emission and not receipt. 2.1.2 - uses the term "Pinned Host" which is not the same as the previously used "Known Pinned Host" - is the distinction meant to be significant or is that a typo? 2.1.3/section 4 - shouldn't the potential DoS issues be discussed for cases where report-uri != same-origin? E.g. if busy-site.example.net (is hacked and) sets report-uri to victim.example.com (maybe with some HTML/JS that generates loads of queries to the victimj) that'd be like getting /.'d I think that's maybe worth noting in the security considerations or in 2.1.3 where you (quite properly) say to rate-limit reporting. If you'd rather not say why though, that's ok too. From nobody Thu Oct 9 06:00:33 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 E0D381ACF70; Thu, 9 Oct 2014 06:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 YkuqTDaF6qCo; Thu, 9 Oct 2014 06:00:27 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113CF1ACE90; Thu, 9 Oct 2014 05:58:14 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so1068873lbd.6 for ; Thu, 09 Oct 2014 05:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=M/xI478+i8fDd/nUvT0vnorvdJMMlAV1ph8PtFO2OyI=; b=ecL/J+Guievr4zrP84LhSWu2vJeIrv7Y94jiQDPiZaiza2LiYcgx8FDFzv83bW3Gwj 7pps1Z6QeMFRSXFuw+oZnFD/5itq3AM0nN9qPxeh8qonDDRSGcu5smBz2mYLrGJJ6zk8 ubBWwfVpznYBm8A9ziLIFWUTip8YWZJXr23yP6I6icISH4UKNGtKnl4ihQgR4EjWkVBt 4lwd29WonS+w/dMqmg0kDoc7Ssad1mdiv84fYtYavQGBLAtOuS+Zcok7wfaomDVVsYVq d1XrcdVy2WJtCYCSarkDx+gmQyC5m8O42UMqpkzLh6va/CWElRR6KdGURxxEMlpfclAq lAVA== MIME-Version: 1.0 X-Received: by 10.152.36.67 with SMTP id o3mr18654074laj.45.1412859493404; Thu, 09 Oct 2014 05:58:13 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Thu, 9 Oct 2014 05:58:13 -0700 (PDT) In-Reply-To: <20141009124236.9721.74949.idtracker@ietfa.amsl.com> References: <20141009124236.9721.74949.idtracker@ietfa.amsl.com> Date: Thu, 9 Oct 2014 08:58:13 -0400 X-Google-Sender-Auth: JSHNeKY7aViXgsM3jru5cA9y8jA Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0158b78e38d73a0504fcfc95 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/ZE4B24cWVarcCPWe5VAiZEXoEe8 Cc: "draft-ietf-websec-key-pinning@tools.ietf.org" , "websec@ietf.org" , The IESG , "websec-chairs@tools.ietf.org" Subject: Re: [websec] Stephen Farrell's Yes on draft-ietf-websec-key-pinning-21: (with COMMENT) 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: Thu, 09 Oct 2014 13:00:28 -0000 --089e0158b78e38d73a0504fcfc95 Content-Type: text/plain; charset=ISO-8859-1 Just on the new point: - In 2.2 you say: "(1) the processing rules for HTTP > request messages received over a secure transport (e.g. > authenticated, non-anonymous TLS); " > > Should the "e.g." be an "i.e." ? It's probably fine either > way but just wondered. > It seems to me that "for example" is right, allowing for other possible secure transports (perhaps IPSec, perhaps something that comes later). The concept is that it needs to be secured, and the example is apt. Barry --089e0158b78e38d73a0504fcfc95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just on the new point:

- In 2.2 you s= ay: "(1) the processing rules for HTTP
=A0 =A0request messages received over a secure transport (e.g.
=A0 =A0authenticated, non-anonymous TLS); "

Should the "e.g." be an "i.e." ? It's probably fine= either
way but just wondered.

It seems to me that "for example"= ; is right, allowing for other possible secure transports (perhaps IPSec, p= erhaps something that comes later).=A0 The concept is that it needs to be s= ecured, and the example is apt.

Barry=A0
--089e0158b78e38d73a0504fcfc95-- From nobody Sat Oct 11 12:10:24 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 9D7B01A8738; Sat, 11 Oct 2014 12:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] 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 ILrzjPuapMCB; Sat, 11 Oct 2014 12:10:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B61F1A8735; Sat, 11 Oct 2014 12:10:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141011191020.12832.57445.idtracker@ietfa.amsl.com> Date: Sat, 11 Oct 2014 12:10:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/T0h7GLCUUOWS_KaV8A6JaimwmrA Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org Subject: [websec] Kathleen Moriarty's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 19:10:21 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-websec-key-pinning-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the adjustments to address my concerns/questions. From nobody Sat Oct 11 12:12:05 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 AD7041A8738; Sat, 11 Oct 2014 12:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 r5Xpz9YUZqrC; Sat, 11 Oct 2014 12:11:53 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB6F1A8736; Sat, 11 Oct 2014 12:11:52 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so4641905lbv.7 for ; Sat, 11 Oct 2014 12:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O2X/OoHWa8lSyuxC0ALg8rg6WJX05QRfU1EQxOFP2V8=; b=D+WnA2nHvlGyThJsf4UFabQsfiOj5p6OvfeWxZyIUQ8kEe2rVmwqXzLColCE9qMAEx p+bn9dMj3FVgMpVar6jpsgFF4GvIaKM8v4kR/KMila2hrbqZbQFLCU30M1xGpMXwBzvY L6Hat5pzW1v+7xqFEYJmwxrtjyVo56dX/nZ36gf//WG2+GTAs2XQRhfmDwsDDRD1pdJn 4GoGQBATi1okaND+d4BruSFPkXolbRwvvkDtvWXVYubyyRch+/e6G9/iE5/caNOqPhr7 9wRwmuQahzLeeMVSxIQuT6WvIcWQUQj9B3BUIskrVYVvJbWhjU2EzwnsWbCLCV2wEM2s /jsw== MIME-Version: 1.0 X-Received: by 10.152.9.2 with SMTP id v2mr13434429laa.36.1413054711111; Sat, 11 Oct 2014 12:11:51 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Sat, 11 Oct 2014 12:11:50 -0700 (PDT) In-Reply-To: References: <20140807031550.1175.40039.idtracker@ietfa.amsl.com> Date: Sat, 11 Oct 2014 15:11:50 -0400 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=089e0158b8ee1aa60505052a705e Archived-At: http://mailarchive.ietf.org/arch/msg/websec/JqcbHoBf2XajOfLdfQTtAxMdVH8 Cc: "websec-chairs@tools.ietf.org" , draft-ietf-websec-key-pinning@tools.ietf.org, "" , Ryan Sleevi , The IESG Subject: Re: [websec] Kathleen Moriarty's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT) 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: Sat, 11 Oct 2014 19:11:57 -0000 --089e0158b8ee1aa60505052a705e Content-Type: text/plain; charset=UTF-8 Hi Barry, Thanks for the updated draft and sorry for the delay. I was working at a conference and just got back. On Wed, Oct 8, 2014 at 11:55 AM, Barry Leiba wrote: > Hi, Kathleen. Can you retrieve context and see if version -21 > resolves your issues (and restart the discussion if not)? Thanks. > > Barry > > On Mon, Aug 25, 2014 at 11:18 AM, Kathleen Moriarty > wrote: > > Helo Ryan, > > > > Thank you for your response. Please keep in mind that in most cases, I > am > > trying to help you clear up the language and ensure that the security and > > privacy concerns are clearly understood in the draft to readers that > might > > include security professionals, CSIRT teams, security administration > staff, > > and others. I do think the draft is good and would like to help progress > > it, but do think some language fixes would be beneficial. > > > > I read the draft again and will try to clarify the points below providing > > suggested language where possible. > > > > > > On Mon, Aug 25, 2014 at 1:44 AM, Ryan Sleevi wrote: > >> > >> > >> > >> > >> On Wed, Aug 6, 2014 at 8:15 PM, Kathleen Moriarty > >> wrote: > >>> > >>> Kathleen Moriarty has entered the following ballot position for > >>> draft-ietf-websec-key-pinning-19: Discuss > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > >>> http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> Overall the draft is very good, thank you for writing it. I just > wanted > >>> to discuss some of the security/privacy considerations and see if we > >>> could improve the language and make sure the set of concerns are clear. > >>> > >>> The privacy consideration section reads more like possible attack > >>> scenarios that would fit into the security considerations. What > privacy > >>> related concerns result from these attacks? Having that spelled out to > >>> differentiate the risks as privacy only would be helpful (if > appropriate) > >>> or moving this into the security consideration section *IF* it is more > >>> generically applicable. If I am missing something and this is only > >>> privacy related, it would be good to understand that in this > discussion. > >>> Adding some text on how these attacks could be used to expose privacy > >>> related information would be helpful too. > >> > >> > >> The first paragraph spells out precisely why this is listed as a privacy > >> consideration: > >> > >> Hosts can use HSTS or HPKP as a "super-cookie", by setting distinct > >> policies for a number of subdomains. For example, assume > example.com > >> wishes to track distinct UAs without explicitly setting a cookie, or > >> if a previously-set cookie is deleted from the UA's cookie store. > >> > >> Neither of these attacks undermine the protections afforded by HPKP. > >> Indeed, they exist precisely BECAUSE of HPKP offering a new means of web > >> storage. Essentially, all storage mechanisms introduced when dealing > with > >> sites - whether it be cookies, new APIs like IndexedDB, exposure of > >> persistent storage such as cryptographic keys, or, as in both HSTS and > HPKP, > >> remembering data about a previously visited site - represent new and > >> potential ways to uniquely identify a user, which the two examples spell > >> out. > >> > >>> > >>> > >>> For the first example, it seems it is the possibility that a report > goes > >>> outside out the intended scope is the concern. The mitigation seems to > >>> be provided in the last sentence of #4, but couldn't this be other > >>> information leakage and not just privacy? Let me know if I am missing > >>> something that explains why this is privacy specific. > >> > >> > >> I'm not sure how that was reached, as the description of the risk was > >> explicitly enumerated > >> > >> and the ability to pin arbitrary identifiers to distinguish UAs. > >> > >> This is also reiterated in the #2 and #3. > >> > >> The same applies to the second example, which hopefully the above > >> explanation is sufficient to demonstrate how the spec already > highlights, in > >> several means, how this is a privacy issue (distinguishing the user > >> independent of cookies, aka a "super-cookie") > > > > > > In reading the draft again, the language issue for me was with the usage > of > > "report" in the text. After looking at this draft again, it seems the > only > > report type discussed is a "pin validation failure report", in reading > up on > > other uses of report-uri (W3C) it seems to be tied to a header, in this > case > > PKP-RO response header. The term report is pretty generic on it's own > and > > this is where my confusion came in, since that wasn't explicitly stated > > (these are tied together and it's the only report discussed). When you > get > > to the privacy section, it just lists the term report on it's own and > not as > > a specific report. There is no mention of the report type in that > section, > > and yes, I probably should have realized that it was tied to the response > > header. I do see that is the only report discussed in the draft, but was > > not well-versed in this area, so it wasn't clear to me on first read. > That > > may be fine for most readers, but it wouldn't hurt to state the use of > the > > term 'report' in this draft is specific to "pin validation failure > report" > > in section 2.1.3 or to mention the report type again in the privacy > section. > > My discuss comments above were all related to the generic term "report". > > I'll let it go if you feel strongly that this is not necessary since I > was > > able to figure it out on a second read. > >> > >> > >>> > >>> > >>> In #3 of the second example, the last sentence includes the following > >>> clause: > >>> and giving some UAs no > >>> Valid Pinning Header for other subdomains (causing subsequent > >>> requests for m.fingerprint.example.com to succeed). > >>> > >>> Does this mean that these subdomains are succeeding when they should > >>> fail? It might just be me, but that is not clear in the text (or if > they > >>> are supposed to succeed). It sounds like they are not supposed to > >>> succeed and this is the security issue. How is this privacy specific? > >>> Again, this may just be me, but an explanation would be helpful. > >> > >> > >> Do the above references to the existing portions of the spec make this > >> clearer? > > > > > > In this case, I'd like to see clearer language that describes the issue > and > > includes why it is an issue. I am okay on the privacy specific > questions as > > that was because of the generic use of the term "report" and I was able > to > > figure out that was the cause of my concerns from my first read of the > > draft. Bullet #3 is a run-on sentence and both fixing that and including > > implications would go a long way. Here is the current bullet: > > > > 3. example.com can distinguish 2^N UAs by serving Valid Pinning > > Headers from an arbitrary number N distinct subdomains, giving > > some UAs Valid Pinning Headers for some, but not all > > subdomains (causing subsequent requests for > > n.fingerprint.example.com to fail), and giving some UAs no > > Valid Pinning Header for other subdomains (causing subsequent > > requests for m.fingerprint.example.com to succeed). > > > > > > Here is a suggestion, please teak the language if I didn't get this quite > > right: > > > > > > 3. example.com can distinguish 2^N UAs by serving Valid Pinning > > Headers from an arbitrary number N distinct subdomains. > > > > Assume in this example, Valid Pinning headers are assigned > > > > for subdomains n.fingerprint.example.com and the > includeSubDomain > > > > directive was intended to cover all subdomains > > > > m.fingerprint.example.com. Where Valid Pinning Headers were > > > > assigned, some were given to UAs but not for all subdomains > > causing > > > > subsequent requests for n.fingerprint.example.com to > > fail. Valid Pinning Header are > > > > not given to some UAs for other subdomains, causing > > subsequent > > > > requests for m.fingerprint.example.com to succeed. > >> > >> > >> As noted above, the attack is about identifying and tracking users > through > >> means other than cookies. Such attacks are also known as > "super-cookies", > >> which is the term explicitly used in the introduction of these attacks. > >> > >> As noted, the attacker is the site serving the headers itself, which is > >> why it's a privacy issue. > > > > Thanks. > >> > >> > >>> > >>> > >>> In the last sentence of the privacy considerations section, what is > meant > >>> by the description "forensic attacker"? I find this term confusing. > Was > >>> this intended to mean that techniques used in forensic analysis could > be > >>> used by an attacker to discern information that could be of interest? > If > >>> that's the case, I think it would be clearer to the reader if that were > >>> stated instead. > >> > >> > >> This was in response to Alissa Cooper's YES vote, in which a threat > model > >> of an attacker with physical access to the machine attempts to recover > state > >> of the user's browsing history, which the UA had otherwise cleared. > > > > > > Sure, I have no problem with the point, but would like to see the > commonly > > used terms for this attack type to avoid confusion for the reader. The > term > > "forensic attacker" isn't one used in the incident response space, so if > you > > could replace that term with what I think is the intended meaning, > "forensic > > analysis techniques could be used by an attacker to discern this > information > > that could be of interest (or useful)", would help. We don't usually > cover > > attack types that require full exploit of the system or physical access, > so > > if this got dropped, that would be fine too. The use of such tools isn't > > limited to physical access, but also is possible once the host is > > compromised and such tools can be installed and used by an attacker (much > > higher likelihood than a physical access attack). The current text does > not > > make a distinction and that is good, I don't think you should be getting > too > > deep here anyway. > > > > Propose change from: > > > > A forensic attacker might > > find this information useful, even if the user has cleared other > > parts of the UA's state. > > > > > > To: > > > > Forensic analysis techniques could be used by an attacker to discern > > this information and > > > > may find it useful, even if the user has cleared other > > parts of the UA's state. > > > > > >> > >> Per Eric Lawrence's feedback, this third section will be reworked into > >> it's own privacy consideration bullet, and hopefully you'll find the > >> clarification suitable. > >> > > > > Thanks for you work on this section. > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> I agree with Richard's comment that the document is well written and an > >>> important document, thank you for writing it. The style changed a > little > >>> toward the end and I had some trouble with long sentences in the > security > >>> & privacy considerations sections. This should be easy enough to fix > and > >>> may be done with the RFC editor anyway. > >>> > >>> To Richard's point on operational concerns versus security concerns, > are > >>> there explicit security attacks that could occur with the max-age > >>> variations described? > >>> > >>> In 4.2, I can't see this being more than an operational concern since > it > >>> fails when overlapping pin sets are not used. Are we missing a gap > that > >>> leads to a security concern? > >> > >> > >> I suppose it depends on your threat model and how you view domain > >> authority. > >> > >> In the example given, subdomain.example.com is bypassing the pins set > for > >> example.com+includeSubDomains, depending on timing. That is, if > example.com > >> is visited first, then subdomain.example.com MUST be > equal-to-or-a-subset-of > >> the pins for example.com, by virtue of the known pinned host > evaluation. > >> > >> Thus if example.com wishes to administer pins for their domain (and all > >> subdomains), it's necessary for them to prevent subdomains from setting > the > >> header. > >> > >> Now, you can see this as an operational concern if you view the > >> example.com and subdomain.example.com as the same administrative > entity, but > >> that's sometimes not the case (e.g. shared hosting sites like Amazon > AWS, > >> GitHub's pages, or Google AppEngine) > > > > > > Thanks for the explanation, it would be helpful to have something along > > those lines in the draft This is a non-blocking comment, so ignore if > you so > > choose, but here is a suggestion to clarify this as a security concern > (in > > addition to an operational one). Perhaps if you explicitly stated that a > > denial of service could result from this configuration issue, that would > > help. Also stating the concern is heightened in a service provider > > environment or one where a single domain is used across administratively > > distinct applications, recommending that the includeSubDomain directive > > should not be used in such circumstances to avoid this issue. > >> > >> > >> > >>> > >>> > >>> 4.3 makes sense to me as a security concern that drives operational > >>> practices. > >>> > >>> > >> > > Thanks! > > > > > > -- > > > > Best regards, > > Kathleen > -- Best regards, Kathleen --089e0158b8ee1aa60505052a705e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Barry,

Thanks for the updated draft = and sorry for the delay.=C2=A0 I was working at a conference and just got b= ack.

O= n Wed, Oct 8, 2014 at 11:55 AM, Barry Leiba <barryleiba@computer.o= rg> wrote:
Hi, Kathleen.=C2= =A0 Can you retrieve context and see if version -21
resolves your issues (and restart the discussion if not)?=C2=A0 Thanks.

Barry

On Mon, Aug 25, 2014 at 11:18 AM, Kathleen Moriarty
<kathleen.moriarty.i= etf@gmail.com> wrote:
> Helo Ryan,
>
> Thank you for your response.=C2=A0 Please keep in mind that in most ca= ses, I am
> trying to help you clear up the language and ensure that the security = and
> privacy concerns are clearly understood in the draft to readers that m= ight
> include security professionals, CSIRT teams, security administration s= taff,
> and others.=C2=A0 I do think the draft is good and would like to help = progress
> it, but do think some language fixes would be beneficial.
>
> I read the draft again and will try to clarify the points below provid= ing
> suggested language where possible.
>
>
> On Mon, Aug 25, 2014 at 1:44 AM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>
>>
>>
>> On Wed, Aug 6, 2014 at 8:15 PM, Kathleen Moriarty
>> <Kathleen.M= oriarty.ietf@gmail.com> wrote:
>>>
>>> Kathleen Moriarty has entered the following ballot position fo= r
>>> draft-ietf-websec-key-pinning-19: Discuss
>>>
>>> When responding, please keep the subject line intact and reply= to all
>>> email addresses included in the To and CC lines. (Feel free to= cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to http://www.ietf.org/iesg/statement= /discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.=
>>>
>>>
>>> The document, along with other ballot positions, can be found = here:
>>> http://datatracker.ietf.org/doc/draft-ietf-w= ebsec-key-pinning/
>>>
>>>
>>>
>>> --------------------------------------------------------------= --------
>>> DISCUSS:
>>> --------------------------------------------------------------= --------
>>>
>>> Overall the draft is very good, thank you for writing it.=C2= =A0 I just wanted
>>> to discuss some of the security/privacy considerations and see= if we
>>> could improve the language and make sure the set of concerns a= re clear.
>>>
>>> The privacy consideration section reads more like possible att= ack
>>> scenarios that would fit into the security considerations.=C2= =A0 What privacy
>>> related concerns result from these attacks?=C2=A0 Having that = spelled out to
>>> differentiate the risks as privacy only would be helpful (if a= ppropriate)
>>> or moving this into the security consideration section *IF* it= is more
>>> generically applicable.=C2=A0 If I am missing something and th= is is only
>>> privacy related, it would be good to understand that in this d= iscussion.
>>>=C2=A0 Adding some text on how these attacks could be used to e= xpose privacy
>>> related information would be helpful too.
>>
>>
>> The first paragraph spells out precisely why this is listed as a p= rivacy
>> consideration:
>>
>>=C2=A0 =C2=A0 Hosts can use HSTS or HPKP as a "super-cookie&qu= ot;, by setting distinct
>>=C2=A0 =C2=A0 policies for a number of subdomains.=C2=A0 For exampl= e, assume example.com<= br> >>=C2=A0 =C2=A0 wishes to track distinct UAs without explicitly setti= ng a cookie, or
>>=C2=A0 =C2=A0 if a previously-set cookie is deleted from the UA'= ;s cookie store.
>>
>> Neither of these attacks undermine the protections afforded by HPK= P.
>> Indeed, they exist precisely BECAUSE of HPKP offering a new means = of web
>> storage. Essentially, all storage mechanisms introduced when deali= ng with
>> sites - whether it be cookies, new APIs like IndexedDB, exposure o= f
>> persistent storage such as cryptographic keys, or, as in both HSTS= and HPKP,
>> remembering data about a previously visited site - represent new a= nd
>> potential ways to uniquely identify a user, which the two examples= spell
>> out.
>>
>>>
>>>
>>> For the first example, it seems it is the possibility that a r= eport goes
>>> outside out the intended scope is the concern.=C2=A0 The mitig= ation seems to
>>> be provided in the last sentence of #4, but couldn't this = be other
>>> information leakage and not just privacy?=C2=A0 Let me know if= I am missing
>>> something that explains why this is privacy specific.
>>
>>
>> I'm not sure how that was reached, as the description of the r= isk was
>> explicitly enumerated
>>
>>=C2=A0 =C2=A0 and the ability to pin arbitrary identifiers to disti= nguish UAs.
>>
>> This is also reiterated in the #2 and #3.
>>
>> The same applies to the second example, which hopefully the above<= br> >> explanation is sufficient to demonstrate how the spec already high= lights, in
>> several means, how this is a privacy issue (distinguishing the use= r
>> independent of cookies, aka a "super-cookie")
>
>
> In reading the draft again, the language issue for me was with the usa= ge of
> "report" in the text.=C2=A0 After looking at this draft agai= n, it seems the only
> report type discussed is a "pin validation failure report", = in reading up on
> other uses of report-uri (W3C) it seems to be tied to a header, in thi= s case
> PKP-RO response header.=C2=A0 The term report is pretty generic on it&= #39;s own and
> this is where my confusion came in, since that wasn't explicitly s= tated
> (these are tied together and it's the only report discussed).=C2= =A0 When you get
> to the privacy section, it just lists the term report on it's own = and not as
> a specific report.=C2=A0 There is no mention of the report type in tha= t section,
> and yes, I probably should have realized that it was tied to the respo= nse
> header.=C2=A0 I do see that is the only report discussed in the draft,= but was
> not well-versed in this area, so it wasn't clear to me on first re= ad.=C2=A0 That
> may be fine for most readers, but it wouldn't hurt to state the us= e of the
> term 'report' in this draft is specific to "pin validatio= n failure report"
> in section 2.1.3 or to mention the report type again in the privacy se= ction.
> My discuss comments above were all related to the generic term "r= eport".
> I'll let it go if you feel strongly that this is not necessary sin= ce I was
> able to figure it out on a second read.
>>
>>
>>>
>>>
>>> In #3 of the second example, the last sentence includes the fo= llowing
>>> clause:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and giving some UAs no=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Valid Pinning Header f= or other subdomains (causing subsequent
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requests for m.fingerprint.examp= le.com to succeed).
>>>
>>> Does this mean that these subdomains are succeeding when they = should
>>> fail?=C2=A0 It might just be me, but that is not clear in the = text (or if they
>>> are supposed to succeed).=C2=A0 It sounds like they are not su= pposed to
>>> succeed and this is the security issue.=C2=A0 How is this priv= acy specific?
>>> Again, this may just be me, but an explanation would be helpfu= l.
>>
>>
>> Do the above references to the existing portions of the spec make = this
>> clearer?
>
>
> In this case, I'd like to see clearer language that describes the = issue and
> includes why it is an issue.=C2=A0 I am okay on the privacy specific q= uestions as
> that was because of the generic use of the term "report" and= I was able to
> figure out that was the cause of my concerns from my first read of the=
> draft. Bullet #3 is a run-on sentence and both fixing that and includi= ng
> implications would go a long way.=C2=A0 Here is the current bullet: >
>=C2=A0 =C2=A0 =C2=A0 =C2=A03.=C2=A0 example.com can distinguish 2^N UAs by serving Valid Pinn= ing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Headers from an arbitrary numb= er N distinct subdomains, giving
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some UAs Valid Pinning Headers= for some, but not all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subdomains (causing subsequent= requests for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n.fingerprint.example.com to fail), an= d giving some UAs no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Valid Pinning Header for other= subdomains (causing subsequent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requests for m.fingerprint.example.com= to succeed).
>
>
> Here is a suggestion, please teak the language if I didn't get thi= s quite
> right:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A03.=C2=A0 example.com can distinguish 2^N UAs by serving Valid Pinn= ing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Headers from an arbitrary numb= er N distinct subdomains.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Assume in this example, Valid = Pinning headers are assigned
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for subdomains n.fingerprint.example.com and the includeSubDomain
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0directive was intended to cove= r all subdomains
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m.fingerprint.example.com. Where Valid= Pinning Headers were
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assigned, some were given to U= As but not for all subdomains
> causing
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0subsequent requests for n.fingerprint.example.com to
> fail.=C2=A0 Valid Pinning Header are
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0not given to some UAs for other subdomains, causing
> subsequent
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requests for m.fingerprint.example.com= to succeed.
>>
>>
>> As noted above, the attack is about identifying and tracking users= through
>> means other than cookies. Such attacks are also known as "sup= er-cookies",
>> which is the term explicitly used in the introduction of these att= acks.
>>
>> As noted, the attacker is the site serving the headers itself, whi= ch is
>> why it's a privacy issue.
>
> Thanks.
>>
>>
>>>
>>>
>>> In the last sentence of the privacy considerations section, wh= at is meant
>>> by the description "forensic attacker"?=C2=A0 I find= this term confusing.=C2=A0 Was
>>> this intended to mean that techniques used in forensic analysi= s could be
>>> used by an attacker to discern information that could be of in= terest?=C2=A0 If
>>> that's the case, I think it would be clearer to the reader= if that were
>>> stated instead.
>>
>>
>> This was in response to Alissa Cooper's YES vote, in which a t= hreat model
>> of an attacker with physical access to the machine attempts to rec= over state
>> of the user's browsing history, which the UA had otherwise cle= ared.
>
>
> Sure, I have no problem with the point, but would like to see the comm= only
> used terms for this attack type to avoid confusion for the reader.=C2= =A0 The term
> "forensic attacker" isn't one used in the incident respo= nse space, so if you
> could replace that term with what I think is the intended meaning, &qu= ot;forensic
> analysis techniques could be used by an attacker to discern this infor= mation
> that could be of interest (or useful)", would help.=C2=A0 We don&= #39;t usually cover
> attack types that require full exploit of the system or physical acces= s, so
> if this got dropped, that would be fine too.=C2=A0 The use of such too= ls isn't
> limited to physical access, but also is possible once the host is
> compromised and such tools can be installed and used by an attacker (m= uch
> higher likelihood than a physical access attack).=C2=A0 The current te= xt does not
> make a distinction and that is good, I don't think you should be g= etting too
> deep here anyway.
>
> Propose change from:
>
>=C2=A0 =C2=A0 A forensic attacker might
>=C2=A0 =C2=A0 find this information useful, even if the user has cleare= d other
>=C2=A0 =C2=A0 parts of the UA's state.
>
>
> To:
>
>=C2=A0 =C2=A0 =C2=A0 Forensic analysis techniques could be used by an a= ttacker to discern
> this information and
>
>=C2=A0 =C2=A0 =C2=A0 may find it useful, even if the user has cleared o= ther
>=C2=A0 =C2=A0 parts of the UA's state.
>
>
>>
>> Per Eric Lawrence's feedback, this third section will be rewor= ked into
>> it's own privacy consideration bullet, and hopefully you'l= l find the
>> clarification suitable.
>>
>
> Thanks for you work on this section.
>>>
>>>
>>>
>>> --------------------------------------------------------------= --------
>>> COMMENT:
>>> --------------------------------------------------------------= --------
>>>
>>> I agree with Richard's comment that the document is well w= ritten and an
>>> important document, thank you for writing it.=C2=A0 The style = changed a little
>>> toward the end and I had some trouble with long sentences in t= he security
>>> & privacy considerations sections.=C2=A0 This should be ea= sy enough to fix and
>>> may be done with the RFC editor anyway.
>>>
>>> To Richard's point on operational concerns versus security= concerns, are
>>> there explicit security attacks that could occur with the max-= age
>>> variations described?
>>>
>>> In 4.2, I can't see this being more than an operational co= ncern since it
>>> fails when overlapping pin sets are not used.=C2=A0 Are we mis= sing a gap that
>>> leads to a security concern?
>>
>>
>> I suppose it depends on your threat model and how you view domain<= br> >> authority.
>>
>> In the example given, subdomain.example.com is bypassing the pins set for
>> example.com+i= ncludeSubDomains, depending on timing. That is, if example.com
>> is visited first, then subdomain.example.com MUST be equal-to-or-a-subset-of >> the pins for exam= ple.com, by virtue of the known pinned host evaluation.
>>
>> Thus if example.c= om wishes to administer pins for their domain (and all
>> subdomains), it's necessary for them to prevent subdomains fro= m setting the
>> header.
>>
>> Now, you can see this as an operational concern if you view the >> example.com a= nd subdomain.exa= mple.com as the same administrative entity, but
>> that's sometimes not the case (e.g. shared hosting sites like = Amazon AWS,
>> GitHub's pages, or Google AppEngine)
>
>
> Thanks for the explanation, it would be helpful to have something alon= g
> those lines in the draft This is a non-blocking comment, so ignore if = you so
> choose, but here is a suggestion to clarify this as a security concern= (in
> addition to an operational one).=C2=A0 Perhaps if you explicitly state= d that a
> denial of service could result from this configuration issue, that wou= ld
> help.=C2=A0 Also stating the concern is heightened in a service provid= er
> environment or one where a single domain is used across administrative= ly
> distinct applications, recommending that the includeSubDomain directiv= e
> should not be used in such circumstances to avoid this issue.
>>
>>
>>
>>>
>>>
>>> 4.3 makes sense to me as a security concern that drives operat= ional
>>> practices.
>>>
>>>
>>
> Thanks!
>
>
> --
>
> Best regards,
> Kathleen



--
=

Best regards,
Kathleen
--089e0158b8ee1aa60505052a705e-- From nobody Sat Oct 11 13:04:03 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 1D9641A8789 for ; Sat, 11 Oct 2014 13:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 sSPaA3uX5HjG for ; Sat, 11 Oct 2014 13:03:58 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A941A877D for ; Sat, 11 Oct 2014 13:03:58 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id r2so6473814igi.11 for ; Sat, 11 Oct 2014 13:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w3Vgb6aOHsFSkzPvKsMRxDMJV+scIWNq8Ds7PRWxyaM=; b=lauEoDiCjEoCT0Y9cdioPzB+ji/re1GG+Det+t7IFlMGFxB3w+ZexDo24uI59pev/r ltG0used2UPdC4dYRmv94/g6R/w95HomEbDORElrHwnK5y9cSrYExjYZaFKRrVlevVk9 6I+lq5laq6OxJfmFhhSqLPYK+zFxLo3T59ZXgmuowRAYWyIx22Pb9owVKJNuAq6OFyE0 910/y+wGYCUP4UUHkIr0eEFOOp9ZPKpq0emh5iE07bwn/9S2mGsaXFnokuz82V84CwFg sezv1OTmjpSEKu1n0TTQTe4/aBgy88ujyNYrwwh35ShdOD817KZMx99fGYgPaltwaWTZ g0oQ== MIME-Version: 1.0 X-Received: by 10.50.143.73 with SMTP id sc9mr17420612igb.29.1413057837767; Sat, 11 Oct 2014 13:03:57 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.163.3 with HTTP; Sat, 11 Oct 2014 13:03:57 -0700 (PDT) In-Reply-To: References: <7E8E7D4E-61D0-4C6B-B5CC-FFAE1BF80699@gmail.com> Date: Sat, 11 Oct 2014 16:03:57 -0400 X-Google-Sender-Auth: -g8Qf4b63GbsTXoTSegt6nMhUzU Message-ID: From: Barry Leiba To: "draft-ietf-websec-key-pinning.all@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a1134cb0e77a3d005052b2a12 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/3jhWYi-1eV5QO4xNzH6C1MnDrAY Cc: IETF WebSec WG Subject: Re: [websec] DISCUSS positions on draft-ietf-websec-key-pinning 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: Sat, 11 Oct 2014 20:04:00 -0000 --001a1134cb0e77a3d005052b2a12 Content-Type: text/plain; charset=UTF-8 Ryan, thanks for getting the last of the changes done, and all the DISCUSSes cleared. I've sent the approval note to the IESG Secretary, and we should see the announcement on Monday. The document will now go into the RFC Editor queue, and you'll hear from them and have to respond when they do the final edits, in AUTH48 state. Everyone, thanks for the work on this. The working group will officially remain open until the RFC is published, after which I'll close it, but will leave the mailing list open for any continued discussion. Barry, Applications AD --001a1134cb0e77a3d005052b2a12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ryan, thanks for getting the last of the changes done, and all the DISCUSSe= s cleared.=C2=A0 I've sent the approval note to the IESG Secretary, and= we should see the announcement on Monday.

The document = will now go into the RFC Editor queue, and you'll hear from them and ha= ve to respond when they do the final edits, in AUTH48 state.

=
Everyone, thanks for the work on this.=C2=A0 The working group w= ill officially remain open until the RFC is published, after which I'll= close it, but will leave the mailing list open for any continued discussio= n.

Barry, Applications AD
--001a1134cb0e77a3d005052b2a12-- From nobody Sun Oct 12 14:40:19 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 5D9DC1A8786 for ; Sat, 11 Oct 2014 12:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] 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 N353GZPBr-nV; Sat, 11 Oct 2014 12:52:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9CA1A878C; Sat, 11 Oct 2014 12:52:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: websec-chairs@tools.ietf.org, draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141011195239.25560.38503.idtracker@ietfa.amsl.com> Date: Sat, 11 Oct 2014 12:52:39 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/websec/nmwYoO9QeUHzfdWfAE6z5L9f7FM X-Mailman-Approved-At: Sun, 12 Oct 2014 14:40:18 -0700 Subject: [websec] ID Tracker State Update Notice: X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2014 19:52:42 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ From nobody Mon Oct 13 08:13:18 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 654021A0349; Mon, 13 Oct 2014 08:13:14 -0700 (PDT) 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 e3Uv_J3khdsn; Mon, 13 Oct 2014 08:13:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 298F31A035C; Mon, 13 Oct 2014 08:13:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013151302.18153.31235.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 08:13:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/-pDJjSjbR8k_vmw_HWeb5HXarU8 Cc: websec mailing list , websec chair , RFC Editor Subject: [websec] Protocol Action: 'Public Key Pinning Extension for HTTP' to Proposed Standard (draft-ietf-websec-key-pinning-21.txt) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:13:15 -0000 The IESG has approved the following document: - 'Public Key Pinning Extension for HTTP' (draft-ietf-websec-key-pinning-21.txt) as Proposed Standard This document is the product of the Web Security Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ Technical Summary This spec describes an extension to the HTTP protocol allowing web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. Review and Consensus Previous versions of this document received useful reviews on the mailing list. Many changes were introduced due to working group consensus, including to pin format, an includeSubdomains directive, and interaction with private trust anchors. Some changes were proposed and rejected by the working group, most notably named pins, a "strict" directive, and hard limits on the max-age directive. The consensus on these involved a long and hard discussion, but as chairs, Tobias and I believe that it is a regular rather than rough consensus. Two issues that were left for last were the interaction of pre-loaded pins with noted pins, and the processing of report-only pins. There was a lot of controversy and a lot of back-and-forth about these issues. We believe that the current drafts represents the working group's consensus, although at least one participant would have preferred a different outcome. Personnel Yoav Nir is the document shepherd. Barry Leiba is the responsible Area Director. From nobody Mon Oct 13 13:02:28 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 944111A000C for ; Mon, 13 Oct 2014 13:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 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.786, SPF_PASS=-0.001] 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 b9CqFE4nFkkb for ; Mon, 13 Oct 2014 13:02:24 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98591A0006 for ; Mon, 13 Oct 2014 13:02:24 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id u20so14035099oif.14 for ; Mon, 13 Oct 2014 13:02:24 -0700 (PDT) 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=8u3f3DrBkIHFqy7nv3bI+BmYWPCdBYusxkzT1gEwNGU=; b=Z1rZBVBurpQkYyl6b1cy2gUx2/1oy+syd3egF3uACsp8slG6J+KWddalLyuyBdeARN BTo1SAjGC3ha4/He/88IH7rT/uKs/qLlU2DWqIFLHAR0BWKG26hGF56G7kyh8XD5K+EG ASpCWkQHzrdhyOlztsSi1I3O2EgYHvwYYvAN0UaLTnWq7jwdNmqz285O5WR3IJRMlxxQ 3vZTg24HcXYaXljMqn+HFXqYuK8LEXKss42NBeCXXu5AEKFF+Q1gA1ByF19jsdmstkri RBqD22MgeQZLWjFc3HxgUxBvmL2XarxyyHB6VOxxCfSl+Dp/HrKleyka832E33S34+Bl LkQA== 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=8u3f3DrBkIHFqy7nv3bI+BmYWPCdBYusxkzT1gEwNGU=; b=Z7GvjYSGMTYMCcVTG6DegEJ2zWd4ahPMKPoXhg9c4Dwq4vxNXjagik624oTLvZlLy3 cdpTzGOLHusfJtz9nC8bdeyq4uBdogAicKygnVnz80xiqEqrnpxVcVrMwF7q6WloVNkY CcHU8GtLKD6RzubjUPETl/gzGQHPYigrkhe03rusf6D9HnEEz8jFn3660Ck/vPgyq4Ei 0BDM48JNSEG8JkNqQVdwU+d2sPIqKig5rvZTbpowxh95f0ixFhriAnJDuBkbo0qazZOS 2EIk/06ByhFrYKqG4SFuze7F1+nM9Wf8SyYGNyXjD+0wbvrO++ap6V/88bsLAZTQ+Och pvzA== X-Gm-Message-State: ALoCoQmm/W0pj5s1gafgGThSpDd+LZgk8VJkTbKIM33KFdq3sPEKClwK0+ks6hm5UypUf1/0HHtG MIME-Version: 1.0 X-Received: by 10.182.191.10 with SMTP id gu10mr598642obc.78.1413230544003; Mon, 13 Oct 2014 13:02:24 -0700 (PDT) Received: by 10.182.55.68 with HTTP; Mon, 13 Oct 2014 13:02:23 -0700 (PDT) In-Reply-To: References: <7E8E7D4E-61D0-4C6B-B5CC-FFAE1BF80699@gmail.com> Date: Mon, 13 Oct 2014 13:02:23 -0700 Message-ID: From: Chris Palmer To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/oXh2DjEl-26nPGEt_7AQReVs5Bw Cc: "draft-ietf-websec-key-pinning.all@tools.ietf.org" , IETF WebSec WG Subject: Re: [websec] DISCUSS positions on draft-ietf-websec-key-pinning 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, 13 Oct 2014 20:02:26 -0000 On Sat, Oct 11, 2014 at 1:03 PM, Barry Leiba wrote: > Everyone, thanks for the work on this. The working group will officially > remain open until the RFC is published, after which I'll close it, but will > leave the mailing list open for any continued discussion. Thank you, everyone! From nobody Tue Oct 14 09:33:46 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 D04C91A8A7A for ; Tue, 14 Oct 2014 09:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 SsYrY053dW-e for ; Tue, 14 Oct 2014 09:33:43 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A5FC1A8A64 for ; Tue, 14 Oct 2014 09:33:43 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id hn15so15333502igb.9 for ; Tue, 14 Oct 2014 09:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=vL3rrWYnDpExi3m7pA7Od9D/iSN8HyH3yeH9FA90mDU=; b=WP7weEFHLDrSNE/RQpbE6D2KJ6CxYyi8fEr0b83l/c394Ie3OPWe+EmfSd6QKZsPld oZVD99H75Czp8ArC9V081Jbdug06Lwsw9C1e+dEZ7MeAhaXK7a4f6jIkl1hLZ80HUVLE zsILa/XH6Sfx/j6exulA0EQSyudX1kfv8uktLOBBimObD+0/B/I3YMArs1wPO3yvT7xW y5VcM75uxv5W50zfiveb0uejRfs4RePoyh2cnKiBjrpvR00NFyeD58KJG5PRMAVofPsp IMERfFCCr2hWOuA4IU2rWCRO/nx2+CDhaC3vbKUA74OZnW+VCgHZkcpbgset7be2hI/z izXw== MIME-Version: 1.0 X-Received: by 10.42.187.72 with SMTP id cv8mr6187002icb.22.1413304422656; Tue, 14 Oct 2014 09:33:42 -0700 (PDT) Received: by 10.107.3.87 with HTTP; Tue, 14 Oct 2014 09:33:42 -0700 (PDT) Date: Tue, 14 Oct 2014 12:33:42 -0400 Message-ID: From: Jeffrey Walton To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/1JoI4ZcbjxcoThFf6g7yQhDt5dI Subject: [websec] Question on Pinning Overrides X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:33:44 -0000 Section 2.7 states: UAs MAY choose to implement additional sources of pinning information, such as through built-in lists of pinning information. Such UAs should allow users to override such additional sources, including disabling them from consideration. >From section 2.7, I understand a _user_ can provide an override to a _preloaded_ pinset. But I don't see where a user is provided the authority to override a non-preloaded pinset. And I don't see where an external entity is provided authority to override a preloaded or non-preloaded pinset. Is this correct? If correct, shouldn't the user be allowed to override both preloaded and non-preloaded pinsets? If correct, won't that break Chrome with respect to http://www.imperialviolet.org/2011/05/04/pinning.html (see section "What about MITM proxies, Fiddler etc?")? From nobody Tue Oct 14 09:58:22 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 D24271A8BBE for ; Tue, 14 Oct 2014 09:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 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.786, SPF_PASS=-0.001] 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 8swnbSHR88dD for ; Tue, 14 Oct 2014 09:58:14 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027F61A8AE4 for ; Tue, 14 Oct 2014 09:58:13 -0700 (PDT) Received: by mail-oi0-f46.google.com with SMTP id h136so17236568oig.33 for ; Tue, 14 Oct 2014 09:58:13 -0700 (PDT) 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=/uDmFKl/wrdHiSnFZKMJ6l3ljlqa/I8TG+3j9J+T9ZM=; b=XIlvJBm3CUHiiWY4q1aXh/qBFMqudWx3KI8PIqMS9rVpo7ExKFrAwjweXox2IJ1u35 iO9ycvhgH5mTkxdd7KBdvFUUOtLzbwtOr5uYt07uNv/FS4Cl/ihnuTCykGFlDXStAb4i 2tHpBBPC/slB8mjJNkUFZJG7Ckzbw9kYlAZc0jLoM4PU/2Qh77DLjpXuPooHeNRbOjFh IScZPqdAQHQqDAwZVmygUJbnRM+HZ2KwqkUiHFgOOdZLjR92bUCLi3jgNBHjGBLM11Z2 k6lbk5rJEvTj7ChlmGUYKbL227unQIvog/kVnNKr6tgkw3oXJS1B3Peh1HBQc4AjzCg1 Qfxw== 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=/uDmFKl/wrdHiSnFZKMJ6l3ljlqa/I8TG+3j9J+T9ZM=; b=DH8UqIB8bx8HMVoLwC5hr2NLK8nvcQG9usnnZMCRF1jmtJL0CNUfnh+Bin51yKMsdq g+/YhoS0woIVdtHFOWff/ZzmB4om86ZWbajJRBvSkYiFdBbACPY8MDZ9FUWcg2YA7yZI I2t4AHXBHoidNccJD1U/uxB5j77O3by/KZboANYW3Ul6CJ0Eu4Vm5CADNF871s6Ip8sn vqyFEMKOyrimHu3USEzR3f6Yw1AXSysxKIVeXOWZKfLG2g4xzn/Fi6vE7oAF4Rz5b4uH 7u/wqojYzt+6BYkYVf4Gs17dXdtn7HpFfH8/ps6JNsE4q5sLStoDW1WfPkuD8+FQVuoc 8y6A== X-Gm-Message-State: ALoCoQle+TDGosSMmxJlA3sl+QgFOTx1vtp6VWlbfm4hdRjDWyxM7lB5xRfVPMhBQIAyYLSWagcA MIME-Version: 1.0 X-Received: by 10.182.176.66 with SMTP id cg2mr5715776obc.21.1413305893373; Tue, 14 Oct 2014 09:58:13 -0700 (PDT) Received: by 10.182.55.68 with HTTP; Tue, 14 Oct 2014 09:58:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Oct 2014 09:58:13 -0700 Message-ID: From: Chris Palmer To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/Qt_EHr5voFJCSrs5dVV1QluIQMM Cc: IETF WebSec WG Subject: Re: [websec] Question on Pinning Overrides 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: Tue, 14 Oct 2014 16:58:16 -0000 On Tue, Oct 14, 2014 at 9:33 AM, Jeffrey Walton wrote: > Section 2.7 states: > > UAs MAY choose to implement additional sources of pinning > information, such as through built-in lists of pinning information. > Such UAs should allow users to override such additional sources, > including disabling them from consideration. This is so that, for example, there is at least a chance people can recover from stale built-in pin sets. (Chrome currently handles this by skipping Pin Validation for built-in pin sets if Chrome detects that it was built 10 weeks or more in the past.) > >From section 2.7, I understand a _user_ can provide an override to a > _preloaded_ pinset. But I don't see where a user is provided the > authority to override a non-preloaded pinset. And I don't see where an > external entity is provided authority to override a preloaded or > non-preloaded pinset. > > Is this correct? > > If correct, shouldn't the user be allowed to override both preloaded > and non-preloaded pinsets? > > If correct, won't that break Chrome with respect to > http://www.imperialviolet.org/2011/05/04/pinning.html (see section > "What about MITM proxies, Fiddler etc?")? Section 2.6: """ For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform).""" So that's how you make Fiddler work, among other things. From nobody Tue Oct 14 12:20:24 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 3D05A1A034B for ; Mon, 13 Oct 2014 08:13:10 -0700 (PDT) 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 aufaVYzkGhpH; Mon, 13 Oct 2014 08:13:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F151A0352; Mon, 13 Oct 2014 08:13:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: websec-chairs@tools.ietf.org, draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013151301.18153.72866.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 08:13:01 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/websec/fTlmBOzm1iBg5enveZt0t5vasJM X-Mailman-Approved-At: Tue, 14 Oct 2014 12:19:55 -0700 Subject: [websec] ID Tracker State Update Notice: X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:13:10 -0000 X-List-Received-Date: Mon, 13 Oct 2014 15:13:10 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ From jeff.hodges@paypal.com Thu Oct 16 17:22:56 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 79F4C1A9073 for ; Thu, 16 Oct 2014 17:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.101 X-Spam-Level: X-Spam-Status: No, score=-21.101 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 IXEAmci28kwc for ; Thu, 16 Oct 2014 17:22:55 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496011A9071 for ; Thu, 16 Oct 2014 17:22:55 -0700 (PDT) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:user-agent:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:X-CFilter-Loop; b=JHsAXYGmmJHzm+ysmA1mZ0K/yJwag8G8Ov/ZQprhbP3FyVWMYaGxfLXE hkrfWEA5c06onSLrg4mqoGai1fWn6jYM4BOLf1duNRXPbGOl19YZG5BAt HO9cYRx9xHSf/IRsUmwNFkOqYlKPQSJdvfLKg2VF5njWdQ5XPRq5glqqF w=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1413505376; x=1445041376; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bdUCqxUhLFxb7GkMrFFZ9yho3VwayjwXgFZncWSVNpo=; b=HouaAiFJmMsvTS7NuSS0CepedQqiYS0kUhB7o+GFHvEbU2Eq7IaChfHv Qdz1rzqNpucWCprEK2YMwbfxg9oM4pQcdY1Gn/ESipGwWTftpNAU+jVZ+ K9gwDuGBUB2B32YuYsYXK7C+gR5waZ8bI7TB/Ism1eIO5v4qBFM8SxlVC g=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="5.04,735,1406617200"; d="scan'208";a="73415274" Received: from den-vteml-003.corp.ebay.com (HELO DEN-EXMHT-005.corp.ebay.com) ([10.101.112.119]) by den-mipot-002.corp.ebay.com with ESMTP; 16 Oct 2014 17:22:55 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-005.corp.ebay.com ([fe80::8109:2a37:17ad:e57e%18]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 18:22:54 -0600 From: "Hodges, Jeff" To: IETF WebSec WG Thread-Topic: [websec] wrt closing the websec WG (was: DISCUSS positions on draft-ietf-websec-key-pinning Thread-Index: AQHP6aB+dQ2PlIOgsk228B8mCYQh0Q== Date: Fri, 17 Oct 2014 00:22:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [24.5.2.144] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/websec/ANHqPKi82Q1-vdzcwzJ8rgc_Cz0 X-Mailman-Approved-At: Thu, 16 Oct 2014 18:47:48 -0700 Subject: [websec] wrt closing the websec WG (was: DISCUSS positions on draft-ietf-websec-key-pinning 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: Fri, 17 Oct 2014 01:27:39 -0000 T24gMTAvMTEvMTQsIDE6MDMgUE0sICJCYXJyeSBMZWliYSIgPGJhcnJ5bGVpYmFAY29tcHV0ZXIu b3JnPiB3cm90ZToNCg0KPiAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBvZmZpY2lhbGx5IHJlbWFp biBvcGVuIHVudGlsIHRoZSBSRkMgaXMNCj5wdWJsaXNoZWQsIGFmdGVyIHdoaWNoIEknbGwgY2xv c2UgaXQsIGJ1dCB3aWxsIGxlYXZlIHRoZSBtYWlsaW5nIGxpc3QNCj5vcGVuIGZvciBhbnkgY29u dGludWVkIGRpc2N1c3Npb24uDQoNClllcywgcGxlYXNlIGRvIGxlYXZlIHRoZSBtYWlsaW5nIGxp c3Qgb3BlbiwgdGhlIFdlYiBpcyBhIHBlcmNvbGF0aW5nIHBvdA0KYW5kIHRoZXJlIG1heSB3ZWxs IGJlIG1vcmUgcHJvdG9jb2wtbGV2ZWwgc2VjdXJpdHkgc3R1ZmYgYm9pbGluZyBvdmVyIGludG8N CklFVEYgdGVycml0b3J5IChJIGRvbuKAmXQgaGF2ZSBhIGZpcm0gZXhhbXBsZSByaWdodCBub3cs IGJ1dCBzb21ldGhpbmcgYWxvbmcNCnRoZSBsaW5lcyBvZiBkZWZpbmluZyBtb3JlIGdlbmVyaWMg cG9saWN5LWV4cHJlc3Npb24gZm9ybWF0KHMpIGlzIG5vdCBoYXJkDQp0byBpbWFnaW5lKSwgYW5k IHNvIHBlcmhhcHMgc2ltaWxhciB0byB3aGF0IHdlIGRpZCB3aXRoIEhUVFAtU3RhdGUsIHdobw0K a25vd3MsIHdlIG1pZ2h0IGhhdmUgYSBuZWVkIHRvIHJlLXNwaW4gaXQgdXAuDQoNClRoYW5rcywN Cg0KPUplZmZIDQoNCg== From jeff.hodges@paypal.com Thu Oct 16 17:23:58 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 AD6B61A9072 for ; Thu, 16 Oct 2014 17:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.501 X-Spam-Level: X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 3sheyXaMD8Xk for ; Thu, 16 Oct 2014 17:23:57 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201021A7013 for ; Thu, 16 Oct 2014 17:23:57 -0700 (PDT) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:Received: From:To:Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:user-agent: x-originating-ip:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Return-Path: X-CFilter-Loop; b=mevNYe2r5Se7KJyVruoYJa1M7bi82Wb1hXTDihr2gyi8goaIj/+UVNpr +uS4TkTIfkt8VSCLIWKQrwT5zMAR1iVHb0EpwH2KC2u8TyF4O0r6YRxRa m25TXxHeFkDJ2uBL2JVvQgY36Lb+jd9Oc65dPlakJQ7fNV7VwBH2B9Vy6 M=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1413505437; x=1445041437; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9n+hz9TP84fHTPHApqYiZwX2V+LZv4UpE3DQjgsMV+U=; b=f0DDVkH7zVc9aWfHGVac/PXUpbQqB8eS1pYTAvvVn7m2592ED28vRLbz cib99TYOnbmslT3s0fIoZT4pneJToD3u53+6kkjL1ri9bEHy3ym/ODAXS uLyJzB7/gPJouykAcFd/3MbhxbddiFDxO8Glyb0kRDu3050/d+OhspPWI M=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="5.04,735,1406617200"; d="scan'208";a="73415424" Received: from den-vteml-004.corp.ebay.com (HELO DEN-EXMHT-001.corp.ebay.com) ([10.101.112.120]) by den-mipot-002.corp.ebay.com with ESMTP; 16 Oct 2014 17:23:57 -0700 Received: from DEN-EXMHT-011.corp.ebay.com (10.241.52.136) by DEN-EXMHT-001.corp.ebay.com (10.241.17.148) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 16 Oct 2014 18:23:56 -0600 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-011.corp.ebay.com ([10.241.52.136]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 18:23:56 -0600 From: "Hodges, Jeff" To: websec mailing list Thread-Topic: [websec] Protocol Action: 'Public Key Pinning Extension for HTTP' to Proposed Standard (draft-ietf-websec-key-pinning-21.txt) Thread-Index: AQHP5vg6hMXUwww250Wr23cuaxm8xpwzYx8A Date: Fri, 17 Oct 2014 00:23:56 +0000 Message-ID: References: <20141013151302.18153.31235.idtracker@ietfa.amsl.com> In-Reply-To: <20141013151302.18153.31235.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [24.5.2.144] Content-Type: text/plain; charset="utf-8" Content-ID: <5464E149D9683A45833188D6C083B1B4@corp.ebay.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/websec/-pjzW_IF3TGJlnP4rw9D6FF2dWg X-Mailman-Approved-At: Thu, 16 Oct 2014 18:47:48 -0700 Subject: Re: [websec] Protocol Action: 'Public Key Pinning Extension for HTTP' to Proposed Standard (draft-ietf-websec-key-pinning-21.txt) 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: Fri, 17 Oct 2014 01:27:48 -0000 Q29uZ2F0cyEhDQoNCg0KT24gMTAvMTMvMTQsIDg6MTMgQU0sICJUaGUgSUVTRyIgPGllc2ctc2Vj cmV0YXJ5QGlldGYub3JnPiB3cm90ZToNCg0KPlRoZSBJRVNHIGhhcyBhcHByb3ZlZCB0aGUgZm9s bG93aW5nIGRvY3VtZW50Og0KPi0gJ1B1YmxpYyBLZXkgUGlubmluZyBFeHRlbnNpb24gZm9yIEhU VFAnDQo+ICAoZHJhZnQtaWV0Zi13ZWJzZWMta2V5LXBpbm5pbmctMjEudHh0KSBhcyBQcm9wb3Nl ZCBTdGFuZGFyZA0KPg0KPlRoaXMgZG9jdW1lbnQgaXMgdGhlIHByb2R1Y3Qgb2YgdGhlIFdlYiBT ZWN1cml0eSBXb3JraW5nIEdyb3VwLg0KPg0KPlRoZSBJRVNHIGNvbnRhY3QgcGVyc29ucyBhcmUg QmFycnkgTGVpYmEgYW5kIFBldGUgUmVzbmljay4NCj4NCj5BIFVSTCBvZiB0aGlzIEludGVybmV0 IERyYWZ0IGlzOg0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi13 ZWJzZWMta2V5LXBpbm5pbmcvDQo+DQo+DQo+DQo+DQo+DQo+VGVjaG5pY2FsIFN1bW1hcnkNCj4N Cj5UaGlzIHNwZWMgZGVzY3JpYmVzIGFuIGV4dGVuc2lvbiB0byB0aGUgSFRUUCBwcm90b2NvbCBh bGxvd2luZyB3ZWINCj5ob3N0IG9wZXJhdG9ycyB0byBpbnN0cnVjdCB1c2VyIGFnZW50cyB0byBy ZW1lbWJlciAoInBpbiIpIHRoZSBob3N0cycNCj5jcnlwdG9ncmFwaGljIGlkZW50aXRpZXMgZm9y IGEgZ2l2ZW4gcGVyaW9kIG9mIHRpbWUuICBEdXJpbmcgdGhhdA0KPnRpbWUsIFVBcyB3aWxsIHJl cXVpcmUgdGhhdCB0aGUgaG9zdCBwcmVzZW50IGEgY2VydGlmaWNhdGUgY2hhaW4NCj5pbmNsdWRp bmcgYXQgbGVhc3Qgb25lIFN1YmplY3QgUHVibGljIEtleSBJbmZvIHN0cnVjdHVyZSB3aG9zZQ0K PmZpbmdlcnByaW50IG1hdGNoZXMgb25lIG9mIHRoZSBwaW5uZWQgZmluZ2VycHJpbnRzIGZvciB0 aGF0IGhvc3QuICBCeQ0KPmVmZmVjdGl2ZWx5IHJlZHVjaW5nIHRoZSBudW1iZXIgb2YgYXV0aG9y aXRpZXMgd2hvIGNhbiBhdXRoZW50aWNhdGUNCj50aGUgZG9tYWluIGR1cmluZyB0aGUgbGlmZXRp bWUgb2YgdGhlIHBpbiwgcGlubmluZyBtYXkgcmVkdWNlIHRoZQ0KPmluY2lkZW5jZSBvZiBtYW4t aW4tdGhlLW1pZGRsZSBhdHRhY2tzIGR1ZSB0byBjb21wcm9taXNlZA0KPkNlcnRpZmljYXRpb24g QXV0aG9yaXRpZXMuDQo+DQo+UmV2aWV3IGFuZCBDb25zZW5zdXMNCj4NCj5QcmV2aW91cyB2ZXJz aW9ucyBvZiB0aGlzIGRvY3VtZW50IHJlY2VpdmVkIHVzZWZ1bCByZXZpZXdzIG9uIHRoZQ0KPm1h aWxpbmcgbGlzdC4gTWFueSBjaGFuZ2VzIHdlcmUgaW50cm9kdWNlZCBkdWUgdG8gd29ya2luZyBn cm91cA0KPmNvbnNlbnN1cywgaW5jbHVkaW5nIHRvIHBpbiBmb3JtYXQsIGFuIGluY2x1ZGVTdWJk b21haW5zIGRpcmVjdGl2ZSwNCj5hbmQgaW50ZXJhY3Rpb24gd2l0aCBwcml2YXRlIHRydXN0IGFu Y2hvcnMuDQo+DQo+U29tZSBjaGFuZ2VzIHdlcmUgcHJvcG9zZWQgYW5kIHJlamVjdGVkIGJ5IHRo ZSB3b3JraW5nIGdyb3VwLA0KPm1vc3Qgbm90YWJseSBuYW1lZCBwaW5zLCBhICJzdHJpY3QiIGRp cmVjdGl2ZSwgYW5kIGhhcmQgbGltaXRzIG9uIHRoZQ0KPm1heC1hZ2UgZGlyZWN0aXZlLiBUaGUg Y29uc2Vuc3VzIG9uIHRoZXNlIGludm9sdmVkIGEgbG9uZyBhbmQgaGFyZA0KPmRpc2N1c3Npb24s IGJ1dCBhcyBjaGFpcnMsIFRvYmlhcyBhbmQgSSBiZWxpZXZlIHRoYXQgaXQgaXMgYSByZWd1bGFy DQo+cmF0aGVyIHRoYW4gcm91Z2ggY29uc2Vuc3VzLg0KPg0KPlR3byBpc3N1ZXMgdGhhdCB3ZXJl IGxlZnQgZm9yIGxhc3Qgd2VyZSB0aGUgaW50ZXJhY3Rpb24gb2YgcHJlLWxvYWRlZA0KPnBpbnMg d2l0aCBub3RlZCBwaW5zLCBhbmQgdGhlIHByb2Nlc3Npbmcgb2YgcmVwb3J0LW9ubHkgcGlucy4g VGhlcmUNCj53YXMgYSBsb3Qgb2YgY29udHJvdmVyc3kgYW5kIGEgbG90IG9mIGJhY2stYW5kLWZv cnRoIGFib3V0IHRoZXNlDQo+aXNzdWVzLiBXZSBiZWxpZXZlIHRoYXQgdGhlIGN1cnJlbnQgZHJh ZnRzIHJlcHJlc2VudHMgdGhlIHdvcmtpbmcNCj5ncm91cCdzIGNvbnNlbnN1cywgYWx0aG91Z2gg YXQgbGVhc3Qgb25lIHBhcnRpY2lwYW50IHdvdWxkIGhhdmUNCj5wcmVmZXJyZWQgYSBkaWZmZXJl bnQgb3V0Y29tZS4NCj4NCj5QZXJzb25uZWwNCj4NCj5Zb2F2IE5pciBpcyB0aGUgZG9jdW1lbnQg c2hlcGhlcmQuIEJhcnJ5IExlaWJhIGlzIHRoZSByZXNwb25zaWJsZQ0KPkFyZWEgRGlyZWN0b3Iu DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj53 ZWJzZWMgbWFpbGluZyBsaXN0DQo+d2Vic2VjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby93ZWJzZWMNCj4NCg0KDQo= From nobody Sun Oct 19 09:27:34 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 985D41A1C00 for ; Sun, 19 Oct 2014 09:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 Exdc4Svd094J for ; Sun, 19 Oct 2014 09:27:31 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15421A1BFC for ; Sun, 19 Oct 2014 09:27:30 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rp18so3274504iec.7 for ; Sun, 19 Oct 2014 09:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TD18FvCVHxPLIDQwIu0e5TLLMcAy8IHU7wfIrUy30Dk=; b=sky9AL+ZqMB4gpU8eYbnYfVqOG1BFDRKQPKQ/VRiTFF/JxxYYbcjFqSgZvc2qcjXl2 hx4JE1/uyPN7yB3tXRWfSXZKVNu70ZYsg4uqwpSpy7pPnJrgUN0i3Lp9hp/cU6CShXVJ nIMaN7NL23e3vUlyi9rcD+Zyr7cmCgo2kaB+GycFx7ppVML6MkgDhaSZ/E87xrx+QFdf eJzsHqbxECp6oCeBc/EqHUJO2OQRJUXJj+F6ujud8gd99P5r9e5bXEcCSwQNcybnIkNA yD/ndpOxdc8f3Vy8JEpJMTzc/P4paGQ3hHteTEBNeqgFnBIIcyHI9ftzKxBAp8W4GiGf X6kw== MIME-Version: 1.0 X-Received: by 10.50.142.71 with SMTP id ru7mr770947igb.32.1413736050209; Sun, 19 Oct 2014 09:27:30 -0700 (PDT) Received: by 10.107.3.87 with HTTP; Sun, 19 Oct 2014 09:27:30 -0700 (PDT) In-Reply-To: References: Date: Sun, 19 Oct 2014 12:27:30 -0400 Message-ID: From: Jeffrey Walton To: Chris Palmer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/S4BJEfn1scF0l3E8bizWgUlMzJs Cc: IETF WebSec WG Subject: Re: [websec] Question on Pinning Overrides X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 16:27:32 -0000 Hi Chris, I've had a few days to think about this... >> If correct, won't that break Chrome with respect to >> http://www.imperialviolet.org/2011/05/04/pinning.html (see section >> "What about MITM proxies, Fiddler etc?")? > > Section 2.6: > > """ For example, a UA may disable Pin Validation for Pinned Hosts > whose validated certificate chain terminates at a user-defined trust > anchor, rather than a trust anchor built-in to the UA (or underlying > platform).""" > > So that's how you make Fiddler work, among other things. This is where I am concerned: user-defined. I thinks its a mistake to claim the user defined anything under most circumstances and use cases. Its not clear to me where the user makes a well informed decision. The uncommon case is the pen-tester or researcher using the proxy tools. In this use case, the user clearly made the decision, and clearly defined the trust anchor. I think the more common cases of "I want to use my device at work" or "I must click through the buttons to use the wifi hotspot" is devoid of any user understanding and decision. In this use case, the user did not define a trust anchor. Rather, it was surreptitiously installed by the device management software or unscrupulous service providers. In fact, the "user's decision" was likely hidden away in a Terms of Service when Nokia was caught performing intercept en masse [0]. In this case, the user clearly did not define anything. Rather, the handset manufacture made the decision for the user. Is there anything that can be done to address the gap? [0] http://web.archive.org/web/20140127075723/http://falkvinge.net/2013/01/11/death-twitches-nokia-caught-wiretapping-encrypted-traffic-from-its-handsets/ From nobody Mon Oct 20 11:40:20 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 C6E611A9039 for ; Mon, 20 Oct 2014 11:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 17t4vJ95jVMJ for ; Mon, 20 Oct 2014 11:40:16 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962F91A903D for ; Mon, 20 Oct 2014 11:40:16 -0700 (PDT) Received: by mail-oi0-f45.google.com with SMTP id i138so4190193oig.32 for ; Mon, 20 Oct 2014 11:40:15 -0700 (PDT) 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=mR1n40BxwEhQLFZYtQ0ChK22hyE58lWWMYOYO3i1Hpo=; b=bE2qd0zqZvgN8M54/7VurW6BpUirAmtY0P43RWV5xA51x54qG0zuinsNmvXTqpm4oJ m7Ap9fWOTHskmKaMNFw+/Ok2aSH59Asmds4d5+tBdHafeq4+MKih+W4zwsWDY4+L2tuc 4cYfq67sbqF8xdeuZi9ZO4/SbKJ4knFzTus32Sn9Cgx7PIq3MfRLPzlgZYf+4jjC0a2y b5kx6so69SWvBX4qF0GFYv0f4nf2kK4UpjkjU2BC+44lLxQcRNsWpVFYXsiLTN6M3Gft 7pm9fX7pYwyozPB8NOvrE9PCzIGom2eQGK3CVYvmyCsHyLyDtJqg6R9tlbYGGeemugCm +NKA== 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=mR1n40BxwEhQLFZYtQ0ChK22hyE58lWWMYOYO3i1Hpo=; b=SVF/L8c5uz8N6h1OAvm/vMinxu0DQUlaLQwbmA+n8XPLqqkenzapaK8300I6nNdcrM fJLwUCgQjOMC3aJv7jJniEjwx7nMf7DwC1duCxrx3F8HYYJVEpCAqZF9lZVzsPWVm7gS QEWjQlQhxLfKlIomwuRXRAzY9tiVTSktnMulgqjfD5HaC43VHIPsQzqRcx0GTInXqOXB s0vy5ebxt27efT04SNJz9WPIyaCIjrC91O2P+hvzkLa/bs/YY6/PaCFVthd0np65t7gN B2AhAhZWP/a3/YBwiZQyGKuWDB9Wl/92mNxCBvgE/ptyl6oSWdqJR+E52oZe9Yeh/k4e C6TQ== X-Gm-Message-State: ALoCoQm+YuPGieYJ929I4AYTRP8ruBUD8Lt9UtfQ6nB07OkTgeMmqZ/rd48hjpXZxkfl4t6s7Wcb MIME-Version: 1.0 X-Received: by 10.202.3.70 with SMTP id 67mr3280753oid.69.1413830414995; Mon, 20 Oct 2014 11:40:14 -0700 (PDT) Received: by 10.182.55.68 with HTTP; Mon, 20 Oct 2014 11:40:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 11:40:14 -0700 Message-ID: From: Chris Palmer To: noloader@gmail.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/GSR0quBHnKWdxJrPY_rqWQhUcDI Cc: IETF WebSec WG Subject: Re: [websec] Question on Pinning Overrides 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 Oct 2014 18:40:17 -0000 On Sun, Oct 19, 2014 at 9:27 AM, Jeffrey Walton wrote: > I think the more common cases of "I want to use my device at work" or > "I must click through the buttons to use the wifi hotspot" is devoid > of any user understanding and decision. In this use case, the user did > not define a trust anchor. Rather, it was surreptitiously installed by > the device management software or unscrupulous service providers. To install a new trust-anchor, the attacker/owner/user/device administrator must have administrative control over the device, or must trick the true owner into mis-using their power. Such an attacker is, by necessity, outside the scope of the key pinning threat model. http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- > In fact, the "user's decision" was likely hidden away in a Terms of > Service when Nokia was caught performing intercept en masse [0]. In If the device manufacturer is also taking administrative control over devices in the field, then market pressure (such as those articles) is the only recourse. We can't do anything technically that would not also break legitimate use cases. From nobody Wed Oct 29 21:48:10 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 07A191A88AD for ; Wed, 29 Oct 2014 11:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 8EIhOrek3v0F for ; Wed, 29 Oct 2014 11:55:58 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945721A88A9 for ; Wed, 29 Oct 2014 11:55:58 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so2967280qcy.1 for ; Wed, 29 Oct 2014 11:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=RxCCMUpx+e1z+ssOkdIrC4wHYdLrpRzYD8yiXBNl5KY=; b=XW1ge72JmeElCUlDhYNsFxIRqwDHnDTskOh5NamuxwytGyGc+rsga0lwHNYmHjUzY+ 5FfMLdBiP2c2OWeBsJN5dYecSvINn1hZgqrjGsRrVPixY2B2XjkMYaEF0D7ykArcw9zp MH5beToyuRJPrqmWPLwwvvu/IIBM2e8SABZfQYIwzKNPwHttgViLZIJ5WDrtaKNcZCtr sZPAt3+z48LcKOHqQvuqcj9iy340SQJYaxUeW9aCtGm0FQlYAyRfrhFm0mEOP6yeJUXG dID7MK/Cm3mEd08dU9tR0NHldFvvnNRQAlcvgrCeggvqbJorXm5xuC+GTVBId8i8SkJt 63pg== MIME-Version: 1.0 X-Received: by 10.140.51.102 with SMTP id t93mr17816152qga.72.1414608957752; Wed, 29 Oct 2014 11:55:57 -0700 (PDT) Sender: annevankesteren@gmail.com Received: by 10.229.174.134 with HTTP; Wed, 29 Oct 2014 11:55:57 -0700 (PDT) Date: Wed, 29 Oct 2014 19:55:57 +0100 X-Google-Sender-Auth: 60jYjE7VozFimzf6astHiOqXyQw Message-ID: From: Anne van Kesteren To: websec Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/websec/QMZPeEZ0ManRH9kEpt3UY7NNrCc X-Mailman-Approved-At: Wed, 29 Oct 2014 21:48:10 -0700 Subject: [websec] HSTS at DNS level 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: Wed, 29 Oct 2014 18:56:00 -0000 Is there some way we could add an annotation to DNS that makes it clear a given domain for the purposes of HTTP is only available over port 443 using TLS? DNS can be easily spoofed of course so you also want HSTS, but perhaps it would be sufficient to be able to disable port 80 entirely. -- https://annevankesteren.nl/ From nobody Wed Oct 29 22:33:36 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 5A6C71AD00A for ; Wed, 29 Oct 2014 22:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 5az6vvNa8k35 for ; Wed, 29 Oct 2014 22:33:32 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C68A1ACFA5 for ; Wed, 29 Oct 2014 22:33:32 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so4832449wgh.10 for ; Wed, 29 Oct 2014 22:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PomMUnt9QQTjsPe4ujfXAN2ovIuw5ums6MUPk5IB+Kw=; b=mh62BPmzk8GTWakpnPnafXhSaN6YGN3HIFOBXsFDHfwJr77Qltf1/GmzMjcla533By E61MWEhb/AKvYnPSnWiCrSIQC/wz9F8zPzL5rk2o6xPq+BNlvQ125A9zF0wkhcweIdHa xm7PBa8m2klVzaFMJH1oXfaJ7HJq5D3i5nA1L8Wq2xhF2eVNSVtBGADIYKxlFazzDE37 uhsiqgG4ZFa3C0GdVwIr7pVidc2CQgpR3ZsLeNrYgSe1eicVM6GeiS/KEbcoMZgYyGuE x1+vGebubOHLg72dljNlbo3Hvqd7NL35ne0OH8uUurzv2qZ8QQIg82bvOJNZZnhyWE5i d/Lw== X-Received: by 10.194.235.132 with SMTP id um4mr17272008wjc.91.1414647211284; Wed, 29 Oct 2014 22:33:31 -0700 (PDT) Received: from [192.168.1.104] (IGLD-84-228-87-161.inter.net.il. [84.228.87.161]) by mx.google.com with ESMTPSA id fu5sm7416060wjb.26.2014.10.29.22.33.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 22:33:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Yoav Nir In-Reply-To: Date: Thu, 30 Oct 2014 07:33:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Anne van Kesteren X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/9i7nMXRd2dDQsOalNVerngf0LHE Cc: websec Subject: Re: [websec] HSTS at DNS level 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: Thu, 30 Oct 2014 05:33:34 -0000 In the early days of WebSec there was such a goal. That is why HSTS = begins with an =E2=80=9CH=E2=80=9D. It differentiates it with the DSTS = that is based on DNS.=20 Nobody ever got around to writing a DSTS draft. HPKP does have a DNS = equivalent - it=E2=80=99s DANE.=20 Yoav > On Oct 29, 2014, at 8:55 PM, Anne van Kesteren = wrote: >=20 > Is there some way we could add an annotation to DNS that makes it > clear a given domain for the purposes of HTTP is only available over > port 443 using TLS? DNS can be easily spoofed of course so you also > want HSTS, but perhaps it would be sufficient to be able to disable > port 80 entirely. >=20 >=20 > --=20 > https://annevankesteren.nl/ >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nobody Fri Oct 31 05:27:06 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 671C11AD060 for ; Thu, 30 Oct 2014 02:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 TiHclsIn2f0X for ; Thu, 30 Oct 2014 02:23:21 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315161AD04B for ; Thu, 30 Oct 2014 02:23:21 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id i17so3839232qcy.31 for ; Thu, 30 Oct 2014 02:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rd/jiT+/xyYFQUd1mDtZQ1bPfdJZUPeF5fW41AocEfY=; b=dkuJNDMblcYFQJvUvLavtoMB/a3tf4Ty2oDVbwKAhoRWabFf6mWo6Yyt2qfMuorDkN g6sKAB3rWVaI4NhdUmXjfAO+i6byuq+OynmduZdt2RBxyiB8FMCTmO0LL1a56A4Ysvrn BAksCVA25ZWaV7VicyjxhRxFqfiGuO4K5cR/ckGYMvhTAZmINvxW1JUcGuD2EYxN3icw QW3t/YUH7+MnbJM2DvcXSge/eTI6kpltG8UzHaOHCdTqtW/kCrUyrmjSxRZf3IrP4lLl 3sC21THTsM/SRZu8+gpezyVTkiVKKZXlavlRrQ76AUNISvUXA5dFIDOdtRJ4nQqFC05I jVgA== MIME-Version: 1.0 X-Received: by 10.224.16.135 with SMTP id o7mr24230318qaa.37.1414661000286; Thu, 30 Oct 2014 02:23:20 -0700 (PDT) Sender: annevankesteren@gmail.com Received: by 10.229.174.134 with HTTP; Thu, 30 Oct 2014 02:23:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Oct 2014 10:23:20 +0100 X-Google-Sender-Auth: 5hKdoYpi6tKznkuobFhzL0iQhhM Message-ID: From: Anne van Kesteren To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/websec/g5wBJrmXgXjG2tEZpFxyklVtjIg X-Mailman-Approved-At: Fri, 31 Oct 2014 05:27:04 -0700 Cc: websec Subject: Re: [websec] HSTS at DNS level 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: Thu, 30 Oct 2014 09:23:22 -0000 On Thu, Oct 30, 2014 at 6:33 AM, Yoav Nir wrote: > In the early days of WebSec there was such a goal. That is why HSTS begin= s with an =E2=80=9CH=E2=80=9D. It differentiates it with the DSTS that is b= ased on DNS. Thanks! I should have checked the archives. http://www.ietf.org/mail-archive/web/websec/current/msg00004.html seems pretty clear on why this would be hard. --=20 https://annevankesteren.nl/