From ynir@checkpoint.com Thu Aug 2 11:18:14 2012 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 CF84421E80C4; Thu, 2 Aug 2012 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.326 X-Spam-Level: X-Spam-Status: No, score=-10.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, 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 oVZqVKvkAJt4; Thu, 2 Aug 2012 11:18:14 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A486D21E80DF; Thu, 2 Aug 2012 11:18:13 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q72IIB04011132; Thu, 2 Aug 2012 21:18:11 +0300 X-CheckPoint: {501AC1CA-1-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 2 Aug 2012 21:18:10 +0300 From: Yoav Nir To: Ben Campbell Date: Thu, 2 Aug 2012 21:18:09 +0300 Thread-Topic: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 Thread-Index: Ac1w2yvprMHoxvR2RzOTiJG6heTTcA== Message-ID: References: <50161BD5.7040901@KingsMountain.com> <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> In-Reply-To: <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team , IETF WebSec WG , "draft-ietf-websec-strict-transport-sec.all@tools.ietf.org" , IETF Discussion List Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Thu, 02 Aug 2012 18:18:15 -0000 On Aug 2, 2012, at 10:46 AM, Ben Campbell wrote: > Hi, thanks for the response. Comments inline: >=20 > On Jul 29, 2012, at 10:29 PM, =3DJeffH wr= ote: >=20 >>> -- I did not find any guidance on how to handle UAs that do not underst= and >>> this extension. I don't know if this needs to be normative, but the dra= ft >>> should at least mention the possibility and implications. >>=20 >> Agreed. My -12 working copy now contains these new subsections.. >>=20 >> ### >> 10. Server Implementation and Deployment Advice >>=20 >> This section is non-normative. >>=20 >> 10.1. Non-Conformant User Agent Considerations >>=20 >> Non-conformant UAs ignore the Strict-Transport-Security header field, >> thus non-conformant user agents do not address the threats described >> in Section 2.3.1 "Threats Addressed". Please refer to Section 14.1 >> "Non-Conformant User Agent Implications" for further discussion. >>=20 >> . >> . >>=20 >> 14. Security Considerations >> . >> . >> 14.1. Non-Conformant User Agent Implications >>=20 >> Non-conformant UAs ignore the Strict-Transport-Security header field, >> thus non-conformant user agents do not address the threats described >> in Section 2.3.1 "Threats Addressed". >>=20 >> This means that the web application and its users wielding non- >> conformant user agents will be vulnerable to both: >>=20 >> Passive network attacks due to web site development and deployment >> bugs: For example, if the web application contains any insecure, >> non-"https", references to the web application server, and if not >> all of its cookies are flagged as "Secure", then its cookies will >> be vulnerable to passive network sniffing, and potentially >> subsequent misuse of user credentials. >>=20 >> Active network attacks: If an attacker is able to place a man-in- >> the-middle, secure transport connection attempts will likely yield >> warnings to the user, but without HSTS Policy being enforced, the >> present common practice is to allow the user to "click-through" >> and proceed. This renders the user and possibly the web >> application open to abuse by such an attacker. >>=20 >> This is essentially the status-quo for all web applications and their >> users in the absence of HSTS Policy. >> ### >=20 > That's all good text, but I'm not sure it actually captures my concern. >=20 > From the server's perspective, the fact that non-conformant UAs may exist= , the server cannot assume that UAs will honor the extension. This means th= at a UA might attempt unprotected access to some resource assumed to be pro= tected by this extension. That is, the server can't merely select the exten= sion and forget about things--it still needs to to take the same care to av= oid leaking resources over unprotected connections that it would need to do= if this extension did not exist in the first place. >=20 > I think this is implied by your last sentence above, but it would be bett= er to say it explicitly. Hi Ben On this issue, it should be noted that there is never a guarantee that a UA= will respect this extension: - Older UAs and the latest and greatest Internet Explorer do not support t= his - Any UA that has not visited this website yet may try to access insecurel= y - Any UA that has visited this website, but has not done so within the tim= e period may try to access insecurely A server can use HSTS to reflect a "no HTTP" policy, but it cannot be used = to enforce a "only clients that know I'm STS" policy. That is outside the s= cope of the draft. A DNS-based approach could solve the TOFU issue, but older clients (or thos= e without access to the secure DNS) could always try to get things over HTT= P Yoav From ynir@checkpoint.com Thu Aug 2 11:40:33 2012 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 20B1021E8129 for ; Thu, 2 Aug 2012 11:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.331 X-Spam-Level: X-Spam-Status: No, score=-10.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=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 WF-cNcwwhobu for ; Thu, 2 Aug 2012 11:40:32 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3311621E8128 for ; Thu, 2 Aug 2012 11:40:31 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q72IeUPe013780 for ; Thu, 2 Aug 2012 21:40:30 +0300 X-CheckPoint: {501AC705-6-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 2 Aug 2012 21:40:29 +0300 From: Yoav Nir To: IETF WebSec WG Date: Thu, 2 Aug 2012 21:40:27 +0300 Thread-Topic: [saag] WebSec status Thread-Index: Ac1w3knOZJZOe76iTDeO/hhx8jqntg== Message-ID: References: <3AACCB72-00F2-4CB5-992E-3578DB840461@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_B903AC47343F4674A5E855ABE57238DEcheckpointcom_" MIME-Version: 1.0 Subject: [websec] Fwd: [saag] WebSec status 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: Thu, 02 Aug 2012 18:40:33 -0000 --_000_B903AC47343F4674A5E855ABE57238DEcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. forgot to CC this list. Begin forwarded message: From: Yoav Nir > Subject: [saag] WebSec status Date: August 2, 2012 9:15:07 AM PDT To: "saag@ietf.org" > WebSec met at 9:00 AM on Tuesday morning. HSTS is at IETF LC. All issues are resolved, and a new revision should go t= o the IESG soon. Cert Pinning is coming along, with several issues to be discussed on the li= st Still no editor for Mime-sniffing. If none is found soon, we may consider d= ropping this item, but there are issues with HTML5 spec referencing it. The Frame-Options drafts (X- and non-X-) are coming along OK, but the non-X= may become part of CSP and move to W3C Yoav --_000_B903AC47343F4674A5E855ABE57238DEcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. forgot to CC this l= ist.

Begin forwarded message:

From:= Yoav= Nir <ynir@checkpoint.com>=
Subject: [saag] WebSec status=
Date: August 2, 2012 9:15:07 AM PDT<= br>

WebSec met at 9:00 AM on Tuesday morning.
<= br>HSTS is at IETF LC. All issues are resolved, and a new revision should g= o to the IESG soon.
Cert Pinning is coming along, with several issues to= be discussed on the list
Still no editor for Mime-sniffing. If none is = found soon, we may consider dropping this item, but there are issues with H= TML5 spec referencing it.
The Frame-Options drafts (X- and non-X-) are c= oming along OK, but the non-X may become part of CSP and move to W3C
Yoav

= --_000_B903AC47343F4674A5E855ABE57238DEcheckpointcom_-- From ben@nostrum.com Thu Aug 2 10:46:17 2012 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 C6EB611E81BC; Thu, 2 Aug 2012 10:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 NVtHBLOq8qXu; Thu, 2 Aug 2012 10:46:16 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B07811E81AD; Thu, 2 Aug 2012 10:46:16 -0700 (PDT) Received: from dhcp-625b.meeting.ietf.org (dhcp-625b.meeting.ietf.org [130.129.98.91]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q72Hk62W012780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 12:46:11 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ben Campbell In-Reply-To: <50161BD5.7040901@KingsMountain.com> Date: Thu, 2 Aug 2012 10:46:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> References: <50161BD5.7040901@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1485) Received-SPF: pass (nostrum.com: 130.129.98.91 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Thu, 02 Aug 2012 16:32:32 -0700 Cc: General Area Review Team , IETF WebSec WG , draft-ietf-websec-strict-transport-sec.all@tools.ietf.org, IETF Discussion List Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Thu, 02 Aug 2012 17:46:18 -0000 Hi, thanks for the response. Comments inline: On Jul 29, 2012, at 10:29 PM, =3DJeffH = wrote: >=20 > > -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, = that > > should be explicitly flagged and mentioned in the abstract. >=20 > Good question, I don't believe we've discussed this possibility = directly in the websec wg. In looking at the RFCs that do update = RFC2616, it doesn't look like draft-ietf-websec-strict-transport-sec = (HSTS) is of that ilk. >=20 > However, it nominally appears that an argument could be made that it'd = be appropriate to update RFC2818 via = draft-ietf-websec-strict-transport-sec, specifically with regards to = Section 2.1. Connection Initiation. >=20 > Though, RFC2818 is Informational, which may be an issue (?). Also, = perhaps this is something to more appropriately do via a standards-track = rfc2818bis, i.e., have the latter reference the HSTS spec. >=20 > this is something to discuss this coming week @IETF-84 Vancouver it = seems. >=20 >=20 I will comment on this in response to your post-meeting email. > > -- I did not find any guidance on how to handle UAs that do not = understand > > this extension. I don't know if this needs to be normative, but the = draft > > should at least mention the possibility and implications. >=20 > Agreed. My -12 working copy now contains these new subsections.. >=20 > ### > 10. Server Implementation and Deployment Advice >=20 > This section is non-normative. >=20 > 10.1. Non-Conformant User Agent Considerations >=20 > Non-conformant UAs ignore the Strict-Transport-Security header = field, > thus non-conformant user agents do not address the threats described > in Section 2.3.1 "Threats Addressed". Please refer to Section 14.1 > "Non-Conformant User Agent Implications" for further discussion. >=20 > . > . >=20 > 14. Security Considerations > . > . > 14.1. Non-Conformant User Agent Implications >=20 > Non-conformant UAs ignore the Strict-Transport-Security header = field, > thus non-conformant user agents do not address the threats described > in Section 2.3.1 "Threats Addressed". >=20 > This means that the web application and its users wielding non- > conformant user agents will be vulnerable to both: >=20 > Passive network attacks due to web site development and = deployment > bugs: For example, if the web application contains any insecure, > non-"https", references to the web application server, and if not > all of its cookies are flagged as "Secure", then its cookies will > be vulnerable to passive network sniffing, and potentially > subsequent misuse of user credentials. >=20 > Active network attacks: If an attacker is able to place a man-in- > the-middle, secure transport connection attempts will likely = yield > warnings to the user, but without HSTS Policy being enforced, the > present common practice is to allow the user to "click-through" > and proceed. This renders the user and possibly the web > application open to abuse by such an attacker. >=20 > This is essentially the status-quo for all web applications and = their > users in the absence of HSTS Policy. > ### That's all good text, but I'm not sure it actually captures my concern. =46rom the server's perspective, the fact that non-conformant UAs may = exist, the server cannot assume that UAs will honor the extension. This = means that a UA might attempt unprotected access to some resource = assumed to be protected by this extension. That is, the server can't = merely select the extension and forget about things--it still needs to = to take the same care to avoid leaking resources over unprotected = connections that it would need to do if this extension did not exist in = the first place. I think this is implied by your last sentence above, but it would be = better to say it explicitly. >=20 > > > > -- How should a UA handle potential conflicts between a the policy = record > > that includes the includeSubdomain, and any records for subdomains = that might > > have different parameters? >=20 > this is in the draft. the short answer is that at policy enforcement = time, "superdomain matches win". >=20 > At "noting an HSTS Host" time, the HSTS host's policy (if expressed) = is noted regardless of whether there are superdomain HSTS hosts = asserting "includeSubDomains". >=20 > perhaps this needs to be made more clear? Maybe I'm missing something, but I'm not getting that answer from the = text. Can you point out the specific language? >=20 >=20 > > > > -- section 6.1: > > > > The draft mentions that directives may be extended, but defers = creation of an > > IANA registry to the time of first extension. IANA registries are = not > > expensive; I suggest it be created now. If there's a good reason not = to, then > > the draft should still address the specification policy for = extensions. > > > > Also, do you expect that some future directive might need to have a > > "required-to-understand" status? Given that this is a = security-affecting > > extension, it seems likely. If so, then the mechanism for expressing = that > > needs to be defined in this draft. >=20 >=20 > These are good questions, and they beg the overall question of how = complex this simple solution really needs to be and whether we really = think we'll need any extensions. Something for us to discuss in the = working group meeting on Tue morning I think. I will comment on this in the post-meeting mail. >=20 > > > > -- section 7.2: > > > > Am I correct to assume that the server must never just serve the = content over > > a non-secure connection? If so, it would be helpful to mention that, = maybe > > even normatively. >=20 > It's a SHOULD, see the Note in that section, so it's already = effectively stated normatively, though one needs to understand HTTP = workings to realize it in the way you stated it above. Perhaps could = add a simple statement as you suggest to the intro para for section 7 = Server Processing Model, to address this concern? >=20 I think something of the form SHOULD redirect to HTTPS, but MUST NOT = under any circumstances send the content unprotected would improve the = text. That's probably already implied, and a reasonable implementor = wouldn't due it anyway. But my experience is that some readers will find = strange interpretations whenever you give them the wiggle room to do so, = so it's better to be explicit. >=20 > > > > -- section 8.4: > > > > Does this imply a duty for compliant UAs to check for revocation one = way or > > another? >=20 > yes. though, per other relevant specifications, as duly cited. AFAIK = the HSTS spec doesn't need to get into the details because the = underlying security transport specs, namely TLS, already do this. If that duty already exists, then I see no reason to add it here. But do = the cited specs unambiguously _require_ revocation checks? I admit to = not being an expert here, but on a quick scan it seems more like they = say how you can do it, but do they say you have to?=20 [...] >=20 > > -- section 1.2: > > > > The description of indented notes is almost precisely the opposite = of how > > they are described in the RFC editor's style guide. It describes = them as > > "parenthetical" notes, which is how experienced RFC readers are = likely to > > perceive them. While it doesn't say so explicitly, I think putting = normative > > text in parenthetical notes should be avoided. If these are intended = to be > > taken more strongly than that (and by the description, I take it = they should > > be taken more strongly than the surrounding text), then I suggest = choosing a > > stronger prefix than "NOTE:" >=20 > As it turns out, almost all the Notes are parenthetical. >=20 > I'll render the one(s) that are normative as a regular paragraph(s) = and leave the others as-is. Will that address your concern? >=20 Yes, thanks. >=20 > > > > -- section 7: > > > > Does the reference to I-D.ietf-tls-ssl-version3 indicate a = requirement for > > SSL3? >=20 > no, it's just that SSLv3 remains a fact of life and is referenced for = completeness' sake. >=20 >=20 Okay. >=20 > > > > -- section 8.2, paragraph 5 (first non-numbered paragraph after = numbered > > list) > > > > To be pedantic, this could be taken to mean a congruent match only = applies if > > the includeSubdomains flag is not present. I assume it's intended to = apply > > whether or not the flag is present. >=20 > [ I am assuming you actually are referring to section 8.3, as section = 8.2 doesn't mention the includeSubdomains flag and does not contain a = numbered list. ] >=20 > yes, a congruent match is intended to apply whether or not the flag is = present. >=20 >=20 yes, I meant 8.3. And on re-reading, I think the text is fine. >=20 > > -- section 12 and subsections: > > > > I was surprised to see more apparently normative material after the > > non-normative guidance sections. I think it would improve the = organization to > > put this closer to the normative rules for UAs. >=20 > We can move section 12 up ahead of the non-normative guidance = sections. I think that would help, thanks. >=20 >=20 > > > > -- section 14.1, 4th paragraph (first non-bulleted paragraph = following bullet > > list) > > > > This issue is only true for proxies that act as a TLS MiTM, right? >=20 > yes. >=20 >=20 > > Would > > proxies that tunnel TLS via the CONNECT method have this issue? >=20 > I don't think so in the general case. >=20 > I'm not sure what terminology to use to differentiate such proxies if = this is a detail worth addressing. >=20 Okay >=20 > thanks again, >=20 > =3DJeffH >=20 >=20 >=20 >=20 >=20 >=20 From ben@nostrum.com Thu Aug 2 15:54:12 2012 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 3DCF811E8087; Thu, 2 Aug 2012 15:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 9BLtIgOAPNJW; Thu, 2 Aug 2012 15:54:11 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D23A711E8125; Thu, 2 Aug 2012 15:54:10 -0700 (PDT) Received: from dhcp-4516.meeting.ietf.org (dhcp-4516.meeting.ietf.org [130.129.69.22]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q72Ms8Gd041594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Aug 2012 17:54:09 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ben Campbell In-Reply-To: <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> Date: Thu, 2 Aug 2012 15:54:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50161BD5.7040901@KingsMountain.com> <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> To: =JeffH X-Mailer: Apple Mail (2.1485) Received-SPF: pass (nostrum.com: 130.129.69.22 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Thu, 02 Aug 2012 16:32:32 -0700 Cc: General Area Review Team , IETF WebSec WG , draft-ietf-websec-strict-transport-sec.all@tools.ietf.org, IETF Discussion List Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Thu, 02 Aug 2012 22:54:12 -0000 Jeff and I spoke f2f. Pending actual text, I believe we have resolutions = to all of my comments save those about an extension registry, which Jeff = will discuss with other interested parties. Thanks! Ben. On Aug 2, 2012, at 10:46 AM, Ben Campbell wrote: > Hi, thanks for the response. Comments inline: >=20 > On Jul 29, 2012, at 10:29 PM, =3DJeffH = wrote: >>=20 >>> -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, = that >>> should be explicitly flagged and mentioned in the abstract. >>=20 >> Good question, I don't believe we've discussed this possibility = directly in the websec wg. In looking at the RFCs that do update = RFC2616, it doesn't look like draft-ietf-websec-strict-transport-sec = (HSTS) is of that ilk. >>=20 >> However, it nominally appears that an argument could be made that = it'd be appropriate to update RFC2818 via = draft-ietf-websec-strict-transport-sec, specifically with regards to = Section 2.1. Connection Initiation. >>=20 >> Though, RFC2818 is Informational, which may be an issue (?). Also, = perhaps this is something to more appropriately do via a standards-track = rfc2818bis, i.e., have the latter reference the HSTS spec. >>=20 >> this is something to discuss this coming week @IETF-84 Vancouver it = seems. >>=20 >>=20 >=20 > I will comment on this in response to your post-meeting email. >=20 >=20 >>> -- I did not find any guidance on how to handle UAs that do not = understand >>> this extension. I don't know if this needs to be normative, but the = draft >>> should at least mention the possibility and implications. >>=20 >> Agreed. My -12 working copy now contains these new subsections.. >>=20 >> ### >> 10. Server Implementation and Deployment Advice >>=20 >> This section is non-normative. >>=20 >> 10.1. Non-Conformant User Agent Considerations >>=20 >> Non-conformant UAs ignore the Strict-Transport-Security header = field, >> thus non-conformant user agents do not address the threats described >> in Section 2.3.1 "Threats Addressed". Please refer to Section 14.1 >> "Non-Conformant User Agent Implications" for further discussion. >>=20 >> . >> . >>=20 >> 14. Security Considerations >> . >> . >> 14.1. Non-Conformant User Agent Implications >>=20 >> Non-conformant UAs ignore the Strict-Transport-Security header = field, >> thus non-conformant user agents do not address the threats described >> in Section 2.3.1 "Threats Addressed". >>=20 >> This means that the web application and its users wielding non- >> conformant user agents will be vulnerable to both: >>=20 >> Passive network attacks due to web site development and = deployment >> bugs: For example, if the web application contains any insecure, >> non-"https", references to the web application server, and if not >> all of its cookies are flagged as "Secure", then its cookies will >> be vulnerable to passive network sniffing, and potentially >> subsequent misuse of user credentials. >>=20 >> Active network attacks: If an attacker is able to place a man-in- >> the-middle, secure transport connection attempts will likely = yield >> warnings to the user, but without HSTS Policy being enforced, the >> present common practice is to allow the user to "click-through" >> and proceed. This renders the user and possibly the web >> application open to abuse by such an attacker. >>=20 >> This is essentially the status-quo for all web applications and = their >> users in the absence of HSTS Policy. >> ### >=20 > That's all good text, but I'm not sure it actually captures my = concern. >=20 > =46rom the server's perspective, the fact that non-conformant UAs may = exist, the server cannot assume that UAs will honor the extension. This = means that a UA might attempt unprotected access to some resource = assumed to be protected by this extension. That is, the server can't = merely select the extension and forget about things--it still needs to = to take the same care to avoid leaking resources over unprotected = connections that it would need to do if this extension did not exist in = the first place. >=20 > I think this is implied by your last sentence above, but it would be = better to say it explicitly. >=20 >=20 >>=20 >>>=20 >>> -- How should a UA handle potential conflicts between a the policy = record >>> that includes the includeSubdomain, and any records for subdomains = that might >>> have different parameters? >>=20 >> this is in the draft. the short answer is that at policy enforcement = time, "superdomain matches win". >>=20 >> At "noting an HSTS Host" time, the HSTS host's policy (if expressed) = is noted regardless of whether there are superdomain HSTS hosts = asserting "includeSubDomains". >>=20 >> perhaps this needs to be made more clear? >=20 > Maybe I'm missing something, but I'm not getting that answer from the = text. Can you point out the specific language? >=20 >>=20 >>=20 >>>=20 >>> -- section 6.1: >>>=20 >>> The draft mentions that directives may be extended, but defers = creation of an >>> IANA registry to the time of first extension. IANA registries are = not >>> expensive; I suggest it be created now. If there's a good reason not = to, then >>> the draft should still address the specification policy for = extensions. >>>=20 >>> Also, do you expect that some future directive might need to have a >>> "required-to-understand" status? Given that this is a = security-affecting >>> extension, it seems likely. If so, then the mechanism for expressing = that >>> needs to be defined in this draft. >>=20 >>=20 >> These are good questions, and they beg the overall question of how = complex this simple solution really needs to be and whether we really = think we'll need any extensions. Something for us to discuss in the = working group meeting on Tue morning I think. >=20 > I will comment on this in the post-meeting mail. >=20 >>=20 >>>=20 >>> -- section 7.2: >>>=20 >>> Am I correct to assume that the server must never just serve the = content over >>> a non-secure connection? If so, it would be helpful to mention that, = maybe >>> even normatively. >>=20 >> It's a SHOULD, see the Note in that section, so it's already = effectively stated normatively, though one needs to understand HTTP = workings to realize it in the way you stated it above. Perhaps could = add a simple statement as you suggest to the intro para for section 7 = Server Processing Model, to address this concern? >>=20 >=20 > I think something of the form SHOULD redirect to HTTPS, but MUST NOT = under any circumstances send the content unprotected would improve the = text. That's probably already implied, and a reasonable implementor = wouldn't due it anyway. But my experience is that some readers will find = strange interpretations whenever you give them the wiggle room to do so, = so it's better to be explicit. >=20 >>=20 >>>=20 >>> -- section 8.4: >>>=20 >>> Does this imply a duty for compliant UAs to check for revocation one = way or >>> another? >>=20 >> yes. though, per other relevant specifications, as duly cited. AFAIK = the HSTS spec doesn't need to get into the details because the = underlying security transport specs, namely TLS, already do this. >=20 > If that duty already exists, then I see no reason to add it here. But = do the cited specs unambiguously _require_ revocation checks? I admit to = not being an expert here, but on a quick scan it seems more like they = say how you can do it, but do they say you have to?=20 >=20 > [...] >=20 >>=20 >>> -- section 1.2: >>>=20 >>> The description of indented notes is almost precisely the opposite = of how >>> they are described in the RFC editor's style guide. It describes = them as >>> "parenthetical" notes, which is how experienced RFC readers are = likely to >>> perceive them. While it doesn't say so explicitly, I think putting = normative >>> text in parenthetical notes should be avoided. If these are intended = to be >>> taken more strongly than that (and by the description, I take it = they should >>> be taken more strongly than the surrounding text), then I suggest = choosing a >>> stronger prefix than "NOTE:" >>=20 >> As it turns out, almost all the Notes are parenthetical. >>=20 >> I'll render the one(s) that are normative as a regular paragraph(s) = and leave the others as-is. Will that address your concern? >>=20 >=20 > Yes, thanks. >=20 >>=20 >>>=20 >>> -- section 7: >>>=20 >>> Does the reference to I-D.ietf-tls-ssl-version3 indicate a = requirement for >>> SSL3? >>=20 >> no, it's just that SSLv3 remains a fact of life and is referenced for = completeness' sake. >>=20 >>=20 >=20 > Okay. >=20 >>=20 >>>=20 >>> -- section 8.2, paragraph 5 (first non-numbered paragraph after = numbered >>> list) >>>=20 >>> To be pedantic, this could be taken to mean a congruent match only = applies if >>> the includeSubdomains flag is not present. I assume it's intended to = apply >>> whether or not the flag is present. >>=20 >> [ I am assuming you actually are referring to section 8.3, as section = 8.2 doesn't mention the includeSubdomains flag and does not contain a = numbered list. ] >>=20 >> yes, a congruent match is intended to apply whether or not the flag = is present. >>=20 >>=20 >=20 > yes, I meant 8.3. And on re-reading, I think the text is fine. >=20 >>=20 >>> -- section 12 and subsections: >>>=20 >>> I was surprised to see more apparently normative material after the >>> non-normative guidance sections. I think it would improve the = organization to >>> put this closer to the normative rules for UAs. >>=20 >> We can move section 12 up ahead of the non-normative guidance = sections. >=20 > I think that would help, thanks. >=20 >>=20 >>=20 >>>=20 >>> -- section 14.1, 4th paragraph (first non-bulleted paragraph = following bullet >>> list) >>>=20 >>> This issue is only true for proxies that act as a TLS MiTM, right? >>=20 >> yes. >>=20 >>=20 >>> Would >>> proxies that tunnel TLS via the CONNECT method have this issue? >>=20 >> I don't think so in the general case. >>=20 >> I'm not sure what terminology to use to differentiate such proxies if = this is a detail worth addressing. >>=20 >=20 > Okay >=20 >>=20 >> thanks again, >>=20 >> =3DJeffH >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From ynir@checkpoint.com Tue Aug 7 05:27:24 2012 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 44B6921F8602 for ; Tue, 7 Aug 2012 05:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.366 X-Spam-Level: X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, 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 i35uVEDA-AYM for ; Tue, 7 Aug 2012 05:27:23 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1324B21F8600 for ; Tue, 7 Aug 2012 05:27:22 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q77CRLp6002220 for ; Tue, 7 Aug 2012 15:27:21 +0300 X-CheckPoint: {502106D4-1-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 15:27:20 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 7 Aug 2012 15:27:19 +0300 From: Yoav Nir To: IETF WebSec WG Date: Tue, 7 Aug 2012 15:27:18 +0300 Thread-Topic: Meeting Minutes Thread-Index: Ac10l/xLB29X2JSaR2KDM1DahDOIew== Message-ID: <8046EBF7-1B69-449E-A12D-FBAF754CB5B7@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11f5a82712b45f89a2eb8b16762b167c390fd7de23 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [websec] Meeting Minutes 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: Tue, 07 Aug 2012 12:27:24 -0000 Hi all I have uploaded the minutes from last week's meeting. The URL is http://www= .ietf.org/proceedings/84/minutes/minutes-84-websec Please send corrections to Alexey, Tobias, or me. Thanks again to Ted Hardie for taking the notes. Yoav From Jeff.Hodges@KingsMountain.com Thu Aug 9 15:09:53 2012 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 8AF8421F86AD for ; Thu, 9 Aug 2012 15:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.561 X-Spam-Level: X-Spam-Status: No, score=-99.561 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 bEAzya51nVRP for ; Thu, 9 Aug 2012 15:09:52 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 8498221F8606 for ; Thu, 9 Aug 2012 15:09:52 -0700 (PDT) Received: (qmail 28696 invoked by uid 0); 9 Aug 2012 22:09:51 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 9 Aug 2012 22:09:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yuFuPHKxRZWtxQDPeaT8duNauGgb8cVF2biruB7U3II=; b=NNAT759sy301VaX53y74dj3O+P0JXCjgK2HVuqk2L2iKeE/K9I1Gl90toOilxW9eOgVjM8YTB18U7hwT6PFamj8YfbnzWUZ6/ZiY0ZTt5zELNT4fJMXFlEKlLjV++iCC; Received: from [24.4.122.173] (port=38213 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SzavP-0004t1-MQ; Thu, 09 Aug 2012 16:09:51 -0600 Message-ID: <5024352D.4040604@KingsMountain.com> Date: Thu, 09 Aug 2012 15:09:49 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: Ben Campbell Subject: [websec] handling STS header field extendability 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: Thu, 09 Aug 2012 22:09:53 -0000 Hi, here's a write-up on the background of, and proposed resolution to th= e=20 question of handling STS header field extendability more properly in the = spec. I also pose the question of which IANA policy to declare, down at the ver= y end. thanks, =3DJeffH Background: ---------- We've defined the Strict-Transport-Security (STS) header field like so.. Strict-Transport-Security =3D "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] ) directive =3D directive-name [ "=3D" directive-valu= e ] directive-name =3D token directive-value =3D token | quoted-string =2E.such that the definition of new directives is open-ended, i.e., the S= TS header field is extendable. draft-ietf-websec-strict-transport-sec-11 presently states at the end of = section=20 6.1.. Additional directives extending the semantic functionality of the STS= header field can be defined in other specifications, with a registry defined for them at such time. The only extensions we'd discussed in the past were the CertPinning, Lock= CA, LockEV. We've decided that cert pinning is an intersecting but orthogona= l policy to HSTS, and thus best handled at this point via a separate header= field. Also, the various LockFoo notions should be addressed in a cert pinning p= olicy context (i mentioned this in the WG session at IETF-82 Taipei). Thus we don't have any presently anticipated extensions for the STS heade= r field. However, I don't believe we wish to change the (implicitly extensible) ma= ner in=20 which the ABNF is specified, nor necessarily close the door to defining s= ome=20 extension if we happen to come up with an appropriate need. The IETF-84 Vancouver, WebSec WG meeting minutes [1] state on this topic.= =2E The group then discussed the registry management, particularly around =93mandatory to understand=94 extensions. The sense of the room was th= at the group did not want to create mandatory to understand extensions ever. = If such extensions are needed, they will need a new header. Where the dra= ft says other specifications can update this one, say that any necessary registries may be created when such an update comes around. Note that -11 already states that a registry should be created at that ti= me. Ben=20 indicated in his review that it isn't sufficient in his view (below). Ben replied directly to me regarding the meeting minutes... > > I think we may be conflating two mostly orthangonal comments: > (a) > -- If the working group doesn't expect "mandatory to understand" exten= sions, > then I'm fine with it, other than thinking it might be worth noting th= at any > such extensions must be safe to ignore. > (b) > -- My questions about a registry don't depend on the mandatory to unde= rstand. > I'm skeptical of any draft that says "you can extend this, but we will= leave > the creation of a registry until someone actually does it." In particu= lar, > this defers making decisions about the documentation policy for extens= ions > (rfc5226 section 4.1), which is rarely a good idea. The only situation= where > it seems to make sense to defer the registry would be if you really di= dn't > expect any extensions--in which case the draft probably shouldn't ment= ion > extending it. > > That all being said, please keep in mind that I, as a gen-art reviewer= , am > only offering my opinion like anyone else. It's up to the work group a= nd the > ADs to decide if they agree with me or not. So it's okay to say "We di= sagree > with Ben here, and choose to leave it as is". Proposed Resolution: ------------------- For (a) The spec already notes that UAs must ignore unrecognized directives. in a= ny case=20 I've composed a note regarding furture-defined directives being ignored b= y=20 (legacy) UAs. For (b) Alter the spec text to include a reference of the required IANA Policy fo= r any=20 defined registry. NOTE: we need to decide the type of IANA Policy (more below) The spec text I now have in my -12 working copy at the end of section 6.1= is.. Additional directives extending the semantic functionality of the STS= header field can be defined in other specifications, with a registry (having an IANA policy definition of FOO [RFC5226]) defined for them at such time. NOTE: Such future directives will be ignored by UAs implementing only this specification, as well as by generally non- conforming UAs. See Section 14.1 "Non-Conformant User Agent Implications" for further discussion. We need to decide what IANA policy definition [RFC5226] we wish to declar= e for=20 FOO in the above text. Since HSTS is a security policy, I lean towards wanting to have relativel= y=20 rigorous review applied to any registry and its contents created for HSTS= =20 directives and thus am thinking a policy of "IETF Review" is what we ough= t to=20 state here. thoughts? [1] https://www.ietf.org/proceedings/84/minutes/minutes-84-websec --- end From alexey.melnikov@isode.com Fri Aug 10 01:55:37 2012 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 8DA4F21F841B; Fri, 10 Aug 2012 01:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] 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 ROKsW45Fovmy; Fri, 10 Aug 2012 01:55:37 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7821F852C; Fri, 10 Aug 2012 01:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344588934; d=isode.com; s=selector; i=@isode.com; bh=00/1+9E+AM7GqxYBAXVF+YQh/LQlEXBj8s3wxQ/OuJ8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ncGxuHp0wlue+qJqcRblnzyg4u4o351jL53HTSWq/NtO8sShNNfZnWRsqPQ2bQ1McIQWEA 9APIDlfHgo0XzhOs14XgV9ih2FtGFZDayBHPJZN9suNB8H3W7CBwqepyG03zutOipZpDgy Z4NyOgT5p1jF5tGZHBKnVxHiXIw0dwI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 10 Aug 2012 09:55:33 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <502441B7.8020001@isode.com> Date: Fri, 10 Aug 2012 00:03:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Ben Campbell , =JeffH References: <50161BD5.7040901@KingsMountain.com> <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> In-Reply-To: <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General Area Review Team , IETF WebSec WG , draft-ietf-websec-strict-transport-sec.all@tools.ietf.org, IETF Discussion List Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Fri, 10 Aug 2012 08:55:37 -0000 On 02/08/2012 10:46, Ben Campbell wrote: > Hi, thanks for the response. Comments inline: > > On Jul 29, 2012, at 10:29 PM, =JeffH wrote: [...] >>> -- section 7.2: >>> >>> Am I correct to assume that the server must never just serve the content over >>> a non-secure connection? If so, it would be helpful to mention that, maybe >>> even normatively. >> It's a SHOULD, see the Note in that section, so it's already effectively stated normatively, though one needs to understand HTTP workings to realize it in the way you stated it above. Perhaps could add a simple statement as you suggest to the intro para for section 7 Server Processing Model, to address this concern? >> > I think something of the form SHOULD redirect to HTTPS, but MUST NOT under any circumstances send the content unprotected would improve the text. Sounds good to me. (And yes, this is implied, but it doesn't hurt to state explicitly.) > That's probably already implied, and a reasonable implementor wouldn't due it anyway. But my experience is that some readers will find strange interpretations whenever you give them the wiggle room to do so, so it's better to be explicit. From tobias.gondrom@gondrom.org Fri Aug 10 03:03:18 2012 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 A07C721F8645 for ; Fri, 10 Aug 2012 03:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.564 X-Spam-Level: X-Spam-Status: No, score=-97.564 tagged_above=-999 required=5 tests=[AWL=-2.203, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] 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 rtbTqWammlyy for ; Fri, 10 Aug 2012 03:03:18 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id A057C21F85F0 for ; Fri, 10 Aug 2012 03:03:17 -0700 (PDT) Received: (qmail 20391 invoked from network); 10 Aug 2012 12:03:11 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?) (94.194.102.93) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Aug 2012 12:03:11 +0200 Message-ID: <5024DC5E.60404@gondrom.org> Date: Fri, 10 Aug 2012 11:03:10 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: alexey.melnikov@isode.com References: <50161BD5.7040901@KingsMountain.com> <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> <502441B7.8020001@isode.com> In-Reply-To: <502441B7.8020001@isode.com> Content-Type: multipart/alternative; boundary="------------080205060203060004010107" Cc: ben@nostrum.com, ietf@ietf.org, gen-art@ietf.org, websec@ietf.org, draft-ietf-websec-strict-transport-sec.all@tools.ietf.org Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Fri, 10 Aug 2012 10:03:18 -0000 This is a multi-part message in MIME format. --------------080205060203060004010107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/08/12 00:03, Alexey Melnikov wrote: > On 02/08/2012 10:46, Ben Campbell wrote: >> Hi, thanks for the response. Comments inline: >> >> On Jul 29, 2012, at 10:29 PM, =JeffH >> wrote: > [...] >>>> -- section 7.2: >>>> >>>> Am I correct to assume that the server must never just serve the >>>> content over >>>> a non-secure connection? If so, it would be helpful to mention >>>> that, maybe >>>> even normatively. >>> It's a SHOULD, see the Note in that section, so it's already >>> effectively stated normatively, though one needs to understand HTTP >>> workings to realize it in the way you stated it above. Perhaps could >>> add a simple statement as you suggest to the intro para for section >>> 7 Server Processing Model, to address this concern? >>> >> I think something of the form SHOULD redirect to HTTPS, but MUST NOT >> under any circumstances send the content unprotected would improve >> the text. > > Sounds good to me. (And yes, this is implied, but it doesn't hurt to > state explicitly.) > >> That's probably already implied, and a reasonable implementor >> wouldn't due it anyway. But my experience is that some readers will >> find strange interpretations whenever you give them the wiggle room >> to do so, so it's better to be explicit. > > Agree with Alexey and Ben. Tobias --------------080205060203060004010107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/08/12 00:03, Alexey Melnikov wrote:
On 02/08/2012 10:46, Ben Campbell wrote:
Hi, thanks for the response.  Comments inline:

On Jul 29, 2012, at 10:29 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
 [...]
-- section 7.2:

Am I correct to assume that the server must never just serve the content over
a non-secure connection? If so, it would be helpful to mention that, maybe
even normatively.
It's a SHOULD, see the Note in that section, so it's already effectively stated normatively, though one needs to understand HTTP workings to realize it in the way you stated it above.  Perhaps could add a simple statement as you suggest to the intro para for section 7 Server Processing Model, to address this concern?

I think something of the form SHOULD redirect to HTTPS, but MUST NOT under any circumstances send the content unprotected would improve the text.

Sounds good to me. (And yes, this is implied, but it doesn't hurt to state explicitly.)

That's probably already implied, and a reasonable implementor wouldn't due it anyway. But my experience is that some readers will find strange interpretations whenever you give them the wiggle room to do so, so it's better to be explicit.


<hat="individual">
Agree with Alexey and Ben. Tobias


--------------080205060203060004010107-- From ben@estacado.net Fri Aug 10 07:19:17 2012 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 622DB21F8604; Fri, 10 Aug 2012 07:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 IqPgMkHDslNP; Fri, 10 Aug 2012 07:19:16 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9771121F85C3; Fri, 10 Aug 2012 07:19:16 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q7AEGWUQ049872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 09:16:38 -0500 (CDT) (envelope-from ben@estacado.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ben Campbell In-Reply-To: <502441B7.8020001@isode.com> Date: Fri, 10 Aug 2012 09:16:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50161BD5.7040901@KingsMountain.com> <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com> <502441B7.8020001@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1485) X-Mailman-Approved-At: Fri, 10 Aug 2012 08:16:33 -0700 Cc: Ben Campbell , IETF Discussion List , General Area Review Team , IETF WebSec WG , draft-ietf-websec-strict-transport-sec.all@tools.ietf.org Subject: Re: [websec] [Gen-art] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Fri, 10 Aug 2012 14:19:17 -0000 Jeff and I had a f2f discussion about this point in Vancouver. To = paraphrase (and I assume he will correct me if if I mischaracterize = anything), Jeff indicated that this really wasn't a MUST level = requirement due to the variation and vagaries in application behavior = and abilities. Rather, it's more of a "do the best you can" sort of = thing. Specifically, he indicated that an implementation that chose to = go ahead and serve unprotected content due to the listed caveats on = redirecting to HTTPS would necessarily be out-of-compliance. If the requirement really that you SHOULD NOT (rather than MUST NOT) = serve unprotected content, then I think the original language is okay. Thanks! Ben. On Aug 9, 2012, at 6:03 PM, Alexey Melnikov = wrote: > On 02/08/2012 10:46, Ben Campbell wrote: >> Hi, thanks for the response. Comments inline: >>=20 >> On Jul 29, 2012, at 10:29 PM, =3DJeffH = wrote: > [...] >>>> -- section 7.2: >>>>=20 >>>> Am I correct to assume that the server must never just serve the = content over >>>> a non-secure connection? If so, it would be helpful to mention = that, maybe >>>> even normatively. >>> It's a SHOULD, see the Note in that section, so it's already = effectively stated normatively, though one needs to understand HTTP = workings to realize it in the way you stated it above. Perhaps could = add a simple statement as you suggest to the intro para for section 7 = Server Processing Model, to address this concern? >>>=20 >> I think something of the form SHOULD redirect to HTTPS, but MUST NOT = under any circumstances send the content unprotected would improve the = text. >=20 > Sounds good to me. (And yes, this is implied, but it doesn't hurt to = state explicitly.) >=20 >> That's probably already implied, and a reasonable implementor = wouldn't due it anyway. But my experience is that some readers will find = strange interpretations whenever you give them the wiggle room to do so, = so it's better to be explicit. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From Jeff.Hodges@KingsMountain.com Fri Aug 10 14:34:20 2012 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 A43EC21F863F for ; Fri, 10 Aug 2012 14:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.099 X-Spam-Level: X-Spam-Status: No, score=-101.099 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 93CR+9uRC64M for ; Fri, 10 Aug 2012 14:34:20 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id F0F9021F861B for ; Fri, 10 Aug 2012 14:34:19 -0700 (PDT) Received: (qmail 23990 invoked by uid 0); 10 Aug 2012 21:33:58 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 10 Aug 2012 21:33:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=zQ42lv4nJ35pqAeoI1DBK7QuzkWuO0maehLqEdWcNw4=; b=nP7T9HTdfxO9PV1OTuC7BwjLaByYiMHmmqcpWPoSCFT+jwlIiE5BqcKI9hkfVMcVRuPJ3wEKYorwfWULZSHCIfKDfdtB7Ypex/bymket+MziQjEpFNwgTfP/43MTahNx; Received: from [24.4.122.173] (port=41385 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SzwqC-0001Ci-He; Fri, 10 Aug 2012 15:33:56 -0600 Message-ID: <50257E43.8010005@KingsMountain.com> Date: Fri, 10 Aug 2012 14:33:55 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Alexey Melnikov , Tobias Gondrom , Ben Campbell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: General Area Review Team , IETF WebSec WG , draft-ietf-websec-strict-transport-sec.all@tools.ietf.org, IETF Discussion List Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Fri, 10 Aug 2012 21:34:20 -0000 Thanks Ben. > Jeff and I had a f2f discussion about this point in Vancouver. To paraphrase > (and I assume he will correct me if if I mischaracterize anything), Jeff > indicated that this really wasn't a MUST level requirement due to the > variation and vagaries in application behavior and abilities. Yes, see the NOTE in section 7.2. > Rather, it's > more of a "do the best you can" sort of thing. Specifically, he indicated > that an implementation that chose to go ahead and serve unprotected content > due to the listed caveats on redirecting to HTTPS would necessarily be > out-of-compliance. I presume you actually mean "not necessarily", which would then be correct, unless I'm misunderstanding something. > If the requirement really that you SHOULD NOT (rather than MUST NOT) serve > unprotected content, then I think the original language is okay. agreed. thanks, =JeffH From palmer@google.com Fri Aug 10 14:52:26 2012 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 C062F21F8645 for ; Fri, 10 Aug 2012 14:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 qslHFyUJGpMP for ; Fri, 10 Aug 2012 14:52:26 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C217C21F853B for ; Fri, 10 Aug 2012 14:52:24 -0700 (PDT) Received: by lahm15 with SMTP id m15so1150892lah.31 for ; Fri, 10 Aug 2012 14:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=WGDzmQViYNxFQdE9OvmOw2o2HnNnuupOwkoI5xItsrc=; b=R603AD4nQkFdfAFbf42nv4WtvcFpmVf5+7+I0LVdPaN9OlTFECH6EJjVeY9E939qj3 gxeYRJajMVWipm0KoVMiNuEP9aHLnnKbercO6X5FEvC+q4tjs7YVSgKXvXiSMAXBJFhG fofCSm/R+ROfT+FMPCR6EafcUryI2e3danYeiXROjhz2NrjXs+/iBxW83sebb5cnYR4L b7rY1q/OXZCL8LgTJLYICp78Iw9ay1U0vun0bUpeR1e8LCiZRcwl6OCjJXy2GvDJDsN5 YpNkxUBkn4FTsNgpIBDcdATK1F7ULfXLx04nVDz5xIR4A9TwlbDO87B29UZWo8HQFH+b oEYw== X-Google-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:x-system-of-record:x-gm-message-state; bh=WGDzmQViYNxFQdE9OvmOw2o2HnNnuupOwkoI5xItsrc=; b=KO9tT2HTTbQyj/19kcPOz79v8b+GSgF7GIz+9Hw832xFeiUu4oq8dylUZqPUPvIPxk QlBJVpWtGTCkFiSThphf1bh7m+oV0Ty4FHPuL7b/rk9HFXGb5mKzh9yADLc7Y2YlC2mH GvJLoXV76hiZoaO5UQzsM5OkC6gh+6FvqicakkstAjPWesu/wN2ClUS50EaVpjj+WCV7 qk8VFl70VojeDDFLah+/SttETuZNOT2QL41HnHS9iEPo8xCOPSheCrH4ireubjvoebQv eI2uA4UuIhcTXndOMzMhh5suRgtOyfCkNrW9JJPIEb0uX733ihfFQLfhZigwDp/jIkwk l8lQ== Received: by 10.112.43.98 with SMTP id v2mr3004553lbl.1.1344635543631; Fri, 10 Aug 2012 14:52:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.43.98 with SMTP id v2mr3004536lbl.1.1344635543443; Fri, 10 Aug 2012 14:52:23 -0700 (PDT) Received: by 10.112.77.4 with HTTP; Fri, 10 Aug 2012 14:52:23 -0700 (PDT) In-Reply-To: <5024352D.4040604@KingsMountain.com> References: <5024352D.4040604@KingsMountain.com> Date: Fri, 10 Aug 2012 14:52:23 -0700 Message-ID: From: Chris Palmer To: "=JeffH" Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkL1u3Do6FjQS4kHdfFmfY1TYnHSguc06VzLtmFKv82FpfN0xzWpEE97w/NiXmQvIw5dcUJH0YEDgAxKSyl6l24cjBpAIFLxf6RclqG75rMhIm99KzbscEm3gEMp7pqtznQXVWUqY3qy4ss3DryXg6SIQ0MgfTAOlvs6Ul+kzf/Z5Z5MsLZatF6oCe0SXOYAVwRAV18 Cc: Ben Campbell , IETF WebSec WG Subject: Re: [websec] handling STS header field extendability 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: Fri, 10 Aug 2012 21:52:26 -0000 On Thu, Aug 9, 2012 at 3:09 PM, =JeffH wrote: > The only extensions we'd discussed in the past were the CertPinning, LockCA, > LockEV. We've decided that cert pinning is an intersecting but orthogonal > policy to HSTS, and thus best handled at this point via a separate header > field. > Also, the various LockFoo notions should be addressed in a cert pinning > policy > context (i mentioned this in the WG session at IETF-82 Taipei). Please forgive my ignorance, but do LockCA and/or LockEV offer any functionality that you can't already get with public key pinning as currently specified? You can pin to a given CA's public key(s), and you can pin to any given EV issuers' public keys. From palmer@google.com Fri Aug 10 15:20:25 2012 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 48CC911E80BF for ; Fri, 10 Aug 2012 15:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 hyUHvzRJWRq8 for ; Fri, 10 Aug 2012 15:20:24 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEA8621F85E6 for ; Fri, 10 Aug 2012 15:20:23 -0700 (PDT) Received: by lahm15 with SMTP id m15so1159780lah.31 for ; Fri, 10 Aug 2012 15:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=FTmmwBpKGjH+Tbnx5ZkrEUYsGph/GBInZy34ikeBInE=; b=YuthJyKzNEAkdwrV0uSD9UV5rkXvG4N6ZnY7q9m7tYuCoN3qgrpOqpQReRoF0ovabO I0+ycuMLW1/AbuG85sw2MVHd8mkK0uF70nNKiMag4lK5+9rNb1RM9etbD9YFx6AciC9r R2QY6Glvtn/mfpb/kQo/7rYecwqOjR0JDNab5MOQH2rwr60icnGk7CgxoTv0Okwmo4Lr 1Hsc/byl3JyFTXV97Hrg7/gLsaDrioUsx/WOixQiXoCtXg/+CBiZ8HTzBBim4HP42YMB BKirPKuyoIXZtqcnN3m+NCxXlrffjgyWQUf8oKK5Hv2xuC5p93i0d5ucBsG82fOWP40i PJJQ== X-Google-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:x-system-of-record :x-gm-message-state; bh=FTmmwBpKGjH+Tbnx5ZkrEUYsGph/GBInZy34ikeBInE=; b=D12dJCp5OGJ902dp8fj/PQFf4GKbYyQ7a4JOsP78+CpZw1SB87S9u6akj20iAnbiuJ ICyntSI6NVRKVyB9XTdQc1L1JTMnx56e/XYQCqrQSYa69wzFoimXv9eWUzK6OGOSBIjL D23LqBZOUcPvIAwCQ0JR3oVtMFSTkXxmo+TMkKkQHi0voX7xkZuWtzP4SCTBtd6RXrmf fySt54cMppRtPwc4q2Gtdj9gU1fHIWKVmQsqaiSJj6/AaMhp3PWXwzj6cTzYUIr4OQr+ /kaUzk8TtsXhBBROOHFviiVOZ4lb8QwJwXmTleBVwRJxN/VQ2j7k4DD2imxNsjF/uxDK ZDbQ== Received: by 10.152.111.71 with SMTP id ig7mr4303285lab.28.1344637222718; Fri, 10 Aug 2012 15:20:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.111.71 with SMTP id ig7mr4303269lab.28.1344637222530; Fri, 10 Aug 2012 15:20:22 -0700 (PDT) Received: by 10.112.77.4 with HTTP; Fri, 10 Aug 2012 15:20:22 -0700 (PDT) In-Reply-To: <4FCF894B.8080002@gondrom.org> References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> Date: Fri, 10 Aug 2012 15:20:22 -0700 Message-ID: From: Chris Palmer To: Tobias Gondrom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlgCWQpLBUJCtLrnE9UECixZZC6AdBUZRHQleP7GT37kfbb9jKNPg3mqo+RTc44xxM6LRtKNCOJRpwhVm3dqZ3yMiQWho6sdWRSO6Xs5bpDQqDbEImE400BdbKOyVOBfDS9+jjVu4U4wVA6mq+L0QqUY6dn6jcI3WTaOQ4bJ+0/N+vpi0669POpLQnrg1xWa8onDT/9 Cc: Chris Evans , websec@ietf.org, paul.hoffman@vpnc.org, saag@ietf.org, turners@ieca.com, Moxie Marlinspike Subject: Re: [websec] [saag] Pinning 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: Fri, 10 Aug 2012 22:20:25 -0000 Hi all, Resurrecting this ancient thread, and explicitly including Moxie and Trevor in case they aren't already on any of the relevant mailing lists. So ultimately I do think we should decide on either HPKP or TACK, but that we should make that decision after there has been some real-world deployment experience with both (or, sadly, real-world non-deployment of one or both). Additionally, HPKP and TACK might converge, more or less. I have plans to publish a new HPKP I-D that borrows some of TACK's pin activation and expiration ideas, for example. Additionally, one of the main criticisms of HPKP is that it is tied to HTTP. I currently don't consider that a huge problem =E2=80=94 even though = I consider TACK's TLS-generic-ness a nice benefit =E2=80=94 for several reaso= ns: * HTTPS is the big, important application that we need to secure right now. * IMAPS and POPS are surely on the list too, right after HTTPS; but specifying "IPKP" and "PPKP" is likely to be relatively straightforward once we get HPKP working. * It's not clear that SMTP over TLS is very beneficial, because you can't stop delivery due to pin validation failure (or really even regular old X.509 failure). You could use certificate errors as soft-fail spam signals, but you can in principle do that now, too, without explicit pinning. I don't know how much benefit you'd get from using pin validation failure as a spam signal. * SSH already has PKP. :) * The other common application protocols, like SIP, XMPP, and friends, are likely to also be pretty easy to extend in a manner similar to HPKP, "IPKP", and "PPKP". And finally, as Ben Laurie pointed out, there is also Certificate Transparency. I personally consider the "public log" class of solutions (of which CT is a leading member, along with Sovereign Keys) to be The Real Solution. Pinning-like solutions (including HPKP and TACK) are a good, quick fix =E2=80=94 as long as they are quick and simple. On Wed, Jun 6, 2012 at 9:46 AM, Tobias Gondrom wrote: > Sean et al., > > > I agree with Paul and Yoav and think the coordination between dane and > websec on HSTS and key-pinning is ok. Both WGs are aware of potential > coordination issues when mechanisms in both (DNSSEC and HTTP header) will= be > implemented eventually. I don't think we need an operations statement yet= . > Maybe at some point in the future an informational Best Practice or if yo= u > wish a Std Track can help. > > With regards to draft-perrin-tls-tack and draft-ietf-websec-key-pinning, = I > am not so sure about potential conflicts here and whether we need or want > both. > > > Best regards, Tobias > > > Ps.: > > And on a personal note, one thing I am not so happy about is that I can s= ee > from the tls-tack draft, that the authors are aware of key-pinning (which= is > nice) and perceive that there would be flaws, yet they chose to not post > their comments on it to websec nor inform the WG about their new draft. > > To make it easier in the future to coordinate the two drafts and possibly > discuss and decide whether to boil down to one, it might make sense to > inform websec about draft-perrin-tls-tack and have a discussion about it = at > some point there. > Just my 5cents. > > > > > > On 05/06/12 23:01, Paul Hoffman wrote: >> >> On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote: >> >>>> The similarity of pinning and DANE has been discussed before. DANE >>>> relies on DNSSEC being deployed, which key-pinning does not. >> >> Correct. Further, key-pinning in HTTP only applies to HTTP and relies on >> the client being able to establish a TLS session using non-key-pinning >> semantics. Key-pinning in TLS relies works with any lower-layer protocol= and >> relies on the client being able to establish a TLS session using >> non-key-pinning semantics. >> >>>> Come to think of it, the draft needs a section comparing with DANE, bu= t >>>> that's for another thread. >>>> >>>> draft-perrin-tls-tack seems to tackle the same problem as key-pinning. >>>> Instead of the pins getting attested to in HTTP headers, you have a sp= ecial >>>> public/private key pair, that you use to sign the SPKI from the server >>>> certificate within the a TLS extension. Like key-pinning there's a TOF= U >>>> element here, because the client only learns about the special key whe= n it >>>> encounters it in a TLS handshake. >>>> >>>> The obvious question is why would we need both key-pinning and tack. >> >> It would be clearer if you said "both key-pinning in HTTP and key-pinnin= g >> in TLS (tack)". >> >> --Paul Hoffman >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From ben@estacado.net Fri Aug 10 14:58:38 2012 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 1E60221F865E; Fri, 10 Aug 2012 14:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 v1bz59dq3Dy9; Fri, 10 Aug 2012 14:58:37 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 69D6221F865C; Fri, 10 Aug 2012 14:58:36 -0700 (PDT) Received: from [10.12.11.64] ([10.12.11.64]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q7ALttiU010516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 16:55:55 -0500 (CDT) (envelope-from ben@estacado.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Ben Campbell In-Reply-To: <50257E43.8010005@KingsMountain.com> Date: Fri, 10 Aug 2012 16:55:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <570BD336-2C91-4C7E-AC03-9FD5423AEB35@estacado.net> References: <50257E43.8010005@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1485) X-Mailman-Approved-At: Fri, 10 Aug 2012 16:43:00 -0700 Cc: Ben Campbell , IETF Discussion List , General Area Review Team , IETF WebSec WG , draft-ietf-websec-strict-transport-sec.all@tools.ietf.org Subject: Re: [websec] [Gen-art] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Fri, 10 Aug 2012 21:58:38 -0000 On Aug 10, 2012, at 4:33 PM, =3DJeffH = wrote: > Thanks Ben. >=20 > > Jeff and I had a f2f discussion about this point in Vancouver. To = paraphrase > > (and I assume he will correct me if if I mischaracterize anything), = Jeff > > indicated that this really wasn't a MUST level requirement due to = the > > variation and vagaries in application behavior and abilities. >=20 > Yes, see the NOTE in section 7.2. >=20 > > Rather, it's > > more of a "do the best you can" sort of thing. Specifically, he = indicated > > that an implementation that chose to go ahead and serve unprotected = content > > due to the listed caveats on redirecting to HTTPS would necessarily = be > > out-of-compliance. >=20 > I presume you actually mean "not necessarily", which would then be = correct, unless I'm misunderstanding something. Oops, you are correct, that's a typo. >=20 >=20 > > If the requirement really that you SHOULD NOT (rather than MUST NOT) = serve > > unprotected content, then I think the original language is okay. >=20 > agreed. >=20 > thanks, >=20 > =3DJeffH >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From Jeff.Hodges@KingsMountain.com Fri Aug 10 19:53:14 2012 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 C861A21F84B9 for ; Fri, 10 Aug 2012 19:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.412 X-Spam-Level: X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 khRKhA-+ptrl for ; Fri, 10 Aug 2012 19:53:14 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 2DBC621F84B3 for ; Fri, 10 Aug 2012 19:53:14 -0700 (PDT) Received: (qmail 24689 invoked by uid 0); 11 Aug 2012 02:52:52 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 11 Aug 2012 02:52:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=gO254EX9BSvkegsd6+csOkhsC5JANcYrpA75KrVCKnI=; b=PLjfsLevMLLc3VfcQ0hAaAVTXe0p5wA/gJXmyuFS96Kx7/yB0Tzx5eLpnO+JMElYaKqccFaZ7ZcJiVewM3x5eJIQvBh+vXMjrCghqnyW734pVuhXHx4YdKDbEpPFsO8W; Received: from [24.4.122.173] (port=42679 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T01oq-00053V-Dv; Fri, 10 Aug 2012 20:52:52 -0600 Message-ID: <5025C902.3060609@KingsMountain.com> Date: Fri, 10 Aug 2012 19:52:50 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] the (old) LockFoo ideas: LockCA, LockEV (was: handling STS header field extendability) 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: Sat, 11 Aug 2012 02:53:14 -0000 > On Thu, Aug 9, 2012 at 3:09 PM, =JeffH wrote: > >> The only extensions we'd discussed in the past were the CertPinning, >> LockCA, LockEV. We've decided that cert pinning is an intersecting but >> orthogonal policy to HSTS, and thus best handled at this point via a >> separate header field. Also, the various LockFoo notions should be >> addressed in a cert pinning policy context (i mentioned this in the WG >> session at IETF-82 Taipei). > > Please forgive my ignorance, no worries, these were nascent ideas we discussed in the past in the context of HSTS, mostly just at past websec wg sessions. > but do LockCA and/or LockEV offer any > functionality that you can't already get with public key pinning as > currently specified? probably not (they were mostly off-the-cuff ideas) > You can pin to a given CA's public key(s), Yes, which provides essentially what we were imagining as LockCA functionality > and you can pin to any given EV issuers' public keys. yep. I didn't mean to imply that these LockFoo notions would necessarily pose new use cases for draft-ietf-websec-key-pinning -- the latter I-D probably already addresses them. HTH, =JeffH From Jeff.Hodges@KingsMountain.com Fri Aug 10 21:41:17 2012 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 69A6F21F8508 for ; Fri, 10 Aug 2012 21:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 pqQAKE5ZfQ5v for ; Fri, 10 Aug 2012 21:41:16 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 6A78021F8507 for ; Fri, 10 Aug 2012 21:41:15 -0700 (PDT) Received: (qmail 1457 invoked by uid 0); 11 Aug 2012 04:40:53 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 11 Aug 2012 04:40:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=pAUvay1+OwfsdgXlsoXr/7NnBbFxf3AmRbW1zQy4gVY=; b=2JCYYopKE5hWt5Dw40q4+QK9rfVYp5cy9gFeYYUfHvOmPlvmXnpiNztH2QgqqV4BHksahsz5o4n29WYkPHuzReCP/hzaT4KTHDRICE4juqTotMrD9ZmyokkLG14pjE4X; Received: from [24.4.122.173] (port=43149 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T03VN-0007RE-Lo; Fri, 10 Aug 2012 22:40:53 -0600 Message-ID: <5025E253.7070907@KingsMountain.com> Date: Fri, 10 Aug 2012 21:40:51 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Ben Campbell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: General Area Review Team , IETF WebSec WG , draft-ietf-websec-strict-transport-sec.all@tools.ietf.org, IETF Discussion List Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11 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: Sat, 11 Aug 2012 04:41:17 -0000 Hi, I believe I've made requite changes to draft-ietf-websec-strict-transport-sec per this thread as well as the WG f2f discussion @IETF-84 Vancouver and also my f2f discussion with Ben after the websec wg meeting. In the below I'm just going to try to identify the individual issues from Ben's review without quoting all the thread discussion, but also highlight the changes I have queued in my -12 working copy of draft-ietf-websec-strict-transport-sec. If the below looks nominally OK I can submit my -12 working copy, please let me know (Alexey/Barry). (note: I'm going to be mostly offline for the next several days) thanks, =JeffH ------ Ben's "minor items": M1) update 2818 ? >> -- Does this draft update any other RFCs (e.g. 2616 or 2818)? Maybe 2818, but based on the informational status of 2818, websec wg discussions, and discussions with Ben and EKR, there's no statement of updating 2818 in my -12 working copy. M2) non-conformant UAs ? >>> -- I did not find any guidance on how to handle UAs that do not >>> understand this extension. I don't know if this needs to be normative, >>> but the draft should at least mention the possibility and implications. >> >> Agreed. My -12 working copy now contains these new subsections.. >> >> >> > That's all good text, but I'm not sure it actually captures my concern. > > That is, the server can't merely select the extension and forget > about things--it still needs to to take the same care to avoid leaking > resources over unprotected connections that it would need to do if this > extension did not exist in the first place. > > I think this is implied by your last sentence above, but it would be better > to say it explicitly. I've added text to my -12 working copy, it now states... ### 14.1. Non-Conformant User Agent Implications Non-conformant user agents ignore the Strict-Transport-Security header field, thus non-conformant user agents do not address the threats described in Section 2.3.1 "Threats Addressed". This means that the web application and its users wielding non- conformant UAs will be vulnerable to both: o Passive network attacks due to web site development and deployment bugs: For example, if the web application contains any insecure, non-"https", references to the web application server, and if not all of its cookies are flagged as "Secure", then its cookies will be vulnerable to passive network sniffing, and potentially subsequent misuse of user credentials. o Active network attacks: For example, if an attacker is able to place a man-in-the- middle, secure transport connection attempts will likely yield warnings to the user, but without HSTS Policy being enforced, the present common practice is to allow the user to "click- through" and proceed. This renders the user and possibly the web application open to abuse by such an attacker. This is essentially the status-quo for all web applications and their users in the absence of HSTS Policy. Since web application providers typically do not control the type or version of UAs their web applications interact with, the implication is that HSTS Host deployers must generally exercise the same level of care to avoid web site development and deployment bugs (see Section 2.3.1.3) as they would if they were not asserting HSTS Policy. ### M3) the superdomain match wins (?) question (section 8.x generally) >>> -- How should a UA handle potential conflicts between a the policy >>> record that includes the includeSubdomain, and any records for subdomains >>> that might have different parameters? >> >> this is in the draft. the short answer is that at policy enforcement time, >> "superdomain matches win". >> >> At "noting an HSTS Host" time, the HSTS host's policy (if expressed) is >> noted regardless of whether there are superdomain HSTS hosts asserting >> "includeSubDomains". >> >> perhaps this needs to be made more clear? > > Maybe I'm missing something, but I'm not getting that answer from the text. In our f2f discussion, Ben and I agreed that we need to clear that we stop on first match when doing policy enforcement -- but it turns out to be not quite that simple, due to the includeSubDomains semantics. Here's the relvant text now in my -12 working copy, the alterations are in step 5... ### 8.3. URI Loading and Port Mapping Whenever the UA prepares to "load", also known as "dereference", any "http" URI [RFC3986] (including when following HTTP redirects [RFC2616]), the UA MUST first determine whether a domain name is given in the URI and whether it matches a Known HSTS Host, using these steps: . . 4. Otherwise, the substring is a given domain name, which MUST be matched against the UA's Known HSTS Hosts using the procedure in Section 8.2 "Known HSTS Host Domain Name Matching". 5. If when performing doman name matching, any superdomain match with an asserted includeSubDomains flag is found, or, if no superdomain matches with asserted includeSubDomains flags are found and a congruent match is found (with or without an asserted includeSubDomains flag), then before proceeding with the load: . . ### M4) section 6.1: handling header field extensibility [ see separate message entitled "handling STS header field extendability" ] section 7.2 must not serve insecure content? M5) section 7.2: state explicitly must not serve insecure content? no changes necessary, see relevant discussion in this thread. M6) section 8.4:formal duty for revocation checking ? Based on f2f discussions with Ben and EKR, I now have the following text in my -12 working copy, and have moved the references to RFC2560 & RFC5280 to Informational. The rationale is that revocation checking is not required by the TLS and PKIX specs, they just say "here's how you can do it", and there's not really an appropriate spec to point at (which would have any chance at all to be actually adhered to by UAs due to the rapidly evolving nature of our understanding of the efficacy and performance and utility of "classical" revocation checking). ### 8.4. Errors in Secure Transport Establishment When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 "User Agent Implementation Advice") if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking UAs employ such as via Certificate Revocation Lists (CRL) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560]. ### Ben's editorial items: E1) Unused Reference: 'RFC6376' -- done in -12 E2) fixup indented "Note:" such that one(s) that are normative as a regular paragraph(s) and leave the others as-is -- done in -12 E3) reference to SSLv3, ref 6101 informatively -- done in -12 E4) section 8.3 congruent match -- text is fine, no changes necessary E5) move section 12 up ahead of the non-normative guidance sections -- done in -12 E6) proxy sec cons apply to CONNECT proxy ? -- done in -12 ( noted that the type of proxy of concern is a "MITM non-transparent proxy", which ought to clarify that it's not a transparent HTTP CONNECT-based proxy. (I couldn't find any dominating terminology describing these beasts, it is all over the map, but maybe I'm missing something) ) --- end From tom@ritter.vg Sat Aug 11 07:42:52 2012 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 7BA1C21F857D for ; Sat, 11 Aug 2012 07:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF47lz9+8o1j for ; Sat, 11 Aug 2012 07:42:51 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9271721F8569 for ; Sat, 11 Aug 2012 07:42:51 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2593012vbb.31 for ; Sat, 11 Aug 2012 07:42:50 -0700 (PDT) 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=bcVTcevosZzRIAdlo7dIYmXIPxPA4BTgtdE7o9lQSB0=; b=lBjb/eNm3D0UgcViw6pamTWO61Y1DYONwoJkUka4nHLDQwJMsXidte6MQctKAXPsFo P+4Pgk9znsD/cSv1o0xeu0iKYhVInfevo0HzhvTQ2vYt3i8A25XFJIbiroZbmH8KMvEU 3io8YnEb06hC9BPLyGFBXaK+rdFIS3Cu1fcIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=bcVTcevosZzRIAdlo7dIYmXIPxPA4BTgtdE7o9lQSB0=; b=KKrpgl5Mf+qTyGCH1eeQ4qBE5S//AfvvCxvx5Lsdr4Oeai6LxVS3mCrbJW6eojD5rn oDYwhHS2KRbnRPZ2rcw6al+rBbSoDgddzI1HRsf8BsEAJGIE1d90QYLit/a+xz9nwvZe jgu2z/G1k+LEsb8WZYzp5xm1AqR2ezuPJ4O+1oY9zg1azDQhPed85cDoeqHs4gnc69kL 8I1c8McDK3ZVmIcMvicMWFU7OKHPyEp7ZgbuSb2/uZfTpCvego3lVhqM6awAxGadcVyf AmUDjSdYOqZ5c65UJP+aRkK0PBIqRSmdMNpkx/bbVauUf7oOzVf2BO/N7S+AC4fGsg/P a7PQ== Received: by 10.220.116.11 with SMTP id k11mr1920713vcq.74.1344696170762; Sat, 11 Aug 2012 07:42:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.145.163 with HTTP; Sat, 11 Aug 2012 07:42:30 -0700 (PDT) In-Reply-To: References: <5024352D.4040604@KingsMountain.com> From: Tom Ritter Date: Sat, 11 Aug 2012 10:42:30 -0400 Message-ID: To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlZb7AZ7T9vtFBzdjMpUnZ+cEYPnulsiFFHL9BJswlQXmQW6rUyz/i3X4D5hGo8hjoBuOve Cc: Ben Campbell , IETF WebSec WG Subject: Re: [websec] handling STS header field extendability 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: Sat, 11 Aug 2012 14:42:52 -0000 On 10 August 2012 17:52, Chris Palmer wrote: > Please forgive my ignorance, but do LockCA and/or LockEV offer any > functionality that you can't already get with public key pinning as > currently specified? You can pin to a given CA's public key(s), and > you can pin to any given EV issuers' public keys. I can't think of one for Lock CA; but LockEV could be useful for sites that want to deploy some additional measure, but can't/don't want to a) commit to a CA or b) enumerate all possible EV authorities. It should be ('should be', not 'is') more difficult to get a fraudulent EV certificate through trickery or treachery than a DV certificate. I don't think browsers differentiate between OV and DV in any meaningful way, but I could be wrong. -tom From paul.hoffman@vpnc.org Sat Aug 11 10:57:43 2012 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 D92D921F861C; Sat, 11 Aug 2012 10:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 0EB57QPjUIhy; Sat, 11 Aug 2012 10:57:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9521F8617; Sat, 11 Aug 2012 10:57:43 -0700 (PDT) Received: from [10.20.30.100] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7BHvdS8049125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Aug 2012 10:57:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: Date: Sat, 11 Aug 2012 10:57:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> To: Chris Palmer X-Mailer: Apple Mail (2.1278) Cc: IETF WebSec WG , IETF Security Area Advisory Group , Moxie Marlinspike Subject: Re: [websec] [saag] Pinning 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: Sat, 11 Aug 2012 17:57:44 -0000 On Aug 10, 2012, at 3:20 PM, Chris Palmer wrote: > Additionally, one of the main criticisms of HPKP is that it is tied to > HTTP. I am one of those people who expressed that criticism in the past. = Having said that: > I currently don't consider that a huge problem =97 even though I > consider TACK's TLS-generic-ness a nice benefit =97 for several = reasons: >=20 > * HTTPS is the big, important application that we need to secure right = now. >=20 > * IMAPS and POPS are surely on the list too, right after HTTPS; but > specifying "IPKP" and "PPKP" is likely to be relatively > straightforward once we get HPKP working. Fully agree to both. TACK is more general, but HPKP's specificity is an = advantage for deployability and interoperability, and other TLS-using = application protocols can copy what they need from it when it is = deployed. > * It's not clear that SMTP over TLS is very beneficial, because you > can't stop delivery due to pin validation failure (or really even > regular old X.509 failure). You could use certificate errors as > soft-fail spam signals, but you can in principle do that now, too, > without explicit pinning. I don't know how much benefit you'd get from > using pin validation failure as a spam signal. Even if you could, the SMTP community hasn't spent much effort and = thinking about the value of TLS failure as spam signals. Until they do, = it is not wise for us to gate our work on them. If they deal with it, = they can then deal with things like pinning issues. > * SSH already has PKP. :) And we can learn from that. And from the smiley. > * The other common application protocols, like SIP, XMPP, and friends, > are likely to also be pretty easy to extend in a manner similar to > HPKP, "IPKP", and "PPKP". Yes. > And finally, as Ben Laurie pointed out, there is also Certificate > Transparency. I personally consider the "public log" class of > solutions (of which CT is a leading member, along with Sovereign Keys) > to be The Real Solution. Pinning-like solutions (including HPKP and > TACK) are a good, quick fix =97 as long as they are quick and simple. "Here is what I say about them" proposals are orthogonal to "here is = what I say about myself" proposals and should not be confused with each = other. --Paul Hoffman= From trevp@trevp.net Sat Aug 11 11:16:04 2012 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 10EA421F84A1 for ; Sat, 11 Aug 2012 11:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivIc82d72dPR for ; Sat, 11 Aug 2012 11:16:03 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4432121F84B5 for ; Sat, 11 Aug 2012 11:16:03 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2482799ghb.31 for ; Sat, 11 Aug 2012 11:16:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=lTUibbTXkpNEO56DtfydqlyEzmEq5SzjN79KjpgVv0U=; b=J6XRpB9uMRz1PaYkxHf/9MY81yha81SUwP/V11YgTtOyzK8k/X9rpxKfwY1i3LZGjk bVw22fJIYI8TjCfcmW2ap4KvZEN1gaS8ohruzU2RAA+tOb/57F8YAmNbnuPvJQkWhla7 smA6AaPD/bY5dbzhZitq1Ot3BNWf59OJ/rmEdQ84LhLeWnYttQisVRY4w+SJspsGsdad ZigobTevKmKXP1Xn+v7xsoKHbhBGsEEtnZ0RKgcXoV+BaQZxKNd2TKXqT/j8AKx+ffSW K8stXafnXQ6MW9lxyIRmyNR/gwSIROeXmXYbsTtYW0q6NBSb9UOg/t3b/WOKwKFKhvLZ u8zg== MIME-Version: 1.0 Received: by 10.42.92.17 with SMTP id r17mr4403742icm.39.1344708962627; Sat, 11 Aug 2012 11:16:02 -0700 (PDT) Received: by 10.64.78.200 with HTTP; Sat, 11 Aug 2012 11:16:02 -0700 (PDT) X-Originating-IP: [67.127.59.13] In-Reply-To: References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> Date: Sat, 11 Aug 2012 11:16:02 -0700 Message-ID: From: Trevor Perrin To: Chris Palmer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlagtxLrbLdB5q7zxWoZllZMxoN2emJJYE2n/4U7CQZbFjwdRFZz9X/VP/SkcVQmiW5/zCI Cc: Chris Evans , websec@ietf.org, saag@ietf.org, Moxie Marlinspike Subject: Re: [websec] [saag] Pinning 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: Sat, 11 Aug 2012 18:16:04 -0000 Hi Chris, all, On Fri, Aug 10, 2012 at 3:20 PM, Chris Palmer wrote: > So ultimately I do think we should decide on either HPKP or TACK, but > that we should make that decision after there has been some real-world > deployment experience with both (or, sadly, real-world non-deployment > of one or both). My 2c: We should keep exploring both TACK and HPKP. I'd like to see both proposals fleshed out, so we can do an in-depth comparison. We'll try to send a draft-01 in a couple weeks. > Additionally, HPKP and TACK might converge, more or less. I have plans > to publish a new HPKP I-D that borrows some of TACK's pin activation > and expiration ideas, for example. Awesome, looking forward to it. There's some things you'll have to grapple with (is pin activation performed for each key individually, or for the keys as a set? when is it performed? etc.) > Additionally, one of the main criticisms of HPKP is that it is tied to > HTTP. I currently don't consider that a huge problem =97 even though I > consider TACK's TLS-generic-ness a nice benefit =97 for several reasons: > > * HTTPS is the big, important application that we need to secure right no= w. Agreed: TACK's TLS-generic-ness is a nice benefit, but a good solution for HTTPS is more important than reusability. > * It's not clear that SMTP over TLS is very beneficial, because you > can't stop delivery due to pin validation failure (or really even > regular old X.509 failure). Pinning for MTA-to-MTA SMTP seems useful. Since receiving MTAs often have invalid certificates, they're hard to authenticate any other way. If a sending MTA doesn't want to reject connections on pin failure, it could run in "warn-only" mode. > * SSH already has PKP. :) Not proposing to change that. But a TACK_Extension *could*, theoretically, be embedded in non-TLS, non-X.509 protocols... And TACK *does* have some nice lifecycle features (activation, break sigs, generations)... > And finally, as Ben Laurie pointed out, there is also Certificate > Transparency. I personally consider the "public log" class of > solutions (of which CT is a leading member, along with Sovereign Keys) > to be The Real Solution. Pinning-like solutions (including HPKP and > TACK) are a good, quick fix =97 as long as they are quick and simple. I think pinning is likely to coexist or integrate with future trust systems= . For example, Cert Transparency is cool and would help detect bad certs, but pinning would prevent their use. I think sites would want to deploy pinning even in a CT world. Also, self-asserted pins like TACK and HPKP can be detected by trust infrastructure (think Convergence or Google Cert Catalog) which publishes them for auditors to review and for client apps to download. So, in a broad sense (pinning, CT, Convergence) are all "public knowledge" systems which have some similar benefits. Anyways, quick and simple is always good, but we shouldn't view pinning as a disposable technology. (Not that you're saying that, but just don't want it to be misconstrued). Trevor From ynir@checkpoint.com Sat Aug 11 13:38:10 2012 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 8E0FB21F8549 for ; Sat, 11 Aug 2012 13:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, 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 RwU1t1bMeT4z for ; Sat, 11 Aug 2012 13:38:10 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 94BDD21F8535 for ; Sat, 11 Aug 2012 13:38:09 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q7BKbs7S003179; Sat, 11 Aug 2012 23:37:54 +0300 X-CheckPoint: {5026BF95-0-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 11 Aug 2012 23:37:54 +0300 From: Yoav Nir To: Chris Palmer Date: Sat, 11 Aug 2012 23:37:52 +0300 Thread-Topic: [saag] [websec] Pinning Thread-Index: Ac14AS5KvY5+O10lTRm44RvftP/6Qg== Message-ID: <24C52325-8B51-4DA0-B21D-DC72E184BB23@checkpoint.com> References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Chris Evans , IETF WebSec WG , Paul Hoffman , Sean Turner , Moxie Marlinspike Subject: Re: [websec] [saag] Pinning 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: Sat, 11 Aug 2012 20:38:10 -0000 Hi Chris I've removed SAAG from CC, trimmed most of your message, and re-arranged th= e rest. Hope you don't mind=85 On Aug 11, 2012, at 1:20 AM, Chris Palmer wrote: > Additionally, HPKP and TACK might converge, more or less. I have plans > to publish a new HPKP I-D that borrows some of TACK's pin activation > and expiration ideas, for example. Just as a reminder, HPKP is now a working group draft. As such, change cont= rol is with the WG. Changes that change the rules for activation and expira= tion should be proposed and discussed on the list first.=20 Having said that, we are pretty far from last call on key-pinning, so I thi= nk it would be OK to publish a version -03 with such proposed changes, as l= ong as those changes are clearly marked as not being the result of WG conse= nsus. As an individual, I understand the limitations of the "spare public key" ap= proach of the current HPKP. It's an administrative hassle to generate n spa= re keys and keep them safe, and if you have n+1 key compromise events withi= n the max-age time, your site is blocked. But it does have the big advantag= e that the server side can be deployed *now* with no additional software. U= ntil I see how those borrowed ideas can help with these issues, I prefer HP= KP. > So ultimately I do think we should decide on either HPKP or TACK, but > that we should make that decision after there has been some real-world > deployment experience with both (or, sadly, real-world non-deployment > of one or both). Well, there's WG deciding, and there's the market deciding. The IETF can pu= blish both approaches (as either proposed standard or experimental) and the= one (if any) that the market prefers can later be upgraded to standard (or= it can stay at proposed anyway) Yoav= From tom@ritter.vg Sat Aug 11 13:58:00 2012 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 3E29821F859B for ; Sat, 11 Aug 2012 13:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA+Qv671c3Kh for ; Sat, 11 Aug 2012 13:57:59 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD921F8599 for ; Sat, 11 Aug 2012 13:57:59 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2785348vcb.31 for ; Sat, 11 Aug 2012 13:57:58 -0700 (PDT) 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:content-transfer-encoding; bh=U9B6V74B8WleZyW7SFp/ryISkli0NUZBnDYjuoGeEFM=; b=G3qKMup5qswfPRMEFL+JvdxHnijOXZejvoymp5+zMlFtFBAswA5YvGfruYWaop6/6w F3/uttQtvPbCgOlivZ0ahMUvKrKJwaSycqx089MhOIHrj3Mx2RBFQNU3ox+P2CUSKfTC o1nOIN/1X22rT7CZqBu2gI1G6LpzQXa6ZX2Lg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=U9B6V74B8WleZyW7SFp/ryISkli0NUZBnDYjuoGeEFM=; b=GTuamsa3DYONqGotbhHanZw/8BptYxcGQkLYGxX5DK66neaIWZduS3HIjHkBcqwVcY KVIUUgmRbp3ZS+KPoKSgSWO5/i2Y3IareJNIDEUotDxmxCiCuC2VKFkfemnqPN7dDG1x NxiIxiYXd1JKsesEO37PuDg37RHK519GfCUC9f6V6df2s9koZKUZ3tUgIdNruf0YCdnJ SfhHCyge5ewD0ZS9k1EHprBiwzSfXqufDNDixgkXkcT344sXnL2OgXnMzHeL0KFKGoHF zo1n53bsFg021Kt6nMWs1F4sen3GKUWHkCHynhpvmKEqzxfX4Fiqp7azdbp52HhC4GSp OluA== Received: by 10.220.222.145 with SMTP id ig17mr1897253vcb.15.1344718678513; Sat, 11 Aug 2012 13:57:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.145.163 with HTTP; Sat, 11 Aug 2012 13:57:38 -0700 (PDT) In-Reply-To: <24C52325-8B51-4DA0-B21D-DC72E184BB23@checkpoint.com> References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> <24C52325-8B51-4DA0-B21D-DC72E184BB23@checkpoint.com> From: Tom Ritter Date: Sat, 11 Aug 2012 16:57:38 -0400 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlfpSCGRuQTm/Cdoc/Zdeq5qK1JJKGtRhxfNOHKqruovRhOQ6RPXmDOxYdBF5xboribBjrr Cc: Chris Evans , IETF WebSec WG , Paul Hoffman , Sean Turner , Moxie Marlinspike Subject: Re: [websec] [saag] Pinning 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: Sat, 11 Aug 2012 20:58:00 -0000 I don't know IETF procedure for making changes, but one of the outstanding issues I don't think has been resolved with draft-ietf-websec-key-pinning-02 is inherited DSA parameters. I raised this issue here: http://www.ietf.org/mail-archive/web/websec/current/msg01027.html with suggested verbiage. -tom On 11 August 2012 16:37, Yoav Nir wrote: > Hi Chris > > I've removed SAAG from CC, trimmed most of your message, and re-arranged = the rest. Hope you don't mind=85 > > On Aug 11, 2012, at 1:20 AM, Chris Palmer wrote: > >> Additionally, HPKP and TACK might converge, more or less. I have plans >> to publish a new HPKP I-D that borrows some of TACK's pin activation >> and expiration ideas, for example. > > > > Just as a reminder, HPKP is now a working group draft. As such, change co= ntrol is with the WG. Changes that change the rules for activation and expi= ration should be proposed and discussed on the list first. > > Having said that, we are pretty far from last call on key-pinning, so I t= hink it would be OK to publish a version -03 with such proposed changes, as= long as those changes are clearly marked as not being the result of WG con= sensus. > > > As an individual, I understand the limitations of the "spare public key" = approach of the current HPKP. It's an administrative hassle to generate n s= pare keys and keep them safe, and if you have n+1 key compromise events wit= hin the max-age time, your site is blocked. But it does have the big advant= age that the server side can be deployed *now* with no additional software.= Until I see how those borrowed ideas can help with these issues, I prefer = HPKP. > >> So ultimately I do think we should decide on either HPKP or TACK, but >> that we should make that decision after there has been some real-world >> deployment experience with both (or, sadly, real-world non-deployment >> of one or both). > > Well, there's WG deciding, and there's the market deciding. The IETF can = publish both approaches (as either proposed standard or experimental) and t= he one (if any) that the market prefers can later be upgraded to standard (= or it can stay at proposed anyway) > > Yoav > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From trac+websec@trac.tools.ietf.org Sat Aug 11 14:20:44 2012 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 0573421F84A1 for ; Sat, 11 Aug 2012 14:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ajLU6TCIyz+C for ; Sat, 11 Aug 2012 14:20:43 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3121F847F for ; Sat, 11 Aug 2012 14:20:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:49498 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T0J6l-0001qI-I0; Sat, 11 Aug 2012 23:20:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-key-pinning@tools.ietf.org X-Trac-Project: websec Date: Sat, 11 Aug 2012 21:20:31 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/50 Message-ID: <051.d94c07ecb13014cd35f8ea0580233d57@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-key-pinning@tools.ietf.org, 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 Resent-To: cevans@google.com, palmer@google.com Resent-Message-Id: <20120811212043.54A3121F847F@ietfa.amsl.com> Resent-Date: Sat, 11 Aug 2012 14:20:43 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #50: Handing of pinning DSA public keys X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 21:20:44 -0000 #50: Handing of pinning DSA public keys http://www.ietf.org/mail-archive/web/websec/current/msg01027.html To close up the hole with inherited parameters, in 2.2, prior to the "We pin public keys" note, add: If the SubjectPublicKeyInfo of a certificate is incomplete when taken in isolation, such as when holding a DSA key without domain parameters, a public key pin cannot be formed. -- -------------------------+--------------------------------------------- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Keywords: -------------------------+--------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sat Aug 11 14:22:38 2012 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 E580111E8097 for ; Sat, 11 Aug 2012 14:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XjQDSdoGaN1b for ; Sat, 11 Aug 2012 14:22:38 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F111E8087 for ; Sat, 11 Aug 2012 14:22:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:49681 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T0J8m-00036K-J4; Sat, 11 Aug 2012 23:22:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-key-pinning@tools.ietf.org X-Trac-Project: websec Date: Sat, 11 Aug 2012 21:22:36 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/51 Message-ID: <051.e05eae1872f8f91c7be05e9dcd2eafec@trac.tools.ietf.org> X-Trac-Ticket-ID: 51 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-key-pinning@tools.ietf.org, 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 Resent-To: cevans@google.com, palmer@google.com Resent-Message-Id: <20120811212237.EB4F111E8087@ietfa.amsl.com> Resent-Date: Sat, 11 Aug 2012 14:22:37 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #51: Clarification of section 2.4 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 21:22:39 -0000 #51: Clarification of section 2.4 In 2.4, adding a phrase to the parenthetical comment in the big paragraph : If the connection has no errors, the UA will then apply a new correctness check: Pin Validation. To perform Pin Validation, the UA will compute the fingerprints of the SPKI structures in each certificate in the host's validated certificate chain. (The UA ignores certificates whose SPKI cannot be taken in isolation and superfluous certificates in the chain that do not form part of the validating chain.) The UA will then check that the set of these fingerprints intersects the set of fingerprints in that host's Pinning Metadata. If there is set intersection, the UA continues with the connection as normal. Otherwise, the UA MUST treat this Pin Failure as a non-recoverable error. -- -------------------------+--------------------------------------------- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Keywords: -------------------------+--------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sat Aug 11 14:23:49 2012 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 C5B5311E8087 for ; Sat, 11 Aug 2012 14:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tIQHdATE64PU for ; Sat, 11 Aug 2012 14:23:49 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 255E811E8097 for ; Sat, 11 Aug 2012 14:23:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:49860 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1T0J9v-0000uC-K3; Sat, 11 Aug 2012 23:23:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-key-pinning@tools.ietf.org X-Trac-Project: websec Date: Sat, 11 Aug 2012 21:23:47 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/52 Message-ID: <051.df0a7eb62cdb49309147ff5b8eb8e401@trac.tools.ietf.org> X-Trac-Ticket-ID: 52 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-key-pinning@tools.ietf.org, 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 Resent-To: cevans@google.com, palmer@google.com Resent-Message-Id: <20120811212349.255E811E8097@ietfa.amsl.com> Resent-Date: Sat, 11 Aug 2012 14:23:49 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #52: Clarification of section 2.3.1 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 21:23:50 -0000 #52: Clarification of section 2.3.1 I'd suggest the following change to 2.3.1, clarifying it's required-ness and a max-age of 0. 2.3.1. max-age max-age specifies the number of seconds, after the reception of the Public-Key-Pins HTTP Response Header, during which the UA regards the host as a Pinned Host. The delta-seconds production is specified in [rfc-2616]. max-age is a required attribute. If omitted, the UA MUST NOT note the host as a Pinned Host, and MUST discard any previously set Pinning Metadata for that host in its non-volatile store. If max-age is set to 0, the UA MUST likewise discard any previsouly set Pinning Metadata. -- -------------------------+--------------------------------------------- Reporter: Tom Ritter | Owner: draft-ietf-websec-key-pinning@… Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Keywords: -------------------------+--------------------------------------------- Ticket URL: websec From ynir@checkpoint.com Sat Aug 11 14:30:27 2012 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 9329021F858A for ; Sat, 11 Aug 2012 14:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, 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 DoynlUHmsO6G for ; Sat, 11 Aug 2012 14:30:27 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ACA1021F8582 for ; Sat, 11 Aug 2012 14:30:26 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q7BLUNeI006911; Sun, 12 Aug 2012 00:30:23 +0300 X-CheckPoint: {5026CBE1-0-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Aug 2012 00:30:23 +0300 From: Yoav Nir To: Tom Ritter Date: Sun, 12 Aug 2012 00:30:22 +0300 Thread-Topic: [websec] [saag] Pinning Thread-Index: Ac14CIPZgeokpe+LR9W2BRgCmgILvg== Message-ID: References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> <24C52325-8B51-4DA0-B21D-DC72E184BB23@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Chris Evans , IETF WebSec WG , Moxie Marlinspike Subject: Re: [websec] [saag] Pinning 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: Sat, 11 Aug 2012 21:30:27 -0000 Hi Tom On Aug 11, 2012, at 11:57 PM, Tom Ritter wrote: > I don't know IETF procedure for making changes, but one of the > outstanding issues I don't think has been resolved with > draft-ietf-websec-key-pinning-02 is inherited DSA parameters. I > raised this issue here: > http://www.ietf.org/mail-archive/web/websec/current/msg01027.html with > suggested verbiage. That message of yours flew under the radar. I don't know why. The IETF procedure for making changes is to raise the suggestion on the mai= ling list, and discuss it there until consensus is reached. To help with that, we may use an issue tracker (similar to a bug tracker li= ke bugzilla). I've opened three tickets for the issues in your email: http://trac.tools.ietf.org/wg/websec/trac/ticket/50 http://trac.tools.ietf.org/wg/websec/trac/ticket/51 http://trac.tools.ietf.org/wg/websec/trac/ticket/52 We can start a thread on each of them. Easy way is the editors start the thread with "looking at issue #50, we agr= ee and it seems OK to us. Anyone object?", and then if nobody objects, the = text is updated, a new draft is published, and if you think it's OK, we clo= se the ticket. If there are objections (by the editors or others), they ge= t discussed. Yoav From jhutz@cmu.edu Sat Aug 11 15:18:25 2012 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 D0F5A21F8510; Sat, 11 Aug 2012 15:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 hPqkBM2-prfs; Sat, 11 Aug 2012 15:18:25 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2120321F84D6; Sat, 11 Aug 2012 15:18:25 -0700 (PDT) Received: from [192.168.202.154] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q7BMIIL8021870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 18:18:19 -0400 (EDT) From: Jeffrey Hutzelman To: Chris Palmer In-Reply-To: <22134_1344637228_q7AMKQRp022297_CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com> References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> <22134_1344637228_q7AMKQRp022297_CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 11 Aug 2012 18:18:18 -0400 Message-ID: <1344723498.15925.63.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 X-Mailman-Approved-At: Mon, 13 Aug 2012 00:42:15 -0700 Cc: Chris Evans , websec@ietf.org, paul.hoffman@vpnc.org, saag@ietf.org, Moxie Marlinspike , jhutz@cmu.edu Subject: Re: [websec] [saag] Pinning 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: Sat, 11 Aug 2012 22:18:25 -0000 On Fri, 2012-08-10 at 15:20 -0700, Chris Palmer wrote: > * It's not clear that SMTP over TLS is very beneficial, because you > can't stop delivery due to pin validation failure (or really even > regular old X.509 failure). That depends. Key pinning may not be very interesting for accepting coming mail from unknown sources, but it may be very interesting when TLS is used for communication between cooperating components of an enterprise mail system, or with an outsourced anti-smap or anti-virus or backup MX service. And of course, it's also interesting when TLS is used to protect authenticated mail submission services -- a user sending outgoing mail via his ISP probably doesn't want to tell his username and password to just anyone. > * SSH already has PKP. Well, no. Certainly, SSH clients making a leap-of-faith connection to a previously unknown host will generally remember that host's public key. And yes, once a host's public key is known, clients will generally reject a host that presents a public key other than the one known for that host. But then, web browsers do the same thing for leap-of-faith connections to web servers, when a server has a self-signed certificate or one signed by an unknown CA. But while this behavior is common, it is not required by any standard, not something I'd expect an SSH client to do when an X.509 certificate is used, and not the same thing as key pinning. So in fact, if this gets done at the application layer, it likely will eventually have to happen for SSH, too. I would really rather not see a proliferation of application-layer extensions to handle pinning of the long-term keys used for TLS. While I haven't participated in previous discussion on this question, I think that in the long run this is much better handled at the TLS layer. That said, there may be a benefit to solving the problem for HTTP at the HTTP layer, _if_ doing so allows us to get something deployed more quickly than a TLS-layer solution. -- Jeff From fanf2@hermes.cam.ac.uk Mon Aug 13 07:08:37 2012 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 3329721F8754; Mon, 13 Aug 2012 07:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 xs04g9Jc444H; Mon, 13 Aug 2012 07:08:36 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0971221F8752; Mon, 13 Aug 2012 07:08:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:35222) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1T0vJn-0003Hk-s4 (Exim 4.72) (return-path ); Mon, 13 Aug 2012 15:08:31 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1T0vJn-00069I-LW (Exim 4.67) (return-path ); Mon, 13 Aug 2012 15:08:31 +0100 Date: Mon, 13 Aug 2012 15:08:31 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Chris Palmer In-Reply-To: Message-ID: References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch X-Mailman-Approved-At: Mon, 13 Aug 2012 07:40:23 -0700 Cc: Chris Evans , websec@ietf.org, paul.hoffman@vpnc.org, saag@ietf.org, Moxie Marlinspike Subject: Re: [websec] [saag] Pinning 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: Mon, 13 Aug 2012 14:08:37 -0000 Chris Palmer wrote: > > * It's not clear that SMTP over TLS is very beneficial, It is not beneficial at the moment because it is underspecified - there is no specification that says which identity to check against the certificate (mail domain vs. host name), and there are significant problems with either choice. In practice this has led to most SMTP server certificates being unvalidatable or containing the wrong name. See also draft-fanf-dane-smtp for a possible way to sort out this mess. > because you can't stop delivery due to pin validation failure (or really > even regular old X.509 failure). I disagree. You can (and usually have to) stop delivery for DNS failures; there is no reason why you can't do the same for authentication errors. Tony. -- f.anthony.n.finch http://dotat.at/ Northwest FitzRoy, Sole, Lundy, Fastnet: Southwesterly backing southerly 4 or 5. Moderate, occasionally rough in northwest Fitzroy and west Sole. Rain or thundery showers. Moderate or good. From bhill@paypal-inc.com Mon Aug 13 10:59:02 2012 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 D928121F8736 for ; Mon, 13 Aug 2012 10:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 Ka4DHS3fJdCO for ; Mon, 13 Aug 2012 10:59:02 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 1099A21F8717 for ; Mon, 13 Aug 2012 10:59:01 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=sTEdi0cVyQ+bO6kvBWyP3Kwqqts9zgjFnuYQhNvOMC69d2cPbS+3m+tI Bk4BTxxuwvruXn+NOKQJjjiY3KNPzYXlTTHSgEzrI/OkpswHvvvC6vmzi 3CSXNxR5DTlIKbY; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1344880742; x=1376416742; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8eWfkggcPI7YYhNmnGVJWRBAXS9Sb/glfyH8pSt691I=; b=ix8ktrnUHczzjVVRSggBgZBRxBtbtxFg6RXvACsQlRmavqky7JtqgBuo C6Q7B/hunEyiPSdjFbT98oFT4gXBIKX7RyH6N/mbceUR9e5pTyuZm5Sds fBwNp167ZSezjBa; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.77,761,1336374000"; d="scan'208";a="9625515" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-006.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 13 Aug 2012 10:58:59 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-006.corp.ebay.com ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 11:58:54 -0600 From: "Hill, Brad" To: Tom Ritter , Chris Palmer Thread-Topic: [websec] handling STS header field extendability Thread-Index: AQHNdnu9G2/cgF2QOE2DrHCPRwkn4JdT/HaAgAEaOQCAAvRWEA== Date: Mon, 13 Aug 2012 17:58:53 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com> References: <5024352D.4040604@KingsMountain.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.242] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: Va++kfOLVR9lLOzqohWklg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: Ben Campbell , IETF WebSec WG Subject: Re: [websec] handling STS header field extendability 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: Mon, 13 Aug 2012 17:59:03 -0000 There are, of course, non-browser HTTP clients that may respect HSTS, but E= V certificates in particular are aimed at a browser audience as it is about= user trust indicators. EV is *not* a security boundary in browsers, however. It is a brand awaren= ess and consumer trust product.=20 I am not aware of any user agents that treat EV and non-EV content as havin= g different effective security principals for purposes of the Same Origin P= olicy. So, although it is more difficult to get an EV certificate than a D= V one, that does not provide any effective security against a MITM attacker= who can obtain a DV certificate. Such an attacker can always act as a par= tial MITM and provide, using a DV certificate, trojan script content in an = iframe with no security indicators or substitute an external script in a le= gitimate page and that script will have full access to content delivered wi= th an EV certificate. I would posit that means a feature like LockEV has little to no practical v= alue unless and until (not likely) Web user agents provide origin isolation= between EV and non-EV content. -Brad Hill > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf > Of Tom Ritter > Sent: Saturday, August 11, 2012 7:43 AM > To: Chris Palmer > Cc: Ben Campbell; IETF WebSec WG > Subject: Re: [websec] handling STS header field extendability >=20 > On 10 August 2012 17:52, Chris Palmer wrote: > > Please forgive my ignorance, but do LockCA and/or LockEV offer any > > functionality that you can't already get with public key pinning as > > currently specified? You can pin to a given CA's public key(s), and > > you can pin to any given EV issuers' public keys. >=20 > I can't think of one for Lock CA; but LockEV could be useful for sites th= at want > to deploy some additional measure, but can't/don't want to > a) commit to a CA or b) enumerate all possible EV authorities. It should= be > ('should be', not 'is') more difficult to get a fraudulent EV certificate= through > trickery or treachery than a DV certificate. >=20 > I don't think browsers differentiate between OV and DV in any meaningful > way, but I could be wrong. >=20 > -tom > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From collin.jackson@west.cmu.edu Mon Aug 13 12:22:19 2012 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 CD7A521F858A for ; Mon, 13 Aug 2012 12:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1WTN9Bfh1vH for ; Mon, 13 Aug 2012 12:22:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA9B21F85F7 for ; Mon, 13 Aug 2012 12:22:19 -0700 (PDT) Received: by yhq56 with SMTP id 56so3932513yhq.31 for ; Mon, 13 Aug 2012 12:22:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=KbyV/x7lGNEBZlYNbvjVsxNajwDDBXL/ebyDjwnJgI4=; b=cIXaetTVAWtGs7XF4vPch5+iAoc2dN1YtVg+YOYXtFXIvtdHeTyKnTFuvEhnnqViSs Jc0sQLLKYntCtkaQ0cBldIKPavkRkg6cWX1J9fb/qZYOdtOUUwRc/5RocjyJCcrpmLC5 rG2DGfzxDkRaErz4yNWR7t3mzBmqbFQh1Ihl38ntbZwskFXzQMp5k3zxi4ypM1gDdDUJ qCdGwLB4KJUoy+u+DNtVBYaixuZsR9OWnsQiHyW2dvk0I+pn1YZSQQtxCCk9r6UipY1L fHuRBisOHHjRCnPijIFa2+F/CQRW5/IKbxeSEbY4FQZOYH58QjVHgoppSs8VnVxCO0/g OdIg== Received: by 10.236.141.42 with SMTP id f30mr8945655yhj.120.1344885738814; Mon, 13 Aug 2012 12:22:18 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id y10sm654752yhd.6.2012.08.13.12.22.18 (version=SSLv3 cipher=OTHER); Mon, 13 Aug 2012 12:22:18 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3751340ghb.31 for ; Mon, 13 Aug 2012 12:22:17 -0700 (PDT) Received: by 10.68.219.226 with SMTP id pr2mr19847587pbc.1.1344885737410; Mon, 13 Aug 2012 12:22:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.21.131 with HTTP; Mon, 13 Aug 2012 12:21:37 -0700 (PDT) In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com> References: <5024352D.4040604@KingsMountain.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com> From: Collin Jackson Date: Mon, 13 Aug 2012 12:21:37 -0700 Message-ID: To: "Hill, Brad" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl9jU+lPuX2rRJGZYGQOnMEykPms93JSAOQvzYIt+yibCFAs+zzvZ3YenjGN0EzQeyBOmq7 Cc: Ben Campbell , IETF WebSec WG Subject: Re: [websec] handling STS header field extendability 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: Mon, 13 Aug 2012 19:22:19 -0000 On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad wrote: > There are, of course, non-browser HTTP clients that may respect HSTS, but= EV certificates in particular are aimed at a browser audience as it is abo= ut user trust indicators. > > EV is *not* a security boundary in browsers, however. It is a brand awar= eness and consumer trust product. > > I am not aware of any user agents that treat EV and non-EV content as hav= ing different effective security principals for purposes of the Same Origin= Policy. So, although it is more difficult to get an EV certificate than a= DV one, that does not provide any effective security against a MITM attack= er who can obtain a DV certificate. Such an attacker can always act as a p= artial MITM and provide, using a DV certificate, trojan script content in a= n iframe with no security indicators or substitute an external script in a = legitimate page and that script will have full access to content delivered = with an EV certificate. > > I would posit that means a feature like LockEV has little to no practical= value unless and until (not likely) Web user agents provide origin isolati= on between EV and non-EV content. Quite the opposite, you just made the argument in favor of LockEV. If LockEV is being used, the MITM attack with a DV certificate would no longer be possible, because the DV certificate would not be accepted by the browser. Collin From paul.hoffman@vpnc.org Mon Aug 13 14:00:41 2012 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 A97B321F849B for ; Mon, 13 Aug 2012 14:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xGhfbAub-NiT for ; Mon, 13 Aug 2012 14:00:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC3021F849A for ; Mon, 13 Aug 2012 14:00:40 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7DL0bWZ038968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 14:00:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 13 Aug 2012 14:00:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5024352D.4040604@KingsMountain.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com> To: Collin Jackson X-Mailer: Apple Mail (2.1278) Cc: Ben Campbell , IETF WebSec WG Subject: Re: [websec] handling STS header field extendability 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: Mon, 13 Aug 2012 21:00:41 -0000 On Aug 13, 2012, at 12:21 PM, Collin Jackson wrote: > On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad = wrote: >> There are, of course, non-browser HTTP clients that may respect HSTS, = but EV certificates in particular are aimed at a browser audience as it = is about user trust indicators. >>=20 >> EV is *not* a security boundary in browsers, however. It is a brand = awareness and consumer trust product. >>=20 >> I am not aware of any user agents that treat EV and non-EV content as = having different effective security principals for purposes of the Same = Origin Policy. So, although it is more difficult to get an EV = certificate than a DV one, that does not provide any effective security = against a MITM attacker who can obtain a DV certificate. Such an = attacker can always act as a partial MITM and provide, using a DV = certificate, trojan script content in an iframe with no security = indicators or substitute an external script in a legitimate page and = that script will have full access to content delivered with an EV = certificate. >>=20 >> I would posit that means a feature like LockEV has little to no = practical value unless and until (not likely) Web user agents provide = origin isolation between EV and non-EV content. >=20 > Quite the opposite, you just made the argument in favor of LockEV. If > LockEV is being used, the MITM attack with a DV certificate would no > longer be possible, because the DV certificate would not be accepted > by the browser. In what case is that attack useful? The public key would still be the = one that the site thought they had an EV cert for. Confused... --Paul Hoffman= From collin.jackson@west.cmu.edu Mon Aug 13 14:09:47 2012 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 D4B3121F865E for ; Mon, 13 Aug 2012 14:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPI0nfBDanLO for ; Mon, 13 Aug 2012 14:09:47 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA99F21F8650 for ; Mon, 13 Aug 2012 14:09:46 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3886882ghb.31 for ; Mon, 13 Aug 2012 14:09:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=fTHvW0PRGdEEbjYwxzA6ncTVTRvOInE6bYZ78beLlc8=; b=nCrNsNzmeYIY4+q7Dlpqr3pGjQWj171QyUZqe/f8Qk5ZoHZTMrxBcXvWIvsi8S70Lf ytNCodlSxXdyvmOkMkZETYuvnabrzqseQhk2H5UE2jfKIVH7KNOUP7OxPF0BfUw887MM 7Tt0cMGQWqeL0Cr3DMHU1YkRJBYyOG0xaqavO70xoXfsAU2r+bbyfWuw1twMZ/q3FWys le6VP0tCM1KpwdJg0v26NIzTmMnI9nLAhOJQBJSj4haTvB2kUMT964NsfWmIcQhD7ijQ x1eWemB92KXSLu9yN0gcmqKX0jUU2SwG2hdZzmS0i2VnxFDoxqdksLHoB5CX+CAmgioV p/bg== Received: by 10.236.78.3 with SMTP id f3mr12553492yhe.34.1344892186509; Mon, 13 Aug 2012 14:09:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id l1sm1148581yhm.19.2012.08.13.14.09.46 (version=SSLv3 cipher=OTHER); Mon, 13 Aug 2012 14:09:46 -0700 (PDT) Received: by yhq56 with SMTP id 56so4066722yhq.31 for ; Mon, 13 Aug 2012 14:09:45 -0700 (PDT) Received: by 10.66.74.67 with SMTP id r3mr18674398pav.1.1344892185348; Mon, 13 Aug 2012 14:09:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.21.131 with HTTP; Mon, 13 Aug 2012 14:09:05 -0700 (PDT) In-Reply-To: References: <5024352D.4040604@KingsMountain.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com> From: Collin Jackson Date: Mon, 13 Aug 2012 14:09:05 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnaOdLJXymrRRhBuz4lPF7LyfbBQPpAwUCJwoT/nxS3qpr+RwBYoBS6bw3nB8WxJpEFGOBu Cc: Ben Campbell , IETF WebSec WG Subject: Re: [websec] handling STS header field extendability 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: Mon, 13 Aug 2012 21:09:47 -0000 I don't understand your question, but I'll attempt to rephrase my comment. Brad was describing a network attacker that was able to obtain a DV certificate (but not an EV certificate) for a target site. The attacker can "act as a partial MITM and provide, using a DV certificate, trojan script content in an iframe with no security indicators or substitute an external script in a legitimate page and that script will have full access to content delivered with an EV certificate." This would allow, for example, the attacker to read cookies and passwords entered into a bank's login form. My point is that if the site is using LockEV, the network attacker's DV certificate is useless, so LockEV is useful even if the browser's script access checks don't pay attention to the EV/DV distinction. On Mon, Aug 13, 2012 at 2:00 PM, Paul Hoffman wrote= : > On Aug 13, 2012, at 12:21 PM, Collin Jackson wrote: > >> On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad wrot= e: >>> There are, of course, non-browser HTTP clients that may respect HSTS, b= ut EV certificates in particular are aimed at a browser audience as it is a= bout user trust indicators. >>> >>> EV is *not* a security boundary in browsers, however. It is a brand aw= areness and consumer trust product. >>> >>> I am not aware of any user agents that treat EV and non-EV content as h= aving different effective security principals for purposes of the Same Orig= in Policy. So, although it is more difficult to get an EV certificate than= a DV one, that does not provide any effective security against a MITM atta= cker who can obtain a DV certificate. Such an attacker can always act as a= partial MITM and provide, using a DV certificate, trojan script content in= an iframe with no security indicators or substitute an external script in = a legitimate page and that script will have full access to content delivere= d with an EV certificate. >>> >>> I would posit that means a feature like LockEV has little to no practic= al value unless and until (not likely) Web user agents provide origin isola= tion between EV and non-EV content. >> >> Quite the opposite, you just made the argument in favor of LockEV. If >> LockEV is being used, the MITM attack with a DV certificate would no >> longer be possible, because the DV certificate would not be accepted >> by the browser. > > In what case is that attack useful? The public key would still be the one= that the site thought they had an EV cert for. > > Confused... > > --Paul Hoffman From paul.hoffman@vpnc.org Mon Aug 13 14:17:45 2012 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 A4ECF21F8691 for ; Mon, 13 Aug 2012 14:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 j8bBguCryVfm for ; Mon, 13 Aug 2012 14:17:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 155EE21F8645 for ; Mon, 13 Aug 2012 14:17:45 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7DLHhNR046730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 14:17:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 13 Aug 2012 14:17:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9AC35DC0-6863-4C3F-AF4F-E34D4CD632CC@vpnc.org> References: <5024352D.4040604@KingsMountain.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com> To: Collin Jackson X-Mailer: Apple Mail (2.1278) Cc: Ben Campbell , IETF WebSec WG Subject: Re: [websec] handling STS header field extendability 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: Mon, 13 Aug 2012 21:17:45 -0000 On Aug 13, 2012, at 2:09 PM, Collin Jackson wrote: > Brad was describing a network attacker that was able to obtain a DV > certificate (but not an EV certificate) for a target site. The > attacker can "act as a partial MITM and provide, using a DV > certificate, trojan script content in an iframe with no security > indicators or substitute an external script in a legitimate page and > that script will have full access to content delivered with an EV > certificate." This would allow, for example, the attacker to read > cookies and passwords entered into a bank's login form. >=20 > My point is that if the site is using LockEV, the network attacker's > DV certificate is useless, so LockEV is useful even if the browser's > script access checks don't pay attention to the EV/DV distinction. If the site did LockEV without ever locking its public key or CA, you = would be right. That seems like a ridiculous policy, though. LockCA = seems much more likely. --Paul Hoffman= From bhill@paypal-inc.com Mon Aug 13 14:21:05 2012 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 BA8FA21F84B3 for ; Mon, 13 Aug 2012 14:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 056Tl3MCFdAE for ; Mon, 13 Aug 2012 14:21:05 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id E4DD721F84A0 for ; Mon, 13 Aug 2012 14:21:04 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=MW/1BtIFwxRasd3rDmVRmaXKgRRz73d4VdfOkY3aoCgGrZXuDDAspiO7 JnV8VyfJjn2oOhxLfTb5fxlge6Q3zaqzWfLm9IPx9cgAPSaZszW6VclNf UeEbQAn2Hob6RuA; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1344892865; x=1376428865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zfiIxbPDSRk/NLw6Qw88wmM3/eqTnhshQUo081sisHQ=; b=UY8r2OVyGDIHv3dk6n8ASPDu+HeWe7NZAmxE6qTYTfb8DiZWDDry25nD M3Ye0ZB1P9CQYHqQsB6zKHU1lpgii6aZl68DVypJPHp6xpa+nBUo1Tm1t hMfR8PSj9otLUjr; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.77,762,1336374000"; d="scan'208,217";a="9146511" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-006.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 13 Aug 2012 14:21:04 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-006.corp.ebay.com ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 15:20:21 -0600 From: "Hill, Brad" To: Paul Hoffman , Collin Jackson Thread-Topic: [websec] handling STS header field extendability Thread-Index: AQHNdnu9G2/cgF2QOE2DrHCPRwkn4JdT/HaAgAEaOQCAAvRWEIAAfk+AgAAbqYD//53BMA== Date: Mon, 13 Aug 2012 21:20:20 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E1C2818@DEN-EXDDA-S12.corp.ebay.com> References: <5024352D.4040604@KingsMountain.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.242] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: zn7wKYpsPqCW7ONKLuM9bQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: Ben Campbell , IETF WebSec WG Subject: Re: [websec] handling STS header field extendability 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: Mon, 13 Aug 2012 21:21:05 -0000 I have an EV certificate for www.example.com. On the main page, it include= s the following tag: