From ynir@checkpoint.com Sat Nov 16 23:53:36 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4F811E87C6 for ; Sat, 16 Nov 2013 23:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXnKipr+hN2I for ; Sat, 16 Nov 2013 23:53:31 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 69C6C11E87B6 for ; Sat, 16 Nov 2013 23:53:21 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rAH7rJnT024642 for ; Sun, 17 Nov 2013 09:53:19 +0200 X-CheckPoint: {528873D9-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 09:53:19 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: HPKP: The strict directive and TLS proxies Thread-Index: AQHO42oUsglYxW/W9EiAzsLJN0944w== Date: Sun, 17 Nov 2013 07:53:18 +0000 Message-ID: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.100] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 17 Nov 2013 07:53:37 -0000 Hi, all I know this is late days and all, but something on the httpbis list got me = to thinking about this. Section 2.1.4 defines the "strict" directive. When present, it means that "= the UA ... should apply to the Pinned Host the Pinning Policy expressed in = the PKP header ... ignoring local client policy." While the text does not say what this local policy might be, the reason for= having this was the policy to allow locally-issued certificates to be used= for pretty much anything. This policy accommodates TLS proxies. So if a se= curity-minded bank would like to avoid interception even at the cost of bei= ng inaccessible from many places of business, they can use the "strict" dir= ective.=20 Now consider two devices. One is a mobile platform, could be a phone or a l= aptop, that the user carries around from home to work. The other is a deskt= op computer, that is always at work. The laptop will at some point be used = at home to access the bank. The PKP gets noted, and from that point on, the= user will not be able to access the bank from work.=20 The desktop computer cannot note the PKP, and will always be able to connec= t to the bank. Section 2.5 says this: o The UA MUST note the Pins if and only if the TLS connection was authenticated with a certificate chain containing at least one of the SPKI structures indicated by at least one of the given SPKI Fingerprints. This rule is a safety rule, to avoid being injected with bogus PKPs, mostly= through misconfiguration of the server. There are other requirements (that= TLS be error-free) that make sure it is not done by an attacker (at least,= not a non-trusted attacker).=20 I'm wondering if we should remove this requirement from section 2.5 when th= e "strict" directive is present. IOW, should we allow noting of PKPs with t= he "strict" directive as long as the TLS connection is valid. I can see how= this would make it easy for a TLS proxy to brick the browser, but I'm wond= ering what others think of the trade-off. Yoav From tom@ritter.vg Mon Nov 18 11:49:54 2013 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 33FC91AE1F3 for ; Mon, 18 Nov 2013 11:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 do8xcOgKSQWT for ; Mon, 18 Nov 2013 11:49:52 -0800 (PST) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B0C751AE1B3 for ; Mon, 18 Nov 2013 11:49:49 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i4so2052238oah.1 for ; Mon, 18 Nov 2013 11:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=cYGDr4EX0qkwf7js3ni07FlWQ/Ybh6tIw4x5R39egkc=; b=WHTR1sOIbwqyG1xcF0PkcTPkiGehLcUgOObtUSYzjGXDIUVZ2ryravX8zennLSbzAr p+oF6lusO3seQiBL8ej03n1K1VZIWTeuga8ET+Bt0Px3ykOoAuq94H+BrTeKbOrkgczi 0oFWqi2vuridP6XcgkGP++Q8pbYoRs3SXL2Ig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cYGDr4EX0qkwf7js3ni07FlWQ/Ybh6tIw4x5R39egkc=; b=T1w1PIo1mtBWojX+xbHXAzx1EO+8iGOKwchFTfVMKiILHqrNUK0PlTvD/5vcQVszmN PwgzWJj8YqMsU1xp8lHTRC/5y6V4g/YoByX3RHVRwkv8SYxjBABAFejz8/YZcVyuxL0I uiMGakAmFFQ65Mm4oFn5QY604tseQcVOeSp96E87DF6ajZ5DnYEdaQwOKHUm2Ra0Zk1O LF2Xrc535h4mYGFxlNtpIOItZ+ujoDH/mniP138oR4gC/Qvt3oHbVM1D2oe3V3Fo03AV smCoZ9YOPPvMHzmqSrXeB57dMjFz7wixDvBfstM7Ap8pxXjygQsfHaFoZgctcwOc1pdQ wOFA== X-Gm-Message-State: ALoCoQk7yXfMmbt6TFIHoJKeXb1crHv4FxkdSFtBKRx3pin9DAJetOpO/fhFFtp0iHfH7j4F4W9a X-Received: by 10.182.44.134 with SMTP id e6mr21597316obm.14.1384804183866; Mon, 18 Nov 2013 11:49:43 -0800 (PST) Received: from [192.168.43.217] ([172.56.38.148]) by mx.google.com with ESMTPSA id j9sm31329213oef.8.2013.11.18.11.49.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 11:49:41 -0800 (PST) Message-ID: <528A457D.1030804@ritter.vg> Date: Mon, 18 Nov 2013 11:51:09 -0500 From: Tom Ritter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: websec@ietf.org References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> In-Reply-To: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 18 Nov 2013 19:49:54 -0000 Hm. Interesting predicament. Two thoughts: If the goal is to allow clients to note and obey the 'strict' directive even in the face of a SSL Interception proxy... what you propose won't work. The proxies will be built to just remove the strict directive, or the header all together. If the organization running the proxy wanted to block access to the site in question, they would do so. If they want to monitor ongoing access, they will strip the directive/header so the clients continue to connect. If they are ambivalent - 'access it or not, we don't care, but must monitor you if you do' - the stripping feature may or may not be enabled. What you propose would only help in the latter case, it will not actually provide more security if the website considers the proxy to be an adversary. And if they add the strict header, I would imagine that the website does consider them to be an adversary, or at least that they do not wish the connection to succeed.. So I don't think what you propose is worthwhile, specifically because it does add risk via sites bricking themselves, while not improving security considerably. As far as the laptop moving between home and work... I get the impression this situation may be regarded as a 'failure' of the protocol. That is, we have unintentionally broke something. I disagree. I think the situation has worked as desired. Because if we replace the players with a rogue government performing TLS MitM, with the specific goal of isolating clients from receiving up-to-date security policies... we would declare this same situation a success. I don't see a way to reconcile the two situations, as they behave almost exactly the same. TLS Proxies add a third player into what was previously a (primarily) two-party protocol*. I think the strict directive preserves the reasonable property that any one of the three parties can choose not to participate based on the settings of the protocol. - The TLS proxy can block access or choose not to intercept - The user can not visit the site - The site can declare "I don't want anyone else seeing the data I consider to be for the user's eyes only" I expect that Firefox and Google may even continue to preload entries in their browsers that apply the 'strict' directive specifically to provide websites the power to assert their right to a MitM-free connection. I know several websites who would like to exercise that right. -tom * Yes yes, CAs make 3, but that's PKIX, not TLS. From skyper@thc.org Tue Nov 19 08:07:07 2013 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 149B21AE031 for ; Tue, 19 Nov 2013 08:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 iZqsZwAceKFC for ; Tue, 19 Nov 2013 08:07:05 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 090C81AE042 for ; Tue, 19 Nov 2013 08:07:04 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so1000379ieb.32 for ; Tue, 19 Nov 2013 08:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nVRevdigjpMqDV2Yk7PU7xStB2CRgpTAMW0eUb/wiOI=; b=gMvMu1qqm5zLqmJ/6cRU6ejm61/ZE7QRS9YXthsuaEPeuUI77Q6gBi5pPxm3mhfpba 2Vyx4k8vOd+7jBmv615RLKKHBIoRkdUIsoRuRj4RCIxWe4WmhBQBr6phOtoXRyXgqTGi 2DM2ZZ4epiL2NaTXNLij8Fn3wtaJ6/eWbeXSw= 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:content-type; bh=nVRevdigjpMqDV2Yk7PU7xStB2CRgpTAMW0eUb/wiOI=; b=apQl17HpX5vw2RhxavtZtXILxYiBiqkhGNOoWjZGae8SMO6BBynAwWVTKodjo8sPtS zTBUlBIL7ihJ5jf1zIM8uk+ZeNcFPGg+EMVRdUzJhSY3m83eqD/IB+CEXuu0SyW8k6RC rcaJtUYIhBxNwyJ28HoOFDVGLgbdlWRehuXnkMuf4K1MEBek7zUyKLGln5lvXDlhCWNz X5Y+bgsWLypF2qxpku7ke+P5mGGpsImy/jAJMjdr+VE8hdMSa9ViDb9Qsum8SmrTfijl RNmrrDt1EEtHwNjRRkYFeiFNVGYKxph9J6m2XLLwL1X0uyj/ZqJbI+AsRxWIjRC66rwA FxAQ== X-Gm-Message-State: ALoCoQkHCfsOVVag8teJaX11ZFLEf0OFRcmh0DWovpBC6d65nLbJsxwTvLuaFUNCWcyGRNotPhXo MIME-Version: 1.0 X-Received: by 10.50.73.130 with SMTP id l2mr12739507igv.36.1384877218878; Tue, 19 Nov 2013 08:06:58 -0800 (PST) Received: by 10.64.9.41 with HTTP; Tue, 19 Nov 2013 08:06:58 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> Date: Tue, 19 Nov 2013 16:06:58 +0000 Message-ID: From: Ralf Skyper Kaiser To: websec@ietf.org Content-Type: multipart/alternative; boundary=089e01160edcb06d7604eb89da83 Subject: [websec] Fwd: [TLS] Working Group Last Call for draft-ietf-tls-pwd 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, 19 Nov 2013 16:07:07 -0000 --089e01160edcb06d7604eb89da83 Content-Type: text/plain; charset=ISO-8859-1 Moving discussion from TLS-WG to WEBSEC-WG. See below. ---------- Forwarded message ---------- From: Ralf Skyper Kaiser Date: Tue, Nov 19, 2013 at 10:15 AM Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd To: Dan Harkins Cc: "tls@ietf.org" Hi Dan, The security risk lies within the implementation. The capable client will always offer TLS-PWD. Simplified, this is how pinning will be implemented: The client receives the server's certificate. The client checks if the server's certificate (or better the SPKI) is already known to the client (e.g. pinned) and if the server's certificate is different to the pinned certificate then the connection fails. The draft assumes that certificate based server authentication is the only authentication that exists. The draft does not discuss the scenario where TLS-PWD is used. In such a case I'm concerned that the part of the client source code that checks for pinning is not triggered and by-passed. The client goes into the TLS-PWD mode. Instead what should be pinned is the SPKI _and_ that certificate based server-authentication must be used. E.g. once a client has pinned a certificate for a host it should not allow TLS-PWD. This is obvious to us but not obvious to the developer and should be explicitly mentioned. (It could be mentioned in websec-rfc as you say but that's beyond draft status and additions are no longer practical). Mentioning it in the TLS-PWD draft will hopefully prevent an insecure implementation. regards, Ralf On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins wrote: > > Hi Ralf, > > On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote: > > Hi, > > > > could not find it in the draft: > > > > the interoperability with draft-ietf-websec-key-pinning-08 should be > > mentioned explicitly to prevent > > an attack scenario. (e.g. user has pinned certificate for google.com. > > Attacker MITM forces > > client to do tls-pwd. Client should not allow this). E.g. once a host is > > pinned no other server-side > > auth mechanism should be allowed. > > If the client doesn't want to do TLS-pwd then it won't include the > mandatory extension in its client hello and it won't include any TLS-pwd > ciphersuites. I don't see how this attack happens. > > Perhaps the necessary requirements to deal with pinning certificates > for websec should be dealt with in the draft you mention. > > regards, > > Dan. > > > > --089e01160edcb06d7604eb89da83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Moving discussion from TLS-WG to WEBSEC-WG. See below.
=

---------- Forwarded message = ----------
From: Ralf Skyper Kaiser <skyper@thc.org>= ;
Date: Tue, Nov 19, 2013 at 10:15 AM
Subject: Re: [TLS] Working Group Las= t Call for draft-ietf-tls-pwd
To: Dan Harkins <dharkins@lounge.org>
Cc: "tls@ietf.org" <t= ls@ietf.org>


Hi Dan,

The security r= isk lies within the implementation.

The capable client will always o= ffer TLS-PWD.

Simplified, this is how pinning will be implemented: = The client receives the server's certificate. The client checks if the = server's certificate (or better the SPKI) is already known to the clien= t (e.g. pinned) and if the server's certificate is different to the pin= ned certificate then the connection fails.

The draft assumes that certificate based server authenticati= on is the only authentication that exists.

The draft does not = discuss the scenario where TLS-PWD is used.

In such a cas= e I'm concerned that the part of the client source code that checks for= pinning is not triggered and by-passed. The client goes into the TLS-PWD m= ode.

Instead what should be pinned is the SPKI _and_ that certificate based = server-authentication must be used. E.g. once a client has pinned a certifi= cate for a host it should not allow TLS-PWD.

This is obvi= ous to us but not obvious to the developer and should be explicitly mention= ed.

(It could be mentioned in websec-rfc as you say but that'= ;s beyond draft status and additions are no longer practical). Mentioning i= t in the TLS-PWD draft will hopefully prevent an insecure implementation.

regards,

Ralf




On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <dhar= kins@lounge.org> wrote:

=A0 Hi Ralf,

On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
> Hi,
>
> could not find it in the draft:
>
> the interoperability with draft-ietf-websec-key-pinning-08 should be > mentioned explicitly to prevent
> an attack scenario. (e.g. user has pinned certificate for google.com.
> Attacker MITM forces
> client to do tls-pwd. Client should not allow this). E.g. once a host = is
> pinned no other server-side
> auth mechanism should be allowed.

=A0 If the client doesn't want to do TLS-pwd then it won't in= clude the
mandatory extension in its client hello and it won't include any TLS-pw= d
ciphersuites. I don't see how this attack happens.

=A0 Perhaps the necessary requirements to deal with pinning certificates for websec should be dealt with in the draft you mention.

=A0 regards,

=A0 Dan.





--089e01160edcb06d7604eb89da83-- From ynir@checkpoint.com Tue Nov 19 15:37:33 2013 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 627731AE188 for ; Tue, 19 Nov 2013 15:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 22-VQKRyhmHm for ; Tue, 19 Nov 2013 15:37:30 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 938AA1AE138 for ; Tue, 19 Nov 2013 15:37:21 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rAJNauUS019423; Wed, 20 Nov 2013 01:37:00 +0200 X-CheckPoint: {528BF3D9-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 01:36:56 +0200 From: Yoav Nir To: Tom Ritter , IETF WebSec WG Thread-Topic: [websec] HPKP: The strict directive and TLS proxies Thread-Index: AQHO42oUsglYxW/W9EiAzsLJN09445otGBqA Date: Tue, 19 Nov 2013 23:36:55 +0000 Message-ID: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> In-Reply-To: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.9] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <3D2BAFC52A489546A684046A5EF6600C@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 19 Nov 2013 23:37:33 -0000 > Hm. Interesting predicament. Two thoughts: >=20 > If the goal is to allow clients to note and obey the 'strict' directive > even in the face of a SSL Interception proxy... what you propose won't > work. The proxies will be built to just remove the strict directive, or > the header all together. >=20 > If the organization running the proxy wanted to block access to the site > in question, they would do so. If they want to monitor ongoing access, > they will strip the directive/header so the clients continue to connect. > If they are ambivalent - 'access it or not, we don't care, but must > monitor you if you do' - the stripping feature may or may not be enabled. >=20 > What you propose would only help in the latter case, it will not > actually provide more security if the website considers the proxy to be > an adversary. And if they add the strict header, I would imagine that > the website does consider them to be an adversary, or at least that they > do not wish the connection to succeed.. I agree that it does not help security, but it increases the chances of the= server policy being enforced. This is not far-fetched. Most TLS proxies ar= e next-generation firewalls or caching proxies. They won't remove the stric= t directive. Of course, snooping proxies will act differently. > So I don't think what you propose is worthwhile, specifically because it > does add risk via sites bricking themselves, while not improving > security considerably. >=20 >=20 > As far as the laptop moving between home and work... I get the > impression this situation may be regarded as a 'failure' of the > protocol. That is, we have unintentionally broke something. I disagree. > I think the situation has worked as desired. It's the other way around. The desktop that remains at the office and keeps= ignoring the strict pins is the failure. > Because if we replace the players with a rogue government performing TLS > MitM, with the specific goal of isolating clients from receiving > up-to-date security policies... we would declare this same situation a > success. >=20 > I don't see a way to reconcile the two situations, as they behave almost > exactly the same. >=20 > TLS Proxies add a third player into what was previously a (primarily) > two-party protocol*. I think the strict directive preserves the > reasonable property that any one of the three parties can choose not to > participate based on the settings of the protocol. > - The TLS proxy can block access or choose not to intercept > - The user can not visit the site > - The site can declare "I don't want anyone else seeing the data I > consider to be for the user's eyes only" So the benevolent TLS proxy should note the "strict" directive and block th= e connection by itself? It makes sense, but that would require an upgrade o= f the TLS proxies. Changing client behavior would work with the proxies tha= t are deployed now. > I expect that Firefox and Google may even continue to preload entries in > their browsers that apply the 'strict' directive specifically to provide > websites the power to assert their right to a MitM-free connection. I > know several websites who would like to exercise that right. >=20 What? And have their sites not work in all the places that have newer firew= alls? I doubt it. Anyway, I can see how this would allow a buggy proxy to brick the users, so= I now agree that this is not worthwhile. Yoav From tom@ritter.vg Tue Nov 19 18:41:09 2013 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 0E2101AE209 for ; Tue, 19 Nov 2013 18:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 OVGUXXPjBJO3 for ; Tue, 19 Nov 2013 18:41:07 -0800 (PST) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8211AE17C for ; Tue, 19 Nov 2013 18:41:06 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id h16so3888877oag.39 for ; Tue, 19 Nov 2013 18:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VYysB9xOM4fohcMhYBQXWjj7FDBf7NFdU8uKlBq9seE=; b=Z1LEpc0E5IzqsL6urJQnWEp4uc9qOr7iQMkHa7R5816AHzOJNUEQKjynNEjsVX9c0P DZqKLcXR3XsIHKbiwNT4xvHTd1K2nAT6wbEs74r9yb9gFHPVswNBn4Lbs6BXHYT1gmMV X2dHBMvLnNCt5y2+keoshdDOkaVQSmEJ5n7zs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VYysB9xOM4fohcMhYBQXWjj7FDBf7NFdU8uKlBq9seE=; b=jq7wAhrddmLdsogdo5p7jYoCw3f2m/YBELtgFuP5QFioGfJgoH3DqEu/puv9x9zJlL uTermasaCZPUkvgXUTF+Xj+We0Z60DZATFV2AyFGkObnDbUwp2MBMWcexFZl2zE1TlXa lbsM/2lqzEwMk4U2kh57zgzgQacnsCMcibYhybK+abVP+muhmgUCusJwIlVZXKplqcYc YwJyCZxFdbfVd+hIn7BUuoQQlgaRtGeYDeP1GemlSVPB3lqUoT2RKy6dJtrkSpLjqwVa eUONnNWzox7/v63fKk38476a8IjEzQketo0Oph23NaVknpcOIA4q0LhSK6ivS7sRT+ZF WHFg== X-Gm-Message-State: ALoCoQkGWO9Xh4TjzhWXOItOKSjmSKnhNyftyZyOBQavRkrKSvoqiQcwk8mMr2rYNv3wkiY5TEY3 X-Received: by 10.182.40.201 with SMTP id z9mr9404454obk.45.1384915260420; Tue, 19 Nov 2013 18:41:00 -0800 (PST) Received: from [10.0.13.50] (ool-18b9394e.dyn.optonline.net. [24.185.57.78]) by mx.google.com with ESMTPSA id dh4sm33632333obb.3.2013.11.19.18.40.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 18:40:59 -0800 (PST) Message-ID: <528C2138.1090604@ritter.vg> Date: Tue, 19 Nov 2013 18:40:56 -0800 From: Tom Ritter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yoav Nir , IETF WebSec WG References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 20 Nov 2013 02:41:09 -0000 On 11/19/2013 3:36 PM, Yoav Nir wrote: >> As far as the laptop moving between home and work... I get the >> impression this situation may be regarded as a 'failure' of the >> protocol. That is, we have unintentionally broke something. I disagree. >> I think the situation has worked as desired. > > It's the other way around. The desktop that remains at the office and keeps ignoring the strict pins is the failure. Ah, I agree with that, also. I was anticipating an argument that the laptop had been 'broken' by the migrating. > So the benevolent TLS proxy should note the "strict" directive and block the connection by itself? It makes sense, but that would require an upgrade of the TLS proxies. Changing client behavior would work with the proxies that are deployed now. Not necessarily. Really I meant that I, as the maintainer of the SSL MITM device at FooCorp could decide "Employees aren't allowed to use personal WebMail at work" and then enforce that with blocking. Auto-Blocking based off 'strict' would absolutely require upgrades, but that wasn't my meaning. >> I expect that Firefox and Google may even continue to preload entries in >> their browsers that apply the 'strict' directive specifically to provide >> websites the power to assert their right to a MitM-free connection. I >> know several websites who would like to exercise that right. >> > > What? And have their sites not work in all the places that have newer firewalls? I doubt it. /shrug I can hope. :) -tom From ryan-ietfhasmat@sleevi.com Wed Nov 20 12:23:34 2013 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 8BAE71AE1E1 for ; Wed, 20 Nov 2013 12:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 V2SDz79UUTq4 for ; Wed, 20 Nov 2013 12:23:32 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 40D741AE12D for ; Wed, 20 Nov 2013 12:23:32 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id AA07E428076; Wed, 20 Nov 2013 12:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=v5sXN/5eKEULOip5nfaIWrZa9Fo=; b=iCa9NFQIZR5Js9bpg m22BThyb9jMfdaEqWIS2wLVpICa7unmDeU5djySQnGWYAbIoOeXLiyDpM5QEUjxZ 4RayHmoHFH/8jJfqCH4p4wbcry+aLpVMedQfxywqJFOmgpZivfZ69DZt0jcPDfLI AoAHzHmkosq+Nsw5+J9FBp9V3I= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPA id 0E38D428075; Wed, 20 Nov 2013 12:23:24 -0800 (PST) Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 20 Nov 2013 12:23:25 -0800 Message-ID: <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> Date: Wed, 20 Nov 2013 12:23:25 -0800 From: "Ryan Sleevi" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 20:23:34 -0000 On Tue, November 19, 2013 3:36 pm, Yoav Nir wrote: > > Hm. Interesting predicament. Two thoughts: > > > > If the goal is to allow clients to note and obey the 'strict' directi= ve > > even in the face of a SSL Interception proxy... what you propose won'= t > > work. The proxies will be built to just remove the strict directive, = or > > the header all together. > > > > If the organization running the proxy wanted to block access to the s= ite > > in question, they would do so. If they want to monitor ongoing access= , > > they will strip the directive/header so the clients continue to conne= ct. > > If they are ambivalent - 'access it or not, we don't care, but must > > monitor you if you do' - the stripping feature may or may not be > > enabled. > > > > What you propose would only help in the latter case, it will not > > actually provide more security if the website considers the proxy to = be > > an adversary. And if they add the strict header, I would imagine that > > the website does consider them to be an adversary, or at least that t= hey > > do not wish the connection to succeed.. > > I agree that it does not help security, but it increases the chances o= f > the server policy being enforced. This is not far-fetched. Most TLS > proxies are next-generation firewalls or caching proxies. They won't > remove the strict directive. Of course, snooping proxies will act > differently. > > > So I don't think what you propose is worthwhile, specifically because= it > > does add risk via sites bricking themselves, while not improving > > security considerably. > > > > > > As far as the laptop moving between home and work... I get the > > impression this situation may be regarded as a 'failure' of the > > protocol. That is, we have unintentionally broke something. I disagr= ee. > > I think the situation has worked as desired. > > It's the other way around. The desktop that remains at the office and > keeps ignoring the strict pins is the failure. > > > Because if we replace the players with a rogue government performing = TLS > > MitM, with the specific goal of isolating clients from receiving > > up-to-date security policies... we would declare this same situation = a > > success. > > > > I don't see a way to reconcile the two situations, as they behave alm= ost > > exactly the same. > > > > TLS Proxies add a third player into what was previously a (primarily) > > two-party protocol*. I think the strict directive preserves the > > reasonable property that any one of the three parties can choose not = to > > participate based on the settings of the protocol. > > - The TLS proxy can block access or choose not to intercept > > - The user can not visit the site > > - The site can declare "I don't want anyone else seeing the data I > > consider to be for the user's eyes only" > > So the benevolent TLS proxy should note the "strict" directive and blo= ck > the connection by itself? It makes sense, but that would require an > upgrade of the TLS proxies. Changing client behavior would work with t= he > proxies that are deployed now. > > > I expect that Firefox and Google may even continue to preload entries= in > > their browsers that apply the 'strict' directive specifically to prov= ide > > websites the power to assert their right to a MitM-free connection. I > > know several websites who would like to exercise that right. > > > > What? And have their sites not work in all the places that have newer > firewalls? I doubt it. > > Anyway, I can see how this would allow a buggy proxy to brick the user= s, > so I now agree that this is not worthwhile. > > Yoav > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > Apologies that this discussion has happened due to the editors not having refreshed the draft. As I recall (perhaps incorrectly), our takeaway from IETF 86 was the removal of the 'strict' directive, since the notion of having a remote server provide a directive to override local policy is just escalating a policy arms race. One of the key discussions was had was regarding pinning and how, in current implementations (eg: Chrome), one can only pin to chains that terminate in a 'well-known root'. The 'strict' directive (or its absence) was an attempt to provide some indication that the site accepts being pinned to an internal trust anchor. I recall (and again, perhaps incorrectly), that it was either Eric Rescorla or Jeff Hodges that suggested an implementation change might better accomodate this: 1) If noting pins, and it chains to a well-known trust anchor, local policy (read: potentially MITM enterprise devices) may be able to overrid= e 2) If noting pins, and it does not chain to a well-known trust anchor, effectively note the pins with no override capability (eg: the pins exactly as specified) The goal of this was less about enabling MITM proxies (although they're a= n unfortunate reality and, to at least some, a perceived necessity), and instead finding a way to balance pinning for both "public" sites as well as "internal" sites. From synp71@live.com Wed Nov 20 13:36:49 2013 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 6EBB41AE54B for ; Wed, 20 Nov 2013 13:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DgldGNBuco0a for ; Wed, 20 Nov 2013 13:36:47 -0800 (PST) Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by ietfa.amsl.com (Postfix) with ESMTP id 48CA21AE548 for ; Wed, 20 Nov 2013 13:36:47 -0800 (PST) Received: from BLU0-SMTP150 ([65.55.116.9]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Nov 2013 13:36:40 -0800 X-TMN: [xtrZ5t/uBhdcoJhiSbfZ+DKTCgTECJYp] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([84.109.50.18]) by BLU0-SMTP150.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Nov 2013 13:36:32 -0800 Date: Wed, 20 Nov 2013 23:36:09 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ryan-ietfhasmat@sleevi.com, Yoav Nir References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> In-Reply-To: <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020004020102080901090504" X-OriginalArrivalTime: 20 Nov 2013 21:36:36.0079 (UTC) FILETIME=[96ACD7F0:01CEE638] Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 20 Nov 2013 21:36:49 -0000 --------------ms020004020102080901090504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 20/11/13 10:23 PM, Ryan Sleevi wrote: > On Tue, November 19, 2013 3:36 pm, Yoav Nir wrote: >>> Hm. Interesting predicament. Two thoughts: >>> >>> If the goal is to allow clients to note and obey the 'strict' directi= ve >>> even in the face of a SSL Interception proxy... what you propose won'= t >>> work. The proxies will be built to just remove the strict directive, = or >>> the header all together. >>> >>> If the organization running the proxy wanted to block access to the s= ite >>> in question, they would do so. If they want to monitor ongoing access= , >>> they will strip the directive/header so the clients continue to conne= ct. >>> If they are ambivalent - 'access it or not, we don't care, but must >>> monitor you if you do' - the stripping feature may or may not be >>> enabled. >>> >>> What you propose would only help in the latter case, it will not >>> actually provide more security if the website considers the proxy to = be >>> an adversary. And if they add the strict header, I would imagine that= >>> the website does consider them to be an adversary, or at least that t= hey >>> do not wish the connection to succeed.. >> I agree that it does not help security, but it increases the chances= of >> the server policy being enforced. This is not far-fetched. Most TLS >> proxies are next-generation firewalls or caching proxies. They won't= >> remove the strict directive. Of course, snooping proxies will act >> differently. >> >>> So I don't think what you propose is worthwhile, specifically because= it >>> does add risk via sites bricking themselves, while not improving >>> security considerably. >>> >>> >>> As far as the laptop moving between home and work... I get the >>> impression this situation may be regarded as a 'failure' of the >>> protocol. That is, we have unintentionally broke something. I disagr= ee. >>> I think the situation has worked as desired. >> It's the other way around. The desktop that remains at the office an= d >> keeps ignoring the strict pins is the failure. >> >>> Because if we replace the players with a rogue government performing = TLS >>> MitM, with the specific goal of isolating clients from receiving >>> up-to-date security policies... we would declare this same situation = a >>> success. >>> >>> I don't see a way to reconcile the two situations, as they behave alm= ost >>> exactly the same. >>> >>> TLS Proxies add a third player into what was previously a (primarily)= >>> two-party protocol*. I think the strict directive preserves the >>> reasonable property that any one of the three parties can choose not = to >>> participate based on the settings of the protocol. >>> - The TLS proxy can block access or choose not to intercept >>> - The user can not visit the site >>> - The site can declare "I don't want anyone else seeing the data I >>> consider to be for the user's eyes only" >> So the benevolent TLS proxy should note the "strict" directive and b= lock >> the connection by itself? It makes sense, but that would require an >> upgrade of the TLS proxies. Changing client behavior would work with= the >> proxies that are deployed now. >> >>> I expect that Firefox and Google may even continue to preload entries= in >>> their browsers that apply the 'strict' directive specifically to prov= ide >>> websites the power to assert their right to a MitM-free connection. I= >>> know several websites who would like to exercise that right. >>> >> What? And have their sites not work in all the places that have newe= r >> firewalls? I doubt it. >> >> Anyway, I can see how this would allow a buggy proxy to brick the us= ers, >> so I now agree that this is not worthwhile. >> >> Yoav >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > Apologies that this discussion has happened due to the editors not havi= ng > refreshed the draft. > > As I recall (perhaps incorrectly), our takeaway from IETF 86 was the > removal of the 'strict' directive, since the notion of having a remote > server provide a directive to override local policy is just escalating = a > policy arms race. That was issue #53. It was closed, and there was no consensus to remove=20 'strict'. The only things missing from the draft is the closing of #57-#6= 0. > > One of the key discussions was had was regarding pinning and how, in > current implementations (eg: Chrome), one can only pin to chains that > terminate in a 'well-known root'. The 'strict' directive (or its absenc= e) > was an attempt to provide some indication that the site accepts being > pinned to an internal trust anchor. > > I recall (and again, perhaps incorrectly), that it was either Eric > Rescorla or Jeff Hodges that suggested an implementation change might > better accomodate this: > 1) If noting pins, and it chains to a well-known trust anchor, local > policy (read: potentially MITM enterprise devices) may be able to overr= ide > 2) If noting pins, and it does not chain to a well-known trust anchor, > effectively note the pins with no override capability (eg: the pins > exactly as specified) > > The goal of this was less about enabling MITM proxies (although they're= an > unfortunate reality and, to at least some, a perceived necessity), and > instead finding a way to balance pinning for both "public" sites as wel= l > as "internal" sites. > I'm not sure of the value of pinning internal sites. But regardless, I=20 think the text with the changes agreed upon for the few open issues=20 reflects the consensus of the group or what's left of it (the group, not = the consensus). I think it's time to push this out. Yoav --------------ms020004020102080901090504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMTIwMjEzNjA5WjAjBgkqhkiG9w0BCQQxFgQUkU3D/CY//dFj//m8nwQfcgj9I6YwbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBAFMFkoCXj8Tz25lUUzdjykkPQYMO9QWeCQG/W1wZK/UReJGq gVj0XX2YJ1g1y05Ap2PH0TfJWEra8Lmk0UuQYUH9WKDFnNU/zOZzEsenO+dZ2gh15jbrXHrM LJ9n7UazYJJSBCNLG8D5RccCd+au8/nIOqg5LQ8LQf42dln2KgXpeKsZCa7oz2tVmxeKW7K/ zh8TMk3ldbMLOgLLI9ZVeo9E1r+kt+kebhkjMHze/VBNNfnXe1wNx5IqtOd+T5GOodMqCP/h jvrJG7/PYSXTXeKMKRUdQG/Umw43wcveuUHcrhpNPbHCeQf7n7vwWcgHysJvy5VOWCVXnQgN 7HJg+BwAAAAAAAA= --------------ms020004020102080901090504-- From ietf-secretariat-reply@ietf.org Wed Nov 20 13:45:59 2013 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 2F2DC1AE544 for ; Wed, 20 Nov 2013 13:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQw5DR36I5I4 for ; Wed, 20 Nov 2013 13:45:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F38251AE561 for ; Wed, 20 Nov 2013 13:45:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: websec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131120214556.8995.21002.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 13:45:56 -0800 From: IETF Secretariat X-Mailman-Approved-At: Fri, 22 Nov 2013 13:44:03 -0800 Subject: [websec] Milestones changed for websec WG 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, 20 Nov 2013 21:45:59 -0000 Changed milestone "Submit 'X-Frame-Options' to the IESG for consideration as a Informational Track RFC.", resolved as "Done". Changed milestone "Adopt 'HTTP Application Security Problem Statement and Requirements' as initial WG item.", resolved as "Done". URL: http://datatracker.ietf.org/wg/websec/charter/ From trac+websec@trac.tools.ietf.org Mon Nov 25 17:19:53 2013 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 524A71AE0EF for ; Mon, 25 Nov 2013 17:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-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 hRMXWb7J-qCZ for ; Mon, 25 Nov 2013 17:19:51 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 94E101AE0E1 for ; Mon, 25 Nov 2013 17:19:51 -0800 (PST) Received: from localhost ([127.0.0.1]:42369 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vl7Jf-0002xH-0M; Tue, 26 Nov 2013 02:19:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "websec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: palmer@google.com X-Trac-Project: websec Date: Tue, 26 Nov 2013 01:19:50 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/websec/trac/ticket/57#comment:3 Message-ID: <073.a3f9220c05900098469bec6668dc2546@trac.tools.ietf.org> References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #57: Re-add an upper limit to max-age 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: Tue, 26 Nov 2013 01:19:53 -0000 #57: Re-add an upper limit to max-age Changes (by palmer@google.com): * status: new => closed * resolution: => fixed Comment: The new language satisfies the rough consensus in the WG. -- --------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+-------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Nov 25 17:27:16 2013 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 081F61AE0E1 for ; Mon, 25 Nov 2013 17:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Ce5rF0toOuVM for ; Mon, 25 Nov 2013 17:27:14 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 977D21AE032 for ; Mon, 25 Nov 2013 17:27:14 -0800 (PST) Received: from localhost ([127.0.0.1]:43327 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vl7Qo-0004sW-4j; Tue, 26 Nov 2013 02:27:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "websec issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: palmer@google.com X-Trac-Project: websec Date: Tue, 26 Nov 2013 01:27:14 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/websec/trac/ticket/54#comment:2 Message-ID: <073.fdae55eace0ff306b7c34c2d5575843c@trac.tools.ietf.org> References: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #54: Specify a report-only mode 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: Tue, 26 Nov 2013 01:27:16 -0000 #54: Specify a report-only mode Changes (by palmer@google.com): * status: assigned => closed * resolution: => fixed Comment: Draft -08 specifies a report-uri directive and a JSON format to be POSTed to the given URI. -- -------------------------------+-------------------------------- Reporter: palmer@google.com | Owner: palmer@google.com Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------- Ticket URL: websec From palmer@google.com Mon Nov 25 19:41:04 2013 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 CCAB41ADFC6 for ; Mon, 25 Nov 2013 19:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 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.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 ADEMN8sq9mbl for ; Mon, 25 Nov 2013 19:41:03 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBD61ADFC3 for ; Mon, 25 Nov 2013 19:41:02 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so8123678iej.40 for ; Mon, 25 Nov 2013 19:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/TK/VWh+PgMtMcdDO9VfuM045FwpQDDG8bcKL4Xw4w4=; b=S6EEMGX5jALlAahSm8EuGocYajWisfTbpduqALjgvplKBq+Fzj6kmlJpxqxrGnYHO5 vnEl5oG0Htr7nSeF4ZtU1NkjVhXojrUvzffZE67bWK9a2Phq52BqUBa7opzLiIO8uYSy HH2WHrPDJt/MhMakDq/lnDUfOLkflrNXEt6hXPm5sr1jYegtDGPf7/4ch/HDzITydmWG qe//jM53jCHFLaV5fFqfByLg2cQqkGEBTMVG/sQmpWEU8uzdrKK8XRY7HTmL5ME6aFzG tmfjZLGB3i6KWwQUJsUjYnotp0il+pWxSX7rztj6H6tthL5l9Wb39NjuGvR4c27j17J/ 5v2w== 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 :content-transfer-encoding; bh=/TK/VWh+PgMtMcdDO9VfuM045FwpQDDG8bcKL4Xw4w4=; b=mM+gpZVf0M5Je7fsSyb94hd/u7E2KLEgHpEzLEuelqKRGeQ3mfvc/F9l1i2S/nUtEh eUBKVrRKWw9FKwo3JgbFX8awnykAc5LoK2wPJjEiL6ZlJGS9/3qwxdbVEniH+50THwzH GrPQIgbThPtxzuD+z5de+GJu0/7pjAre5OYQAP6+qXzdqn85/Xh3IrPcgrT4bfdsggZ+ KfrSQVqMle1AKmdV/5yX/G00WF2sGSs/m8dAWEOIatoBN+dVGs9zHLbnQv2rN/PoLcoC rYuB5s5c4AkhGxZJCMeLYJqBuA+q4Bvr9W7TqMtSOKwCm3NfazHwHvPbb11iPoBa6t/+ MT1A== X-Gm-Message-State: ALoCoQntY/es0GkKK1C1+t6CEgLayuPfcwaGt5xNNDpGPlMHXAX5SIdi44xX4q9xeM/3FJ06ke/RIMIi7Lsaev8UgOi3PEpE6Wdj+HosGKtL4xnZf5+PafFoZofZX9uV+3SWZeNByqnf/iXEmUbY943BAFgWa0qCRe3rz3Aq06Y8672xfupG1q4yppIGl5pwo/7AA1XRC/Nm MIME-Version: 1.0 X-Received: by 10.50.16.45 with SMTP id c13mr15131008igd.55.1385437262666; Mon, 25 Nov 2013 19:41:02 -0800 (PST) Received: by 10.64.81.70 with HTTP; Mon, 25 Nov 2013 19:41:02 -0800 (PST) In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Mon, 25 Nov 2013 19:41:02 -0800 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 26 Nov 2013 03:41:05 -0000 On Wed, Nov 20, 2013 at 1:36 PM, Yoav Nir wrote: >> As I recall (perhaps incorrectly), our takeaway from IETF 86 was the >> removal of the 'strict' directive, since the notion of having a remote >> server provide a directive to override local policy is just escalating a >> policy arms race. > > That was issue #53. It was closed, and there was no consensus to remove > 'strict'. The only things missing from the draft is the closing of #57-#6= 0. Issue 53 (http://tools.ietf.org/wg/websec/trac/ticket/53) was not quite about the policy arms race. The policy arms race between public web site www.example.com and a given client's filtering TLS proxy is over: if the client legitimately trusts the TLS proxy (e.g. the TLS proxy's trust anchor is installed in the client's trust anchor store), then www.example.com cannot enforce its policy on the client; in effect, the proxy is the true client. On the other hand, if the client does *not* trust the TLS proxy, then the proxy will be "caught" either by pinning or by the usual "The server presented a certificate your operating system does not trust" warning screen. So I don't think it is possible or sane to promise to site operators that they can deny MITM powers to MITMs that the client trusts. As I (think we) intended it, strict was to mean "bypass the local policy of not applying pinning to chains that chain to local trust anchors" =E2=80=94 i.e. as a way of allowing sites that install their own trust anchors on machines to also pin the keys of the servers that the local trust anchor signs. This would be for enterprises that want to have their own PKI and also strictly enforce it (to ensure that, e.g., internal.example.com never chains to a public anchor). The utility of this is debatable (but, I would argue, more than 0... potentially). There is a new draft -09 in our Git repo at https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-websec= -key-pinning.xml. Any thoughts before I actually put it in the IETF tracker as the real -09? From synp71@live.com Tue Nov 26 00:14:11 2013 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 6F1131AC7F1 for ; Tue, 26 Nov 2013 00:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4_4gI9r16zRU for ; Tue, 26 Nov 2013 00:14:09 -0800 (PST) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by ietfa.amsl.com (Postfix) with ESMTP id EACD31AC499 for ; Tue, 26 Nov 2013 00:14:08 -0800 (PST) Received: from BLU0-SMTP199 ([65.55.116.7]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Nov 2013 00:14:08 -0800 X-TMN: [BWQE9QpSbOyloZnXin0Y6LG5Rd1rFfxx] X-Originating-Email: [synp71@live.com] Message-ID: Received: from ynir-MBA.local ([194.29.32.131]) by BLU0-SMTP199.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Nov 2013 00:14:06 -0800 Date: Tue, 26 Nov 2013 10:14:06 +0200 From: Yoav Nir User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Chris Palmer , IETF WebSec WG References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000807070201040001050708" X-OriginalArrivalTime: 26 Nov 2013 08:14:07.0042 (UTC) FILETIME=[7A175A20:01CEEA7F] Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 26 Nov 2013 08:14:11 -0000 --------------ms000807070201040001050708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 26/11/13 5:41 AM, Chris Palmer wrote: > On Wed, Nov 20, 2013 at 1:36 PM, Yoav Nir wrote: > >>> As I recall (perhaps incorrectly), our takeaway from IETF 86 was the >>> removal of the 'strict' directive, since the notion of having a remot= e >>> server provide a directive to override local policy is just escalatin= g a >>> policy arms race. >> That was issue #53. It was closed, and there was no consensus to remov= e >> 'strict'. The only things missing from the draft is the closing of #57= -#60. > Issue 53 (http://tools.ietf.org/wg/websec/trac/ticket/53) was not > quite about the policy arms race. > > The policy arms race between public web site www.example.com and a > given client's filtering TLS proxy is over: if the client legitimately > trusts the TLS proxy (e.g. the TLS proxy's trust anchor is installed > in the client's trust anchor store), then www.example.com cannot > enforce its policy on the client; in effect, the proxy is the true > client. On the other hand, if the client does *not* trust the TLS > proxy, then the proxy will be "caught" either by pinning or by the > usual "The server presented a certificate your operating system does > not trust" warning screen. So I don't think it is possible or sane to > promise to site operators that they can deny MITM powers to MITMs that > the client trusts. > > As I (think we) intended it, strict was to mean "bypass the local > policy of not applying pinning to chains that chain to local trust > anchors" =E2=80=94 i.e. as a way of allowing sites that install their o= wn > trust anchors on machines to also pin the keys of the servers that the > local trust anchor signs. This would be for enterprises that want to > have their own PKI and also strictly enforce it (to ensure that, e.g., > internal.example.com never chains to a public anchor). The utility of > this is debatable (but, I would argue, more than 0... potentially). > > There is a new draft -09 in our Git repo at > https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-we= bsec-key-pinning.xml. > Any thoughts before I actually put it in the IETF tracker as the real > -09? Thanks, Chris. To summarize, although there has been much discussion since version -06, = most of it did not result in massive changes to the document, so IMO we=20 don't need another WGLC. If anyone feels differently, please let me know = by the end of this week. Pasted below is the privacy considerations section, which is new to this = version. There is one thing that I think needs fixing before submitting: the IANA = considerations section. It says that this document has no actions for=20 IANA. This is wrong. IANA keeps the registry for HTTP (among other=20 things) headers: http://www.iana.org/assignments/message-headers/message-headers.xhtml So it should be something like 6. IANA Considerations IANA is requested to register the header described in this document in=20 the "Message Headers" registry, with the following parameters: o Header Field Name should be "Public-Key-Pins" o Protocol should be "http" o Status should be "standard" o Reference should be this document Thanks, Yoav Here's a paste of the new section 5: 5. Privacy Considerations Conforming implementations (as well as implementations conforming to [RFC6797]) must store state about which domains have set policies, hence which domains the UA has contacted. A forensic attacker might find this information useful, even if the user has cleared other parts of the UA's state. More importantly, 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. Here are two attack scenarios. 1. example.com can use report-uri and the ability to pin arbitrary identifiers to distinguish UAs. 2. 1. example.com sets a Valid Pinning Header in its response to requests. The header asserts the includeSubDomains directive, and specifies a report-uri directive as well. Pages served by the host also include references to subresource https://bad.example.com/foo.png. 2. The Valid Pinning Header includes a "pin" that is not really the hash of an SPKI, but is instead an arbitrary distinguishing string sent only in response to a particular request. For each request, the Host creates a new, distinct distinguishing string and sets it as if it were a pin. 3. The certificate chain served by bad.example.com does not pass= Pin Validation given the pin set the Host asserted in (1). The HPKP-conforming UA attempts to report the Pin Validation failure to the specified report-uri, including the certificate chain it observed and the SPKI hashes it expected= to see. Among the SPKI hashes is the distinguishing string in step (2). 3. example.com can use SNI and subdomains to distinguish UAs. 4. 1. example.com sets a Valid Pinning Header in its response to requests. The header asserts the includeSubDomains directive. 2. On a subsequent page view, the Host responds with a page including the subresource https://0.fingerprint.example.com/ foo.png, and the server responds using a certificate chain that does not pass Pin Validation for the pin-set defined in the Valid Pinning Header in step (1). The HPKP-conforming UA= will close the connection, never completing the request to 0.fingerprint.example.com. The Host may thus note that this particular UA had noted the (good) pins for that subdomain. 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). --------------ms000807070201040001050708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5 lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1 G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA 8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD 8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU 0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3 MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55 m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTMxMTI2MDgxNDA2WjAjBgkqhkiG9w0BCQQxFgQUlBZsMZXG2x5eBTI9OHy+pSq7MIowbAYJ KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6 MA0GCSqGSIb3DQEBAQUABIIBADcxqqwcj3sf17hV7f5UGf7KCaAscrTV/6yZy4vFKc+DDQWS 8p3Qhf/wnC9rrn/mipflXctbsh2zNI1H7/ujDT7mzXVDtEQ7imjwBN0EFwiMn4zmKA6awMfS ++0TYOONAfrZvS0R56Y4o59tUz/mClgc5pwPpHLDP3o908djiu4e0zgaZFtWCbrEyibWr0Zx mSHt0cnf4zJCG3AlDHMSpS3AmsZwGtaSxhy+Gsz7cakj/JBHL0UNAYFDh793GUABZXhea02D Rs4VzhZH2siXPQQCPXukVp/DU4lnI/UoQ422p/Srzsy79oJsHUOCHAgl6gfOzTzSE5MCU5Gn QxhlDfwAAAAAAAA= --------------ms000807070201040001050708-- From palmer@google.com Tue Nov 26 15:38:45 2013 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 288FB1AE08F for ; Tue, 26 Nov 2013 15:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 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.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 7w3lrg73k1Un for ; Tue, 26 Nov 2013 15:38:44 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D47DF1AE045 for ; Tue, 26 Nov 2013 15:38:43 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so10190228iec.7 for ; Tue, 26 Nov 2013 15:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QBlKrlW84TD9Fjb2UaLSUfh/oqwLxXt7GdOf+pa0lQE=; b=eLXJXnJSFtHtKUBXlSvqwxPuI/7Gn1okYrOYP4gROU8nVXfdPtZO2qP4rKDmsciJ9F LAGGrBpWppuiMyH5b88xEnGzuXv/yNuodL5h1leOPjCGa6/PmEp/5HO/TiPuUJEHncdC 6vnWwieqJRH9t2etg5ipNdV87Mcfgp0l3qHGYrzP4NoJAL1MPm8k6urVs7AvaU+ivs8h G3tfAMtUK/R1mVjpbqTaePQEc5EqtI0eBARITBvU+1sfowZtBoaXYhEBo4/6SYJUR0dX e3P8RGJ63mUOZ2mawfmztDB0s69ErLRwAZAfWeLNhUMGrKbwnlkJg6w9tzD1ecmL+l2g Vsjg== 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=QBlKrlW84TD9Fjb2UaLSUfh/oqwLxXt7GdOf+pa0lQE=; b=JAA7oEOru5AwEV786paNFQbXWdRcLI2urVkznXwIw7PdiX1hxC/RELWVcdOwPyoTuN Kf37fgm2ZxRwqujGrApCumGOvdn/BBLNwrg15+IL9cjh2b7eiuDTADfkGBKe7Fo3vY+Y a5uUSRnd8GZ/TRGBDZR7fsXNvaz64zKCGVVPAqp+QttLARMn1zV72o0rvBz/pvaTMEwk BbHvOGH95zGiNKhHbRQyjLiRwAE50wm8nYPkvtnC46JgTmNvCuZLjCg+GNAHjC7MaE9/ u+y6jijTbOkYKWgqOa7V/nfR49kkzF3vWOuzCJGFBENPn4nM9+LvWoypepFKmOJu0HVU MAcA== X-Gm-Message-State: ALoCoQlYcHzltPWiDv0LZ2hXMs0vKLv06N4mIo+NDytMhLr30RYr7cAs6qadk+8E4Sji/pM+BNmheMXcFOx2QvHEa3EOgzy6ni+1YFOCFfV5a091qq8Ux7vLBjt6grvSLlmuJb3kqveUmgyd1pr3Gef/+8whR6nauBniZi42e3HkuvmtQA3VVYU19pefkDiudcXTjD1amHJs MIME-Version: 1.0 X-Received: by 10.43.151.12 with SMTP id kq12mr3355457icc.55.1385509123556; Tue, 26 Nov 2013 15:38:43 -0800 (PST) Received: by 10.64.81.70 with HTTP; Tue, 26 Nov 2013 15:38:43 -0800 (PST) In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Tue, 26 Nov 2013 15:38:43 -0800 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 26 Nov 2013 23:38:45 -0000 On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir wrote: > There is one thing that I think needs fixing before submitting: the IANA > considerations section. It says that this document has no actions for IANA. > This is wrong. IANA keeps the registry for HTTP (among other things) > headers: > http://www.iana.org/assignments/message-headers/message-headers.xhtml > > So it should be something like > > 6. IANA Considerations > > IANA is requested to register the header described in this document in the > "Message Headers" registry, with the following parameters: > o Header Field Name should be "Public-Key-Pins" > o Protocol should be "http" > o Status should be "standard" > o Reference should be this document OK, I set it to this. Thanks! From internet-drafts@ietf.org Tue Nov 26 15:38:53 2013 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 EC81C1AE075; Tue, 26 Nov 2013 15:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhmfYfVikP_T; Tue, 26 Nov 2013 15:38:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B358F1AE0A4; Tue, 26 Nov 2013 15:38:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131126233850.6712.94809.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 15:38:50 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-09.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: Tue, 26 Nov 2013 23:38:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Ryan Sleevi Filename : draft-ietf-websec-key-pinning-09.txt Pages : 23 Date : 2013-11-26 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) 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. 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-09 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 trevp@trevp.net Fri Nov 29 12:25:03 2013 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 18A7A1ADFBD for ; Fri, 29 Nov 2013 12:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 38VQob-n9O1r for ; Fri, 29 Nov 2013 12:25:01 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id C53151ADBCA for ; Fri, 29 Nov 2013 12:25:00 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x13so9751338wgg.31 for ; Fri, 29 Nov 2013 12:24:59 -0800 (PST) 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=23RtCpAS1hnMwRn7hjyhfnr8T9W6fde0jAOId9jKXE8=; b=MEd2nfBTa9vFlM7BDqCRrgrbx1l5RfQdieOMsUPPNuLWHyVNlfrPwTC8VVjCVbAL90 pEfIjMCZkBES6xw3CDpia6+Rs2eq2pDpSuihsHfR/TXPBP1PJIb8xcBsHvnr87QSBvrZ A/F4pl525wqeQHlg5rzjhzg59Eh8KN4yFqeD5WmQoMmyEQHnXvkxXDE027EnjKbbMps5 tijGvG2oYYeC9i/D3yO044IxqYCukYVQKKDW8u7pTiY1xW1cUqfocmm5U9kYv1Ti2+iK Zh5zDltGuV7hb/Cfcj32BIHoAdX/saklibw6yMo8kTSeW6XOChSps2dLwFCsv8If/AuJ ilQw== X-Gm-Message-State: ALoCoQk4GIJ150OGMAnXb2BukBTG1zm1aJPT1DFm05crc/vZp0iWtkgGM4tolkev2Q6V2bnHPISp MIME-Version: 1.0 X-Received: by 10.180.7.136 with SMTP id j8mr8269023wia.17.1385756698924; Fri, 29 Nov 2013 12:24:58 -0800 (PST) Received: by 10.216.214.134 with HTTP; Fri, 29 Nov 2013 12:24:58 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Fri, 29 Nov 2013 12:24:58 -0800 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 29 Nov 2013 20:25:03 -0000 On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir wrote: > > To summarize, although there has been much discussion since version -06, > most of it did not result in massive changes to the document, so IMO we > don't need another WGLC. * Weren't we going to discuss the relationship of preloaded to dynamic pins? See email [1]. * The rationale in thread [2] for "strict" seems different from the rationale in previous list discussions [3]. Ryan now argues that "strict" is not needed. I think that's worth considering. * I had feedback on an earlier draft which is still relevant [4], see below. [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html [4] http://www.ietf.org/mail-archive/web/websec/current/msg01692.html FEEDBACK ON DRAFT-07, STILL RELEVANT ==== * Interaction with cookies needs discussion. Cookie scoping rules pose a serious problem for pinning, e.g. a pin at "example.com" could be undermined by a MITM inventing a "badguy.example.com" and using it to steal or force cookies. * Why is there a "Public-Key-Pins-Report-Only" header instead of a "report-only" directive? Most of the document is written as if there was a single "PKP header field", so a directive would make more sense. * In draft-05, client processing was changed from noting a single "expiry" value to noting two values: "Effective Pin Date" and "max-age". The previous approach was simpler, stored less data, and was more aligned with HSTS. * Section 2.3.1 fails to update the Effective Date of a noted pin when it is noted again. * Section 2.6 mandates "When a UA connects to a Pinned Host, if the TLS connection has errors, the UA MUST terminate the connection without allowing the user to proceed". HSTS allows the server to specify this, so it seems unnecessary and inflexible to mandate it here. It's also unclear whether a "report-only" pin counts as a "Pinned Host". * UA processing rules are confusingly spread across the document. For example, 2.3.1 and 2.5 describe the same process so should be combined. * Section 2.5 - Does a failed validation of a "report-only" pin count as an "error" that will inhibit noting of new pins in the connection? * Specified UA behavior with multiple header fields is contradictory: - 2.1.3: "If a Host sets both the Public-Key-Pins header and the Public-Key- Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and MUST note only the pins and directives given in the Public-Key-Pins- Report-Only header." - 2.3.1: "If a UA receives more than one PKP header field in an HTTP response message over secure transport, then the UA MUST process only the first such header field." * Section 3 - Should the failure report contain the certificates sent by the server, as well as the validated chain? Could help debugging and attack analysis. * Why is SHA1 supported? If the reason is size, why not remove it but allow the server to pin to a truncated hash (e.g. pin to the first 16 or 20 bytes of SHA256) * Should there be a list of "excluded" keys that must not appear in the "validated certificate chain"? Chrome's preloaded pinning supports this, apparently to exclude 3rd-party subCAs that might have been issued under a pinned CA. * Would it be better to use the term "pin" for the entire record associating (hostname, HPKP data), instead of calling each individual hash a "pin"? The hostname is "pinned" to the 1-of-n key set as a whole, not each key individually. * Should the header name be changed once this draft stabilizes, to ensure no bad interactions with UAs that implemented earlier drafts? Minor: * "Pinning Policy" and "Pinning Metadata" are synonyms? * 2.3.1 ... "or," ... "Otherwise" is confusing * 2.3.2 - are clients expected to store directives they don't understand? * 2.6 - is pin validation performed on resumed TLS connections? * 3 - can UAs provide additional JSON fields inside the report? * The term "validated certificate chain" is not defined * An IANA registry is needed for directives * The acknowledgement for "pin break codes" is ancient/irrelevant Trevor From tom@ritter.vg Fri Nov 29 14:16:20 2013 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 4D75C1AE209 for ; Fri, 29 Nov 2013 14:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 pwAx3a2ytHiZ for ; Fri, 29 Nov 2013 14:16:19 -0800 (PST) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3083F1ADF27 for ; Fri, 29 Nov 2013 14:16:19 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so15137279pbb.31 for ; Fri, 29 Nov 2013 14:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=djjsLruQAVsPsLKpNNPZaI3rzrCRq0J8+89bmxWvWdo=; b=eckbu6HY6XVV6wvTmyveiIsYu5A5KywKrPovhWoPEDeKdny9DCtW04IgLDcfCvbomZ TsjJWjLaYeMyLknDP2FEF8WFqGc+qFBiyNVJZ0ne2XiiFrcBXYRMOA7sDS+mr0znfiWL GXmTcK870wc5tR0njveFL9iSSAxZnX64LdTuQ= 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:from:date :message-id:subject:to:cc:content-type; bh=djjsLruQAVsPsLKpNNPZaI3rzrCRq0J8+89bmxWvWdo=; b=YSD5yFHi4DZxZjXze4tXNGhspg/hRdxS8NwiL5w/POb/g8fnBkNdKvsJYZA/yjy1FK oJ5wNU+YkOFWAurxl+GOpz5mKGdgEPYVpi0e2tM58Q/o3PNMhXwFERp1mWcEaheYWSCN pjegenfp3ev8acJfgqWbOQesmGsiNHQcZGbGM9KErK+P/aB1T4IPBgjuFaT+3i92tDTm mr6Jbu0ERjclmPnu7hfDAnChkNUWqLtqHvjaWt8IbN99FGAfzudS0Qa/tOZVD0BwEPqU S8Sr7w04DTVB0JLm7nzDRZaeGDvJogsRzbLxlE35g9lunCyogNXNwyuls9eJa/dYMF4V Pgqg== X-Gm-Message-State: ALoCoQmP5PQBr6GUM7Hl9JSWGiCG52EElv43CwCmYOIsmvawMkMTRcxXd/qow+JGap4DmpWXexXt X-Received: by 10.68.173.132 with SMTP id bk4mr5554749pbc.169.1385763377634; Fri, 29 Nov 2013 14:16:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.169.193 with HTTP; Fri, 29 Nov 2013 14:15:57 -0800 (PST) In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> From: Tom Ritter Date: Fri, 29 Nov 2013 17:15:57 -0500 Message-ID: To: Trevor Perrin Content-Type: multipart/alternative; boundary=047d7b6d9b16ddf80e04ec582d7b Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 29 Nov 2013 22:16:20 -0000 --047d7b6d9b16ddf80e04ec582d7b Content-Type: text/plain; charset=ISO-8859-1 On 29 November 2013 15:24, Trevor Perrin wrote: > * Why is there a "Public-Key-Pins-Report-Only" header instead of a > "report-only" directive? Most of the document is written as if there > was a single "PKP header field", so a directive would make more sense. > If it becomes a directive, we should be sure that we can still apply two headers, one more loose in enforcing mode, one stricter in report only mode. -tom --047d7b6d9b16ddf80e04ec582d7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 2= 9 November 2013 15:24, Trevor Perrin <trevp@trevp.net> wrote:<= br>
=A0* Why is there a &= quot;Public-Key-Pins-Report-Only" header instead of a
"report-only" directive? =A0Most of the document is written as if= there
was a single "PKP header field", so a directive would make more s= ense.

If it becomes a directive, we sho= uld be sure that we can still apply two headers, one more loose in enforcin= g mode, one stricter in report only mode. =A0

-tom
--047d7b6d9b16ddf80e04ec582d7b-- From trevp@trevp.net Fri Nov 29 14:39:14 2013 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 7B7D71AE01D for ; Fri, 29 Nov 2013 14:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 3ZPvQChQRCtQ for ; Fri, 29 Nov 2013 14:39:13 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id D4B8A1AE00F for ; Fri, 29 Nov 2013 14:39:12 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hq4so2609495wib.8 for ; Fri, 29 Nov 2013 14:39:11 -0800 (PST) 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=j2SFUK5bL/Jc1yQZhFx3xRdeelGZDx0NwMJQiI5ekb4=; b=C/QrxPQ7MfYEFE047tWIBx/1+32og8OLkUlrxpY+0sbZD1eQVGjt1Vm6g1K4YWexT3 A6Xg6ep0Q1RzYiUcOgx9d5cyVmBMNQvA8LfqQfs0n3nsjY4sZnpvR45if4cwWMXgt4wz bbq0Gisva4Z+Y8yxpcktsuCEGPBuS1XV4aqvwamdw/h/PwoRPUXrOQDDvSYuEX9NEpcf SF79gt5OV+rEbKOV1/xlYW9y2xcAfnic7j56OnsKq9fXhYk2amgAtE+nkvrxjh7NRquP Yrp9Q7ImDXWX2+1mUHm6/rGH0DjuruD/cR6UIb9j7foLDkYfpA6xHhskeNT5HlHmAgb+ CXcA== X-Gm-Message-State: ALoCoQmGtO4mPcPKAdRQnR4t7OQZtmtXmb5RnkVbPcBmVENt2ZpYzNXKOg7+JKaw6W9UISp2+igv MIME-Version: 1.0 X-Received: by 10.194.21.131 with SMTP id v3mr22747409wje.44.1385764751053; Fri, 29 Nov 2013 14:39:11 -0800 (PST) Received: by 10.216.214.134 with HTTP; Fri, 29 Nov 2013 14:39:10 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Fri, 29 Nov 2013 14:39:10 -0800 Message-ID: From: Trevor Perrin To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 29 Nov 2013 22:39:14 -0000 On Fri, Nov 29, 2013 at 2:15 PM, Tom Ritter wrote: > On 29 November 2013 15:24, Trevor Perrin wrote: >> >> * Why is there a "Public-Key-Pins-Report-Only" header instead of a >> "report-only" directive? Most of the document is written as if there >> was a single "PKP header field", so a directive would make more sense. > > > If it becomes a directive, we should be sure that we can still apply two > headers, one more loose in enforcing mode, one stricter in report only mode. Would you expect both headers to be noted? The current spec doesn't support that. It specifies 2 different (and incompatible) ways of handling this case: - 2.1.3: "If a Host sets both the Public-Key-Pins header and the Public-Key- Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and MUST note only the pins and directives given in the Public-Key-Pins- Report-Only header." - 2.3.1: "If a UA receives more than one PKP header field in an HTTP response message over secure transport, then the UA MUST process only the first such header field." Trevor From tom@ritter.vg Fri Nov 29 14:51:06 2013 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 CDA8A1AE04D for ; Fri, 29 Nov 2013 14:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 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, 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 zqiLMF6IQiBZ for ; Fri, 29 Nov 2013 14:51:05 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 86B7C1AE00F for ; Fri, 29 Nov 2013 14:51:05 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so15266446pbc.27 for ; Fri, 29 Nov 2013 14:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=os2PoOfwc3zry8gTzd+gPe2gupGKpIVDcELhkBWRoUw=; b=QFIMMogiwqDvOyRRi5snobdfX7BcXNQfBoAABH36vYG96uOU3mIK9QPQvxBWmtDOsq mbE49rD3Y8vhYTDhnFcouM50/rGNKfC3weHQdIOk9NNVlKFBKJBxQNZPDvtTUFrcJoDU kiSLZv1aQbjBJwwMZKpSWrz4tGgA0V8mV4tuQ= 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:from:date :message-id:subject:to:cc:content-type; bh=os2PoOfwc3zry8gTzd+gPe2gupGKpIVDcELhkBWRoUw=; b=Dlyw15YuOMIp5ct7E8w7Faf0kfefk6twx28y/+fDZTXI04ap7NFlFqpcRQCAHsVLir KaSMcbjfVELv3+JJRG7n/Nkw5ijbo2MSIzFlLOwo4cOi/OtpAQftwsj+HWJ3nB06OTuc m4nEnz/isAg1pRUIP0lVZ7B1wbBcXkZEGqNnUAAyK+kYibPtM9wXdgCv6zOzEvauC7kx 4t/wX5KmFIdzSXFKjS4ftUKlSjcCXYxzSg+58b0bTtrVL9+ociLxOW/jZbv69vvM9ZaU iuKgOxFaih1QW+RfddyZgjm3qpnvBuWcSDeUXzAY+xXoMEDlZXvKlsHtPQ2cwoI/pTlQ o2Ww== X-Gm-Message-State: ALoCoQmaCeONKOVDnTg+fQwpAB+UiiIINGoTWD6rlXJa3hVp0gIhVX1J5kQWiPsP62DH2y7K9bnV X-Received: by 10.66.158.99 with SMTP id wt3mr34442836pab.113.1385765464300; Fri, 29 Nov 2013 14:51:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.169.193 with HTTP; Fri, 29 Nov 2013 14:50:43 -0800 (PST) In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> From: Tom Ritter Date: Fri, 29 Nov 2013 17:50:43 -0500 Message-ID: To: Trevor Perrin Content-Type: multipart/alternative; boundary=047d7bacbf023df9d704ec58aa05 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 29 Nov 2013 22:51:07 -0000 --047d7bacbf023df9d704ec58aa05 Content-Type: text/plain; charset=ISO-8859-1 On 29 November 2013 17:39, Trevor Perrin wrote: > On Fri, Nov 29, 2013 at 2:15 PM, Tom Ritter wrote: > > On 29 November 2013 15:24, Trevor Perrin wrote: > >> > >> * Why is there a "Public-Key-Pins-Report-Only" header instead of a > >> "report-only" directive? Most of the document is written as if there > >> was a single "PKP header field", so a directive would make more sense. > > > > > > If it becomes a directive, we should be sure that we can still apply two > > headers, one more loose in enforcing mode, one stricter in report only > mode. > > Would you expect both headers to be noted? > > The current spec doesn't support that. It specifies 2 different (and > incompatible) ways of handling this case: > > - 2.1.3: "If a Host sets both the Public-Key-Pins header and the > Public-Key- > Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and > MUST note only the pins and directives given in the Public-Key-Pins- > Report-Only header." > > - 2.3.1: "If a UA receives more than one PKP header field in an HTTP > response message over secure transport, then the UA MUST > process only the first such header field." > Oh yea. Heh. Why is that? CSP supports an enforcing header and a reporting header, and both of them are applied simultaneously. I would expect the same from HPKP. -tom --047d7bacbf023df9d704ec58aa05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 2= 9 November 2013 17:39, Trevor Perrin <trevp@trevp.net> wrote:<= br>
On Fri, Nov 29, 2013 at 2:15 PM, To= m Ritter <tom@ritter.vg> wrote:<= br> > On 29 November 2013 15:24, Trevor Perrin <trevp@trevp.net> wrote:
>>
>> =A0* Why is there a "Public-Key-Pins-Report-Only" header= instead of a
>> "report-only" directive? =A0Most of the document is writ= ten as if there
>> was a single "PKP header field", so a directive would ma= ke more sense.
>
>
> If it becomes a directive, we should be sure that we can still apply t= wo
> headers, one more loose in enforcing mode, one stricter in report only= mode.

Would you expect both headers to be noted?

The current spec doesn't support that. =A0It specifies 2 different (and=
incompatible) ways of handling this case:

=A0- 2.1.3: "If a Host sets both the Public-Key-Pins header and the Pu= blic-Key-
=A0 =A0 Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, an= d
=A0 =A0 MUST note only the pins and directives given in the Public-Key-Pins= -
=A0 =A0 Report-Only header."

=A0- 2.3.1: "If a UA receives more than one PKP header field in an HTT= P
=A0 =A0 response message over secure transport, then the UA MUST
=A0 =A0 process only the first such header field."


Oh yea. Heh. =A0Why is that? = =A0CSP supports an enforcing header and a reporting header, and both of the= m are applied simultaneously. I would expect the same from HPKP.

-tom
--047d7bacbf023df9d704ec58aa05-- From ryan-ietfhasmat@sleevi.com Fri Nov 29 15:57:04 2013 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 73A0F1AE0E1 for ; Fri, 29 Nov 2013 15:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 ayfFKrXwDhPG for ; Fri, 29 Nov 2013 15:57:03 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id F1D281ADFC8 for ; Fri, 29 Nov 2013 15:57:02 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 8315FBC033; Fri, 29 Nov 2013 15:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=7WtpWzCmVyzSeN4qIiOrvYKKW10=; b=SE80if3oafdv9s1gw PfaUoSSt8pJftfbKHBEKJB3AzLisk4ASErX8/pp8hZH9HPAcapNfg/braG8RJ4D3 hn3MtLbP3HPv908LbRrWsz83r3Q8O9TaSKNgrqfW3sIdqt1eijKkTaVdu9c5ec77 VAj2rmDwj5cBXU6Fhj10EDNbwA= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 3F3CDBC031; Fri, 29 Nov 2013 15:57:01 -0800 (PST) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 29 Nov 2013 15:57:01 -0800 Message-ID: In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Fri, 29 Nov 2013 15:57:01 -0800 From: "Ryan Sleevi" To: "Tom Ritter" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 23:57:04 -0000 On Fri, November 29, 2013 2:50 pm, Tom Ritter wrote: > On 29 November 2013 17:39, Trevor Perrin wrote: > > > On Fri, Nov 29, 2013 at 2:15 PM, Tom Ritter wrote: > > > On 29 November 2013 15:24, Trevor Perrin wrote: > > >> > > >> * Why is there a "Public-Key-Pins-Report-Only" header instead of = a > > >> "report-only" directive? Most of the document is written as if th= ere > > >> was a single "PKP header field", so a directive would make more > > sense. > > > > > > > > > If it becomes a directive, we should be sure that we can still appl= y > > two > > > headers, one more loose in enforcing mode, one stricter in report o= nly > > mode. > > > > Would you expect both headers to be noted? > > > > The current spec doesn't support that. It specifies 2 different (and > > incompatible) ways of handling this case: > > > > - 2.1.3: "If a Host sets both the Public-Key-Pins header and the > > Public-Key- > > Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, = and > > MUST note only the pins and directives given in the Public-Key-Pi= ns- > > Report-Only header." > > > > - 2.3.1: "If a UA receives more than one PKP header field in an HTTP > > response message over secure transport, then the UA MUST > > process only the first such header field." > > > > > Oh yea. Heh. Why is that? CSP supports an enforcing header and a > reporting header, and both of them are applied simultaneously. I would > expect the same from HPKP. > > -tom > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > Spec bug. I'll see about getting that fixed. The PKP + PKP-Report-Only mode are meant to be parallel to their concepts from CSP. That is, the PKP-Report-Only directive is not enforced, but if = a PKP header is present, or PKPs are noted from previous, they are still enforced. From ryan-ietfhasmat@sleevi.com Fri Nov 29 16:15:00 2013 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 8EF041AE22F for ; Fri, 29 Nov 2013 16:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 Pb2yfIzp7Zc5 for ; Fri, 29 Nov 2013 16:14:58 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3041AE11E for ; Fri, 29 Nov 2013 16:14:58 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 78C64BC034; Fri, 29 Nov 2013 16:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=kN74JwnROJDEOy4uhET/OtJ7/pE=; b=PFFTWQ3msETy9tmDx 89+WaJzUAaSBeEASQOaRBSws6W05pE6854JcjxoTgSyhUG40EqaqnOK9oT5Fic7z OqqAlt7DIHPPaM3yvQ375K5caF5+Z2DuVCwPe/Z6h7JjgAuKV4PVBUrThrKqlnIo epjPOikZvKWTfEsEyOlFkK4iko= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 3DD23BC031; Fri, 29 Nov 2013 16:14:57 -0800 (PST) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 29 Nov 2013 16:14:57 -0800 Message-ID: <563531ee35ef903eea91f9ba0bdf3a4d.squirrel@webmail.dreamhost.com> In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> Date: Fri, 29 Nov 2013 16:14:57 -0800 From: "Ryan Sleevi" To: "Trevor Perrin" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 00:15:00 -0000 On Fri, November 29, 2013 12:24 pm, Trevor Perrin wrote: > On Tue, Nov 26, 2013 at 12:14 AM, Yoav Nir wrote: > > > > To summarize, although there has been much discussion since version -= 06, > > most of it did not result in massive changes to the document, so IMO = we > > don't need another WGLC. > > > * Weren't we going to discuss the relationship of preloaded to > dynamic pins? See email [1]. > > * The rationale in thread [2] for "strict" seems different from the > rationale in previous list discussions [3]. Ryan now argues that > "strict" is not needed. I think that's worth considering. > > * I had feedback on an earlier draft which is still relevant [4], see > below. > > [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html > [2] http://www.ietf.org/mail-archive/web/websec/current/msg01942.html > [3] http://www.ietf.org/mail-archive/web/websec/current/msg01484.html > [4] http://www.ietf.org/mail-archive/web/websec/current/msg01692.html > > > FEEDBACK ON DRAFT-07, STILL RELEVANT > =3D=3D=3D=3D > > * Interaction with cookies needs discussion. Cookie scoping rules > pose a serious problem for pinning, e.g. a pin at "example.com" could > be undermined by a MITM inventing a "badguy.example.com" and using it > to steal or force cookies. I still disagree that the *pin* can be undermined. > > * Why is there a "Public-Key-Pins-Report-Only" header instead of a > "report-only" directive? Most of the document is written as if there > was a single "PKP header field", so a directive would make more sense. Similar to CSP. A PKP might specify a looser-policy, while PKP-Report-Onl= y is used to test a more restrictive policy for deployment. > > * In draft-05, client processing was changed from noting a single > "expiry" value to noting two values: "Effective Pin Date" and > "max-age". The previous approach was simpler, stored less data, and > was more aligned with HSTS. > > * Section 2.3.1 fails to update the Effective Date of a noted pin > when it is noted again. > > * Section 2.6 mandates "When a UA connects to a Pinned Host, if the > TLS connection has errors, the UA MUST terminate the connection > without allowing the user to proceed". HSTS allows the server to > specify this, so it seems unnecessary and inflexible to mandate it > here. It's also unclear whether a "report-only" pin counts as a > "Pinned Host". This is a feature, not a bug. PKP is useful without mandating HSTS. However, the security advantages of PKP can be undermined, much the way HSTS's can, if the UA allows users to bypass. It would be unnecessary and inflexible to mandate HSTS in order to obtain security with PKP. > > * UA processing rules are confusingly spread across the document. > For example, 2.3.1 and 2.5 describe the same process so should be > combined. > > * Section 2.5 - Does a failed validation of a "report-only" pin count > as an "error" that will inhibit noting of new pins in the connection? No. Happy to clarify that. > > * Specified UA behavior with multiple header fields is contradictory: > - 2.1.3: "If a Host sets both the Public-Key-Pins header and the > Public-Key- > Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, a= nd > MUST note only the pins and directives given in the Public-Key-Pin= s- > Report-Only header." > - 2.3.1: "If a UA receives more than one PKP header field in an HTTP > response message over secure transport, then the UA MUST > process only the first such header field." Not contradictory, but ambiguous. The presence of > 1 PKP or > 1 PKP-R-O cause the first (PKP || PKP-R-O) field to be processed, and the rest ignored. However, if both a PKP and PKP-R-O field are present, they are both processed (independently). The ambiguity is the term "PKP header field", which may be alternatively written "more than one PKP header field or more than one PKP-R-O header field". Does that satisfy your concern? > > * Section 3 - Should the failure report contain the certificates sent > by the server, as well as the validated chain? Could help debugging > and attack analysis. > > * Why is SHA1 supported? If the reason is size, why not remove it > but allow the server to pin to a truncated hash (e.g. pin to the first > 16 or 20 bytes of SHA256) I won't attempt to assume any argument for you, but it sounds like you oppose SHA-1. Perhaps you could state that, and your reasons why. > > * Should there be a list of "excluded" keys that must not appear in > the "validated certificate chain"? Chrome's preloaded pinning > supports this, apparently to exclude 3rd-party subCAs that might have > been issued under a pinned CA. This was a temporary experiment that is no longer in use. If such a feature is desirable, it seems like something that could be addressed with additional directives in a later spec. > > * Would it be better to use the term "pin" for the entire record > associating (hostname, HPKP data), instead of calling each individual > hash a "pin"? The hostname is "pinned" to the 1-of-n key set as a > whole, not each key individually. > > * Should the header name be changed once this draft stabilizes, to > ensure no bad interactions with UAs that implemented earlier drafts? This seems premature at best, but more likely an unwarranted and unnecessary change. > > > Minor: > * "Pinning Policy" and "Pinning Metadata" are synonyms? > * 2.3.1 ... "or," ... "Otherwise" is confusing > * 2.3.2 - are clients expected to store directives they don't underst= and? > * 2.6 - is pin validation performed on resumed TLS connections? > * 3 - can UAs provide additional JSON fields inside the report? > * The term "validated certificate chain" is not defined > * An IANA registry is needed for directives > * The acknowledgement for "pin break codes" is ancient/irrelevant > > > Trevor > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From trevp@trevp.net Fri Nov 29 20:44:32 2013 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 C09581AE15A for ; Fri, 29 Nov 2013 20:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 LkHr86Cr-LmG for ; Fri, 29 Nov 2013 20:44:30 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9C81AE0E5 for ; Fri, 29 Nov 2013 20:44:30 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so2738367wid.11 for ; Fri, 29 Nov 2013 20:44:28 -0800 (PST) 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=ar/IeGy/gbfjFGJJae3Q5dtHQO0utGtdUY55Bz4EIBg=; b=Hxam8gEp/N59/IVIWFCOPn5O+hoO5r4keKds2cGZwa34rD6tLaX6P6B8P1mWBsFa0u MiBPXuBskUMoLzbXnTwQQRAijX0LO3+2j59e8jAMd162Eerl3hzN5ycq8vSv1+rWPsXz A28bXDA2QT6UW8o0T17nDOemWmSRb2312elagxjF97l5KiNzM/k78UCywf/eOoE1/kOG kTGVz3lywqR8wDzh5OB/XjbYe1jjaIPjTTT/jCTAK/Ci/3ZiB8xMt80mOuQjvgrEDwo5 /aYYnOwTSsRX1ZqBHpjzLkEQETJS1zJ7Wde1gjxGYX2MDVQxfizdpzsycmB9OmqagMX3 qzKg== X-Gm-Message-State: ALoCoQmBrt4HWLimkwxbHfgK8sALHdYvsS1oNkFyue5ae605WGtK+wVKpPE1zrOb6Bza8Hpc7RU+ MIME-Version: 1.0 X-Received: by 10.194.20.202 with SMTP id p10mr270186wje.39.1385786668274; Fri, 29 Nov 2013 20:44:28 -0800 (PST) Received: by 10.216.214.134 with HTTP; Fri, 29 Nov 2013 20:44:28 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: <563531ee35ef903eea91f9ba0bdf3a4d.squirrel@webmail.dreamhost.com> References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> <563531ee35ef903eea91f9ba0bdf3a4d.squirrel@webmail.dreamhost.com> Date: Fri, 29 Nov 2013 20:44:28 -0800 Message-ID: From: Trevor Perrin To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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, 30 Nov 2013 04:44:33 -0000 On Fri, Nov 29, 2013 at 4:14 PM, Ryan Sleevi wrote: > On Fri, November 29, 2013 12:24 pm, Trevor Perrin wrote: >> FEEDBACK ON DRAFT-07, STILL RELEVANT >> ==== >> >> * Interaction with cookies needs discussion. Cookie scoping rules >> pose a serious problem for pinning, e.g. a pin at "example.com" could >> be undermined by a MITM inventing a "badguy.example.com" and using it >> to steal or force cookies. > > I still disagree that the *pin* can be undermined. Semantics aside, there should be Security Considerations about cookies. >> * Why is there a "Public-Key-Pins-Report-Only" header instead of a >> "report-only" directive? Most of the document is written as if there >> was a single "PKP header field", so a directive would make more sense. > > Similar to CSP. A PKP might specify a looser-policy, while PKP-Report-Only > is used to test a more restrictive policy for deployment. So the UA is going to maintain 2 stores of pins ("PKP" and "PKP-R-O"), and process the "PKP" and "PKP-R-O" headers only against the appropriate store? That means asserting PKP: isn't sufficient to overwrite existing pins. You'd also have to assert PKP-R-O:max-age=0. Seems OK, but none of this is in the draft. >> * In draft-05, client processing was changed from noting a single >> "expiry" value to noting two values: "Effective Pin Date" and >> "max-age". The previous approach was simpler, stored less data, and >> was more aligned with HSTS. >> >> * Section 2.3.1 fails to update the Effective Date of a noted pin >> when it is noted again. >> >> * Section 2.6 mandates "When a UA connects to a Pinned Host, if the >> TLS connection has errors, the UA MUST terminate the connection >> without allowing the user to proceed". HSTS allows the server to >> specify this, so it seems unnecessary and inflexible to mandate it >> here. It's also unclear whether a "report-only" pin counts as a >> "Pinned Host". > > This is a feature, not a bug. > > PKP is useful without mandating HSTS. However, the security advantages of > PKP can be undermined, much the way HSTS's can, if the UA allows users to > bypass. I think it's a mistake to mandate UI here. "Users clicking through legitimate security errors" is one risk. "Users being denied access to legitimate sites due to pinning failures" is another. It's hard to know how to balance these. We should allow UAs latitude. I suggest changing the text from MUST to SHOULD, at minimum. >> * UA processing rules are confusingly spread across the document. >> For example, 2.3.1 and 2.5 describe the same process so should be >> combined. >> >> * Section 2.5 - Does a failed validation of a "report-only" pin count >> as an "error" that will inhibit noting of new pins in the connection? > > No. Happy to clarify that. Should failed validation of a "report-only" pin inhibit noting of new "report-only" pins? >> * Specified UA behavior with multiple header fields is contradictory: >> - 2.1.3: "If a Host sets both the Public-Key-Pins header and the >> Public-Key- >> Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and >> MUST note only the pins and directives given in the Public-Key-Pins- >> Report-Only header." >> - 2.3.1: "If a UA receives more than one PKP header field in an HTTP >> response message over secure transport, then the UA MUST >> process only the first such header field." > > Not contradictory, but ambiguous. The presence of > 1 PKP or > 1 PKP-R-O > cause the first (PKP || PKP-R-O) field to be processed, and the rest > ignored. However, if both a PKP and PKP-R-O field are present, they are > both processed (independently). > > The ambiguity is the term "PKP header field", which may be alternatively > written "more than one PKP header field or more than one PKP-R-O header > field". Does that satisfy your concern? The draft is generally written as if there was a only single "header" and a single stored "entry" for any site, so these sorts of changes will probably need to be made elsewhere. >> * Section 3 - Should the failure report contain the certificates sent >> by the server, as well as the validated chain? Could help debugging >> and attack analysis. >> >> * Why is SHA1 supported? If the reason is size, why not remove it >> but allow the server to pin to a truncated hash (e.g. pin to the first >> 16 or 20 bytes of SHA256) > > I won't attempt to assume any argument for you, but it sounds like you > oppose SHA-1. Perhaps you could state that, and your reasons why. It's weaker than SHA-256. I don't see a reason to bother with it. It seems better to steer everyone towards one hash algorithm, to make comparing pins easier. >> * Should there be a list of "excluded" keys that must not appear in >> the "validated certificate chain"? Chrome's preloaded pinning >> supports this, apparently to exclude 3rd-party subCAs that might have >> been issued under a pinned CA. > > This was a temporary experiment that is no longer in use. > > If such a feature is desirable, it seems like something that could be > addressed with additional directives in a later spec. OK. >> * Would it be better to use the term "pin" for the entire record >> associating (hostname, HPKP data), instead of calling each individual >> hash a "pin"? The hostname is "pinned" to the 1-of-n key set as a >> whole, not each key individually. >> >> * Should the header name be changed once this draft stabilizes, to >> ensure no bad interactions with UAs that implemented earlier drafts? > > This seems premature at best, but more likely an unwarranted and > unnecessary change. Chromium has had evolving, partial support for HPKP for some time. Have these partial versions been shipping? Are they likely to be "in the wild", with odd behavior that HPKP-asserting sites might trigger? Trevor From ryan-ietfhasmat@sleevi.com Fri Nov 29 23:47:06 2013 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 1EBC41AE12F for ; Fri, 29 Nov 2013 23:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 eJKdW82bKL04 for ; Fri, 29 Nov 2013 23:47:03 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id B41721AE121 for ; Fri, 29 Nov 2013 23:47:03 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 02DF6BC034; Fri, 29 Nov 2013 23:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=Z03JH+dwNrLZq0Q/8/j09hVsbGE=; b=jeo420F3YS5T2T9Ic yAeQpg8f1mwsYmvZyfUdk04qVeNZMvZiGz6HgmDDYdNQCHvWHStHjqvnFC8vRlQ3 D8hK/9DpKDs0d/xxzaJ3d8ihR7qQ75p5p07rsvoFnAj0bMQqool5fKIVbK5DzCWA Pavbuvy9paznLMO7PAbwvbxZ/c= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id C7104BC033; Fri, 29 Nov 2013 23:47:01 -0800 (PST) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 29 Nov 2013 23:47:01 -0800 Message-ID: <0293e6287211dfed80b38b0c367a6b9c.squirrel@webmail.dreamhost.com> In-Reply-To: References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> <563531ee35ef903eea91f9ba0bdf3a4d.squirrel@webmail.dreamhost.com> Date: Fri, 29 Nov 2013 23:47:01 -0800 From: "Ryan Sleevi" To: "Trevor Perrin" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 07:47:06 -0000 On Fri, November 29, 2013 8:44 pm, Trevor Perrin wrote: > On Fri, Nov 29, 2013 at 4:14 PM, Ryan Sleevi > wrote: > > On Fri, November 29, 2013 12:24 pm, Trevor Perrin wrote: > >> FEEDBACK ON DRAFT-07, STILL RELEVANT > >> =3D=3D=3D=3D > >> > >> * Interaction with cookies needs discussion. Cookie scoping rules > >> pose a serious problem for pinning, e.g. a pin at "example.com" cou= ld > >> be undermined by a MITM inventing a "badguy.example.com" and using = it > >> to steal or force cookies. > > > > I still disagree that the *pin* can be undermined. > > Semantics aside, there should be Security Considerations about cookies= . > > > >> * Why is there a "Public-Key-Pins-Report-Only" header instead of a > >> "report-only" directive? Most of the document is written as if the= re > >> was a single "PKP header field", so a directive would make more sen= se. > > > > Similar to CSP. A PKP might specify a looser-policy, while > > PKP-Report-Only > > is used to test a more restrictive policy for deployment. > > So the UA is going to maintain 2 stores of pins ("PKP" and "PKP-R-O"), > and process the "PKP" and "PKP-R-O" headers only against the > appropriate store? > > That means asserting PKP: isn't sufficient to overwrite > existing pins. You'd also have to assert PKP-R-O:max-age=3D0. > > Seems OK, but none of this is in the draft. An artifact of when a PKP header was required (eg: implicit Max-Age). Thi= s is because Report-Only doesn't/wouldn't need to be stored, because it is = a report-only mechanism. You simply evaluate the R-O on the current connection (if a directive is present) and ping back. As noted during Orlando, this is not a security mechanism, nor intended t= o be one. It's a reporting/deployment testing mechanism. In that sense, R-O still doesn't need to be stored, it could simply be "If present, evaluate the connection against these [potential] pins". If absent, no R-O implied= . With the implementer hat on, I can go either way, but with a preference towards the following: To me, R-O makes most sense when treated like CSP = - if present, report, otherwise, nothing. This is consistent with an implicit Max-Age: 0, because no storage is required or performed. > > > >> * In draft-05, client processing was changed from noting a single > >> "expiry" value to noting two values: "Effective Pin Date" and > >> "max-age". The previous approach was simpler, stored less data, an= d > >> was more aligned with HSTS. Yet was very much intended to address the same concerns you raised regarding the intersection between 'preloaded' and 'dyamic' pins, and the WG seemed to support. Do you have a proposal on how to reconcile these two items? Otherwise, it seems like an issue that's impossible to address - on the one hand, an objection to the ways that preloaded and dynamic may intersect, yet on th= e other, an objection to attempts to attempts to clarify the ways that they do. > >> > >> * Section 2.3.1 fails to update the Effective Date of a noted pin > >> when it is noted again. > >> > >> * Section 2.6 mandates "When a UA connects to a Pinned Host, if th= e > >> TLS connection has errors, the UA MUST terminate the connection > >> without allowing the user to proceed". HSTS allows the server to > >> specify this, so it seems unnecessary and inflexible to mandate it > >> here. It's also unclear whether a "report-only" pin counts as a > >> "Pinned Host". > > > > This is a feature, not a bug. > > > > PKP is useful without mandating HSTS. However, the security advantage= s > > of > > PKP can be undermined, much the way HSTS's can, if the UA allows user= s > > to > > bypass. > > I think it's a mistake to mandate UI here. "Users clicking through > legitimate security errors" is one risk. "Users being denied access > to legitimate sites due to pinning failures" is another. > > It's hard to know how to balance these. We should allow UAs latitude. > I suggest changing the text from MUST to SHOULD, at minimum. Thanks for your feedback. I'd like to hear from others in the WG if that view is shared. To this point, we haven't heard any concerns about the MUST, and the security properties are seemingly well understood. Certainly, no UA vendor has asked or proposed such latitude. But then again, we're all individuals here. I do fail to understand your distinction between "legitimate security errors" and "pinning failures". = I would certainly count the latter amongst the former, and so I fail to see how the risks differ, beyond being a superset/subset. > > > >> * UA processing rules are confusingly spread across the document. > >> For example, 2.3.1 and 2.5 describe the same process so should be > >> combined. > >> > >> * Section 2.5 - Does a failed validation of a "report-only" pin co= unt > >> as an "error" that will inhibit noting of new pins in the connectio= n? > > > > No. Happy to clarify that. > > Should failed validation of a "report-only" pin inhibit noting of new > "report-only" pins? See above re: "noting" for R-O. > > > >> * Specified UA behavior with multiple header fields is contradicto= ry: > >> - 2.1.3: "If a Host sets both the Public-Key-Pins header and the > >> Public-Key- > >> Pins-Report-Only header, the UA MUST NOT enforce Pin Validation= , > >> and > >> MUST note only the pins and directives given in the > >> Public-Key-Pins- > >> Report-Only header." > >> - 2.3.1: "If a UA receives more than one PKP header field in an HT= TP > >> response message over secure transport, then the UA MUST > >> process only the first such header field." > > > > Not contradictory, but ambiguous. The presence of > 1 PKP or > 1 PKP-= R-O > > cause the first (PKP || PKP-R-O) field to be processed, and the rest > > ignored. However, if both a PKP and PKP-R-O field are present, they a= re > > both processed (independently). > > > > The ambiguity is the term "PKP header field", which may be alternativ= ely > > written "more than one PKP header field or more than one PKP-R-O head= er > > field". Does that satisfy your concern? > > The draft is generally written as if there was a only single "header" > and a single stored "entry" for any site, so these sorts of changes > will probably need to be made elsewhere. Single header, yes, updates needed. Single stored entry, however, is hopefully addressed above. > > > >> * Section 3 - Should the failure report contain the certificates s= ent > >> by the server, as well as the validated chain? Could help debuggin= g > >> and attack analysis. > >> > >> * Why is SHA1 supported? If the reason is size, why not remove it > >> but allow the server to pin to a truncated hash (e.g. pin to the fi= rst > >> 16 or 20 bytes of SHA256) > > > > I won't attempt to assume any argument for you, but it sounds like yo= u > > oppose SHA-1. Perhaps you could state that, and your reasons why. > > It's weaker than SHA-256. I don't see a reason to bother with it. > > It seems better to steer everyone towards one hash algorithm, to make > comparing pins easier. > Size, speed, and simplicity were primary motivations, and the security risks at this time are mild to non-existant - particularly given the lack of latitude to mount attacks using the structured nature of the SPKI. However, if you follow discussions in the CA/Browser Forum with respect t= o Microsoft's plans to deprecate SHA-1, you will see that a number of CAs have reported vendors/products that don't support SHA-256. Now, we can discuss at length what the intersection is of (potential implementors of PKP) and (implementations that don't support SHA-256), as well as the potential implications of adding support for PKP but not SHA-256 (the latter which, for FIPS validated products, would require re-valation). In short, I don't feel like it's a compelling reason not to include SHA-1 at this time (but am happy to see if the WG, ADs, or CFRG feel otherwise)= , but I would definitely have concern over the complexity of some truncatio= n schemes. Example concerns with the proposal include: Is it arbitrary or i= s it fixed? If it's fixed, is the criteria size of the hash? Speed of the hash? Some other criteria? > > >> * Should there be a list of "excluded" keys that must not appear i= n > >> the "validated certificate chain"? Chrome's preloaded pinning > >> supports this, apparently to exclude 3rd-party subCAs that might ha= ve > >> been issued under a pinned CA. > > > > This was a temporary experiment that is no longer in use. > > > > If such a feature is desirable, it seems like something that could be > > addressed with additional directives in a later spec. > > OK. > > > >> * Would it be better to use the term "pin" for the entire record > >> associating (hostname, HPKP data), instead of calling each individu= al > >> hash a "pin"? The hostname is "pinned" to the 1-of-n key set as a > >> whole, not each key individually. > >> > >> * Should the header name be changed once this draft stabilizes, to > >> ensure no bad interactions with UAs that implemented earlier drafts= ? > > > > This seems premature at best, but more likely an unwarranted and > > unnecessary change. > > Chromium has had evolving, partial support for HPKP for some time. > Have these partial versions been shipping? > > Are they likely to be "in the wild", with odd behavior that > HPKP-asserting sites might trigger? Chromium does not ship versions. Chrome, which is based on Chromium, releases new versions approximately every six weeks. It has been successful in following the ongoing standardization processes of a variety of specifications - in the IETF, i= n the W3C, and in the WHATWG - and updating implementations accordingly and (nearly) completely. If someone falls off the proverbial update wagon of Chrome, they have a host of much more pressing matters - such as disclose= d security issues - that no doubt are much more concerning than the (potential) risks of (potentially) incompatible changes. Firefox, which has supported HSTS and is working on (shipping?) HPKP support, is likewise on a similar update trajectory and a similar situation where users and sites face much more pressing concerns than HPKP. I would think that it would be much better addressed that, as we progress through WGLC, IF we find we need to make backwards incompatible changes, we can assess the risks then, rather than act on hypothetical concerns in the present. Cheers, Ryan From trevp@trevp.net Sat Nov 30 18:30:37 2013 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 3A3AC1AE241 for ; Sat, 30 Nov 2013 18:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 VHYzRSvwqi3V for ; Sat, 30 Nov 2013 18:30:34 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7E1AE0A6 for ; Sat, 30 Nov 2013 18:30:33 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id a1so8793848wgh.35 for ; Sat, 30 Nov 2013 18:30:31 -0800 (PST) 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=YQpQSg19zf/kbZpf5X6zL726uvPDnNBRscLMvD/x4tw=; b=EMBW6NGh6sccRyrr6bTqImIe1vIu1+VkmTiBQkxdUjeQz5Qsj1TpuMqg6s+jBE1fV2 qxxp3NLSc2J41ABY+RFDRfgH731D6egbdnwR/bOgKYy6EYAvOyFVUIuUlBr2y3kd46Nj L4Exl3ts0KxfM3i0iF8bUSpWJyt3gsRUvYHrN8Ekz2ZoVLEya1pinOXQobeWpSyTpjVW rBrMwB3/DvLatgyrhk1G3w/F1p7psm0q+seFxVKUVtrI7b8VceVCbou7Ywt2ocS1Zm9W TdPd6Shscv4PzTUsm6j9cPOvm0gqhiGa4tsLw7IzOx4tomDtkQ5XUjgAQ7+siVfFTz6v Exaw== X-Gm-Message-State: ALoCoQnoRftCQwgQpX4B97gvpwoyd99mNaov7vAArIVZPSJRBq2laFWPccTHYzgD1XicKKxsvSBF MIME-Version: 1.0 X-Received: by 10.180.89.193 with SMTP id bq1mr3244809wib.22.1385865031574; Sat, 30 Nov 2013 18:30:31 -0800 (PST) Received: by 10.216.214.134 with HTTP; Sat, 30 Nov 2013 18:30:31 -0800 (PST) X-Originating-IP: [199.83.223.81] In-Reply-To: <0293e6287211dfed80b38b0c367a6b9c.squirrel@webmail.dreamhost.com> References: <47CAE73E-1D48-42CF-8D75-3B9A50C286FD@checkpoint.com> <8eea8853462937ad59b0619cca9c4953.squirrel@webmail.dreamhost.com> <563531ee35ef903eea91f9ba0bdf3a4d.squirrel@webmail.dreamhost.com> <0293e6287211dfed80b38b0c367a6b9c.squirrel@webmail.dreamhost.com> Date: Sat, 30 Nov 2013 18:30:31 -0800 Message-ID: From: Trevor Perrin To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] HPKP: The strict directive and TLS proxies 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: Sun, 01 Dec 2013 02:30:37 -0000 On Fri, Nov 29, 2013 at 11:47 PM, Ryan Sleevi wrote: > On Fri, November 29, 2013 8:44 pm, Trevor Perrin wrote: >> On Fri, Nov 29, 2013 at 4:14 PM, Ryan Sleevi >> wrote: >> > On Fri, November 29, 2013 12:24 pm, Trevor Perrin wrote: >> >> >> * Why is there a "Public-Key-Pins-Report-Only" header instead of a >> >> "report-only" directive? Most of the document is written as if there >> >> was a single "PKP header field", so a directive would make more sense. >> > >> > Similar to CSP. A PKP might specify a looser-policy, while >> > PKP-Report-Only >> > is used to test a more restrictive policy for deployment. >> >> So the UA is going to maintain 2 stores of pins ("PKP" and "PKP-R-O"), >> and process the "PKP" and "PKP-R-O" headers only against the >> appropriate store? >> >> That means asserting PKP: isn't sufficient to overwrite >> existing pins. You'd also have to assert PKP-R-O:max-age=0. >> >> Seems OK, but none of this is in the draft. > > An artifact of when a PKP header was required (eg: implicit Max-Age). This > is because Report-Only doesn't/wouldn't need to be stored, because it is a > report-only mechanism. You simply evaluate the R-O on the current > connection (if a directive is present) and ping back. Hmm, I assumed "report-only" pins would be noted, and the draft seems written that way. To step back: It's hard to read this draft and understand how "strict", "report-only", or "preloaded" pins should be handled. It seems these concepts were bolted-on to the draft without being fully integrated. Also, processing rules are scattered throughout, so it's hard to get a clear view of what happens during (A) processing an HPKP header, and (B) validating a connection. The draft could use an editing pass that doesn't change the protocol (from the authors' understanding), but clarifies these things. >> >> * In draft-05, client processing was changed from noting a single >> >> "expiry" value to noting two values: "Effective Pin Date" and >> >> "max-age". The previous approach was simpler, stored less data, and >> >> was more aligned with HSTS. > > Yet was very much intended to address the same concerns you raised > regarding the intersection between 'preloaded' and 'dyamic' pins, and the > WG seemed to support. > > Do you have a proposal on how to reconcile these two items? I propose that pin expiry should be handled in the older, simpler way, consistent with HSTS (noting a single "expiry" value). I understand that tracking the "Effective Pin Date" was added to support the "most recently observed" policy in 2.7. As I've argued in [1], I think that policy is overly complex. There are simpler policies which UAs should have the freedom to choose. Anyways, maybe you could respond to [1], and we could separate out that discussion. >> >> * Section 2.6 mandates "When a UA connects to a Pinned Host, if the >> >> TLS connection has errors, the UA MUST terminate the connection >> >> without allowing the user to proceed". HSTS allows the server to >> >> specify this, so it seems unnecessary and inflexible to mandate it >> >> here. It's also unclear whether a "report-only" pin counts as a >> >> "Pinned Host". >> > >> > This is a feature, not a bug. >> > >> > PKP is useful without mandating HSTS. However, the security advantages >> > of >> > PKP can be undermined, much the way HSTS's can, if the UA allows users >> > to >> > bypass. >> >> I think it's a mistake to mandate UI here. "Users clicking through >> legitimate security errors" is one risk. "Users being denied access >> to legitimate sites due to pinning failures" is another. >> >> It's hard to know how to balance these. We should allow UAs latitude. >> I suggest changing the text from MUST to SHOULD, at minimum. > > Thanks for your feedback. I'd like to hear from others in the WG if that > view is shared. To this point, we haven't heard any concerns about the > MUST, and the security properties are seemingly well understood. > > Certainly, no UA vendor has asked or proposed such latitude. But then > again, we're all individuals here. I do fail to understand your > distinction between "legitimate security errors" and "pinning failures". Pinning is risky. Sites could make a mistake that renders them unreachable. This could be mitigated by "softening" UA behavior when pin validation fails, e.g. silent-fail (with reporting), or soft-fail (that can be clicked through) instead of hard-fail. There are complex usability / security tradeoffs here. I submit we don't have enough experience with pinning to mandate a specific UI. >> >> * Why is SHA1 supported? If the reason is size, why not remove it >> >> but allow the server to pin to a truncated hash (e.g. pin to the first >> >> 16 or 20 bytes of SHA256) >> > >> > I won't attempt to assume any argument for you, but it sounds like you >> > oppose SHA-1. Perhaps you could state that, and your reasons why. >> >> It's weaker than SHA-256. I don't see a reason to bother with it. >> >> It seems better to steer everyone towards one hash algorithm, to make >> comparing pins easier. >> > > Size, speed, and simplicity were primary motivations, and the security > risks at this time are mild to non-existant - particularly given the lack > of latitude to mount attacks using the structured nature of the SPKI. > > However, if you follow discussions in the CA/Browser Forum with respect to > Microsoft's plans to deprecate SHA-1, you will see that a number of CAs > have reported vendors/products that don't support SHA-256. SHA-256 is mandatory for HPKP, so they'll have to add it. Anyways, I suggest replacing SHA-1 with SHA-256 truncated to 128 bits. For example: Public-Key-Pins: sha256-128=, sha256= This is simpler for the UA, as it only needs to calculate one hash on each SPKI in the chain (instead of two). It's also more usable for deployers, since the same SPKI can be recognized whether it's hashed in short or long form. It's also more compact, and a stronger cryptographic hash (given current state of cryptanalysis, e.g. [2]). >> >> * Should the header name be changed once this draft stabilizes, to >> >> ensure no bad interactions with UAs that implemented earlier drafts? >> > >> > This seems premature at best, but more likely an unwarranted and >> > unnecessary change. >> >> Chromium has had evolving, partial support for HPKP for some time. >> Have these partial versions been shipping? >> >> Are they likely to be "in the wild", with odd behavior that >> HPKP-asserting sites might trigger? > > Chromium does not ship versions. > Chrome, which is based on Chromium, releases new versions approximately > every six weeks. It has been successful in following the ongoing > standardization processes of a variety of specifications - in the IETF, in > the W3C, and in the WHATWG - and updating implementations accordingly and > (nearly) completely Beyond just spec changes, I'd be concerned about code quality. Chromium has had evolving code to do *something-or-other* in response to the "Public-Key-Pins" header for over a year. This code is a work-in-progress (in my opinion). Some versions of it seem like they might have problems such as applying a pin for a longer expiry than was asserted, or with incorrect include_subdomains. If I was a site contemplating turning on the HPKP header, this would make me nervous. Renaming the header seems a trivial fix to avoid any risk here. Trevor [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html [2] https://marc-stevens.nl/research/papers/EC13-S.pdf