From Jeff.Hodges@KingsMountain.com Mon Oct 1 08:45: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 EFB3C1F0CCD for ; Mon, 1 Oct 2012 08:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.278 X-Spam-Level: X-Spam-Status: No, score=-100.278 tagged_above=-999 required=5 tests=[AWL=0.217, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFGr0mQ5kdyC for ; Mon, 1 Oct 2012 08:45:42 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 0D7A91F0C7E for ; Mon, 1 Oct 2012 08:45:41 -0700 (PDT) Received: (qmail 25185 invoked by uid 0); 1 Oct 2012 15:45:34 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 1 Oct 2012 15:45:34 -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:To:MIME-Version:From:Date:Message-ID; bh=cRIJ7DNSMqGCZYbrUGilfCC+VbEGgsDL9AjeKWDBJWI=; b=UDjXr+MtpGtqUwoZPMB871Z/C4FYbtRHXamNhpCMLsGTZa2TdKV/+IbqAIjQxm824y6pcIf2QRZyT5dP4JOWuLsTA3cH+JVE/ThtCrQOL91G+WF9725tIC785zcurB8k; Received: from [216.113.168.128] (port=47954 helo=[10.244.138.54]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TIiBZ-0007xp-RP for websec@ietf.org; Mon, 01 Oct 2012 09:45:33 -0600 Message-ID: <5069BA9F.109@KingsMountain.com> Date: Mon, 01 Oct 2012 08:45:35 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: IETF WebSec WG 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] new rev: draft-ietf-websec-strict-transport-sec-13 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, 01 Oct 2012 15:45:43 -0000 New rev: https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-14 please see change log excerpt included below for details. This rev addresses comments raised during IESG review.. https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ballot/ All issue tickets are closed. full issue ticket list for strict-transport-sec: Redline spec diff from previous rev: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-websec-strict-transport-sec-14.txt side-by-side diff from previous rev: https://tools.ietf.org/rfcdiff?url2=draft-ietf-websec-strict-transport-sec-14.txt Change Log for this rev is below. =JeffH ============================================================== Appendix D. Change Log [RFCEditor: please remove this section upon publication as an RFC.] Changes are grouped by spec revision listed in reverse issuance order. D.1. For draft-ietf-websec-strict-transport-sec Changes from -13 to -14: 1. Added a new subsection entitled "Considerations for Offering Unsecured HTTP Services at Alternate Ports or Subdomains of an HSTS Host" to section 11.4 "Implications of includeSubDomains". This is addresses Robert Sparks' Discuss point (1): Also s/flag/directive/ for all uses of e.g. "includeSubDomains flag", and noted that the presence of an includeSubDomains directive in an STS header field means it is "asserted". 2. Added a definition of an expired known HSTS Host, as well as a stipulation that the UA must evict expired known HSTS hosts from the cache (to section 8.1.1 "Noting an HSTS Host - Storage Model"). Added an "unexpired" adjective appropriately to section 8.2 "Known HSTS Host Domain Name Matching". This is addresses Robert Sparks' Discuss point (2): 3. Added a note 14.4 reason for clients to consider providing a way for users to remove entries from the cache. This is addresses Robert Sparks' first Comment: 4. Noted in 2nd para of section 7.1 that HTTP is running over secure transport. This is addresses Robert Sparks' second comment ("nit"): 5. Struck the "or perhaps others" phrase from Section 7. Added Section 14 "Underlying Secure Transport Considerations" to Sec Cons. This is addresses a portion of Eric Rescorla's feedback. 6. Added a NOTE to Section 8.3 URI Loading and Port Mapping regarding non-HTTPS servers running at non-standard ports identified in URIs. Added item (6) to Appendix A explaining the port mapping design decision. This addresses the other portion of EKR's feedback. Changes from -12 to -13: --- end From ynir@checkpoint.com Tue Oct 2 03:27:46 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 EADCB21F8B1B for ; Tue, 2 Oct 2012 03:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxyKWKPwRSlf for ; Tue, 2 Oct 2012 03:27:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0F421F8ACC for ; Tue, 2 Oct 2012 03:27:45 -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 q92ARhQU010160 for ; Tue, 2 Oct 2012 12:27:43 +0200 X-CheckPoint: {506AC088-A-1B221DC2-2FFFF} 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, 2 Oct 2012 12:27:43 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 2 Oct 2012 12:27:43 +0200 From: Yoav Nir To: "IETF WG (websec@ietf.org)" Date: Tue, 2 Oct 2012 12:27:41 +0200 Thread-Topic: HTTP-Auth BoF meeting in Atlanta Thread-Index: Ac2ghvCoJnFQnW3RREKTP8LDlNm3qA== Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A7FA6F452@il-ex01.ad.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [websec] HTTP-Auth BoF meeting in Atlanta 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, 02 Oct 2012 10:27:47 -0000 Hi all In Vancouver, the httpbis working group declined to adopt any of the propos= ed authentication schemes.=20 In the coming IETF meeting, the security area is going to have a BoF with t= he intention of forming a working group to create a bunch of experimental R= FCs for new authentication methods in HTTP. There are quite a few proposed methods. Follow this URL to see a list: http= ://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals If you are interested in this topic, we'd be happy to see you in the BoF. = One thing that I think is missing from the discussion is the UI implication= s of authentication at the HTTP layer. It has been suggested that UI issues= are the reason for the relatively sparse deployment of HTTP layer authenti= cation, but I don't think the current discussion has been informed by UI ex= perts who could tell us what future authentication methods should do in ter= ms of UI to gain meaningful deployment. If you or someone you know has such= expertise and would be willing to speak at the Atlanta BoF, please contact= Derek Atkins and me offline. Yoav (with BoF chair hat on) From iesg-secretary@ietf.org Tue Oct 2 06:37: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 0358F21F86C7; Tue, 2 Oct 2012 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7ikbdUzwxu4; Tue, 2 Oct 2012 06:37:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4B21F86DD; Tue, 2 Oct 2012 06:37:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121002133711.30155.3163.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 06:37:11 -0700 Cc: websec mailing list , websec chair , RFC Editor Subject: [websec] Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt) 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, 02 Oct 2012 13:37:12 -0000 The IESG has approved the following document: - 'HTTP Strict Transport Security (HSTS)' (draft-ietf-websec-strict-transport-sec-14.txt) as Proposed Standard This document is the product of the Web Security Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ Technical Summary The specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections.  This overall policy is referred to as HTTP Strict Transport Security (HSTS).  The policy is declared by web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. Working Group Summary There was a good discussion in the WG on HSTS over an extended period of time. Most of the draft consensus appears to be pretty strong. Discussion activity in the last 4 weeks during WGLC has been relatively low, though no hot controversies did show up. There is one last-minute item raised in Paris that was less discussed than could have been: whether the HSTS header should have a "report-only" feature. There was some minor discussion and so far it appears that rough consensus is for the draft as it is (without adding that feature), but the number of votes for this feature was not very high. The GenART review during Last Call noted that text at the end of Section 6.1 specifies and extension point and says that a registry might be created by the first extension that needs it. The review suggested either creating the registry now or, alternatively, specifying its registration policy now to prevent an inappropriate choice of policy later. The working group decided to do the latter, and chose IETF Review for the policy. Document Quality The document is in good shape. The ABNF was reviewed and verified by several experts and appears to be correct. The header is already deployed and implemented by several websites and browser implementations. Personnel Shepherd: Tobias Gondrom AD: Barry Leiba From jeff.hodges@paypal-inc.com Thu Oct 4 09:59:01 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 6A20C21F8714 for ; Thu, 4 Oct 2012 09:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.858 X-Spam-Level: X-Spam-Status: No, score=-9.858 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEcl1mFksYQC for ; Thu, 4 Oct 2012 09:59:00 -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 6F55F21F863F for ; Thu, 4 Oct 2012 09:59:00 -0700 (PDT) DomainKey-Signature: s=paypalcorp; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=WprjroOLt3FFF7heG/iXXFmszWrPktYySFTbk/kD6ZniVd+F9LoLR2J6 OGozQMgv60sIxTw9mBRy7dKV1S6nB/IUSNpGJicrKdnjlbqGdIA9mZnC7 sZsglS8/JbYfWYT7TQ28UZZTA6r9xt4NdYIL5pB064PvXLOufer4nd+x9 E=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=jeff.hodges@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1349369941; x=1380905941; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=J6t4I0VyeG6IEdOqeqonkRjNF1zsV5ZRQTJ3oHS5jk0=; b=fd3Qvm2fr8PRENV74YdEcbg74JDOmLZqHBPoaY4q8VOgT+wasYTStCs5 iOmVWPR98rT3JKNR+VTqO2cnmOedkfdLfcyyVC/Bs8ltYSMF1E30pRaPk 4wYtzsjeG81+fmaecqzG/5i3HezVTp0kZ66poVxu2J40uwtRAF+Bmko/Z Q=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,537,1344236400"; d="scan'208";a="10613277" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-004.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 04 Oct 2012 09:59:00 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-004.corp.ebay.com ([fe80::a487:c570:9abc:bb59%14]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 10:58:59 -0600 From: "Hodges, Jeff" To: IETF WebSec WG Thread-Topic: HSTS approval generating some news... Thread-Index: Ac2iUGOBb9OAptxqQbWxXyLRveVAGQ== Date: Thu, 4 Oct 2012 16:58:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: [websec] HSTS approval generating some news... 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, 04 Oct 2012 16:59:01 -0000 ..e.g., see... https://twitter.com/i/#!/search/realtime/hsts http://news.cnet.com/8301-1009_3-57524915-83/web-security-protocol-hsts-w= ins-proposed-standard-status/ https://threatpost.com/en_us/blogs/ietf-approves-hsts-internet-draft-1003= 12 8^) =3DJeffH From omgponies3145@gmail.com Thu Oct 4 10:35:39 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 CDFEF21F86BE for ; Thu, 4 Oct 2012 10:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfIAvADXTVQk for ; Thu, 4 Oct 2012 10:35:39 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E47E821F86EA for ; Thu, 4 Oct 2012 10:35:38 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so356101dan.31 for ; Thu, 04 Oct 2012 10:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ts956PB+k7rZFo0PVo4oHpSLhLyff+A62BhKH0J3z2U=; b=Uz/+xBxbtbhdDAPsLt1W10JYYtsYeA5X6Qzt5SP/3RUSJisXB+enZrJZrkkH2Xh4Zy zqXuq9PhkhhqJiuKV3WuHUbVXvoqMBeieq8LlaxSY+hvltKQgqVtq7GrIvPRsCJWaghn Cg+EZ3MB7bBHgkM86hDOg29BkZOT6yQqTTsKFTSilGfKCtJfTBAdp9upVq2E74hR51wZ 0lqbmHi4My1Ssx+bXNYyifeMlXdqv06pym5p1CAGoJd9TMfE69Ngh9lwILAZS1kJWZ6V iWoxY/jkMZxApnv8HFQgYt1bIWs/xZAZFsb1PRWMIAryX44ieqXRGVkZIWrjZSASjojP RpEg== Received: by 10.66.88.198 with SMTP id bi6mr15097109pab.23.1349372138700; Thu, 04 Oct 2012 10:35:38 -0700 (PDT) Received: from [192.168.15.96] ([209.118.204.126]) by mx.google.com with ESMTPS id j3sm4558577paz.37.2012.10.04.10.35.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 10:35:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: John Menerick In-Reply-To: Date: Thu, 4 Oct 2012 10:34:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <99B6B0D7-9559-4BF4-A32A-CB3AAE5FB61A@gmail.com> References: To: "Hodges, Jeff" X-Mailer: Apple Mail (2.1283) Cc: IETF WebSec WG Subject: Re: [websec] HSTS approval generating some news... 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, 04 Oct 2012 17:35:39 -0000 Congrats! On Oct 4, 2012, at 9:58 AM, Hodges, Jeff wrote: > ..e.g., see... >=20 > https://twitter.com/i/#!/search/realtime/hsts >=20 >=20 > = http://news.cnet.com/8301-1009_3-57524915-83/web-security-protocol-hsts-wi= ns-proposed-standard-status/ >=20 >=20 > = https://threatpost.com/en_us/blogs/ietf-approves-hsts-internet-draft-10031= 2 >=20 >=20 > 8^) >=20 > =3DJeffH >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From paulej@packetizer.com Fri Oct 5 00:31:48 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 08CD521F8581 for ; Fri, 5 Oct 2012 00:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_40=-0.185, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2c6xtL0a3lA for ; Fri, 5 Oct 2012 00:31:45 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A61CE21F858E for ; Fri, 5 Oct 2012 00:31:33 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q957VUn6019665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Oct 2012 03:31:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349422291; bh=MofxKodspEhlmpfCKdoUMpazTWhEA1a+RdZocRf91zM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=o5nF9tdVqKHhS3Hb0p87fWEBuFJZ/Nrbij5tS4OclXKVE43w2ecKsbF4IS7utedR0 m4L/RF9QS0sq3yb40ze+FwN0wDnp9wg4MnZwSCwCa9ymstGyQTbyhlc5KAoJ07DGlA YVIxKx/Ob0nlwLzRygkXilasNEk8DM2sNLCNN5KM= From: "Paul E. Jones" To: Date: Fri, 5 Oct 2012 03:31:36 -0400 Message-ID: <022401cda2cb$744a0040$5cde00c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0225_01CDA2A9.ED3971B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2ivpBQley7TlYzQaiiDL43WnX8WA== Content-Language: en-us Cc: 'Gonzalo Salgueiro' Subject: [websec] draft-ietf-websec-strict-transport-sec and WebFinger 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, 05 Oct 2012 07:31:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0225_01CDA2A9.ED3971B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Websec Group, I was reviewing the Strict Transport Security draft and I like the idea. However, one security hole that exists is one that I believe we should work to tighten. Specifically, it is the use of a 301 as specified in Section 7.2. If a UA requests initially visits a site like www.paypal.com, it would not know if the host is an HSTS host or not. Use of 301 is not secure and the user agent could be maliciously redirected to someplace other than a site owned by PayPal, for example. A possible alternative means of determining whether a given host is an HSTS host could be via WebFinger or the current RFC 6415. In parallel to issuing a query to http://www.paypal.com, the user agent could issue a query to https://www.paypal.com/.well-known/host-meta.json. Prior to acting on a response to the HTTP request, the user agent could act on the response to the WebFinger query. A WebFinger query might be: GET /.well-known/host-meta.json HTTP/1.1 Host: www.paypal.com The WebFinger response might contain something like this: { "properties" : { " strict-transport-security":"yes" } } This response returns a single response indicating the strict transport security policy. Note that since this query was issued against an HTTS server, the above might be redundant since the Strict-Transport-Security header would have been included. Even so, this might provide a standard means of checking the policy. Alternatively, one could issue a query for the specific URL requested. Let say the original request is for http://www.example.com/user/foo. Using WebFinger, one could issue: GET /.well-known/host-meta.json?resource= http %3a%2f%2fwww.example.com%2fuser%2ffoo HTTP/1.1 This more targeted request could report on the requirement to use HTTPS via a similar means, but we could also use this to facilitate a redirection. I'm not so favorable to using WebFinger as a means of redirecting a client, but if the HTTP path and HTTPS path are different, perhaps this might provide that secure replacement for 301 on HTTP. Thus, the reply might look something like this: { "subject" : "http://www.example.com/user/foo", "properties" : { " strict-transport-security":"yes" }, "aliases" : [ "https://secure.example.com/user/foo" ] } This would indicate (again redundantly) what that strict transport security is to be used, but would also provide an alias address that could be queried. This could effectively serve where the 301 is proposed in the current draft. As yet another possible alternative to provide an alternate means of 301 redirection, we might have this reply: { "subject" : "http://www.example.com/user/foo", "links" : [ { "rel" : "strict-transport-security", "href" : "https://secure.example.com/user/foo" } ] } What the above reply does is remove the "strict transport security" property, thus removing the redundancy in the previous examples. In its place, we have a single link relation called "strict-transport-security" that contains the URL to substitute for the "subject" URL. I know it's a bit late to bring this up, but I thought it is worth asking. I apologize if the 301 issue has been beaten like a dead horse, but it seemed like an open security hole as I read the draft. If I'm misreading the draft there, by all means tell me, but I do think it would be good if we close that hole somehow if it does exist. Paul ------=_NextPart_000_0225_01CDA2A9.ED3971B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Websec = Group,

 

I was reviewing the Strict Transport Security draft = and I like the idea. However, one security hole that exists is one that = I believe we should work to tighten.  Specifically, it is the use = of a 301 as specified in Section 7.2.  If a UA requests initially = visits a site like www.paypal.com, it would not know if the host is an = HSTS host or not.  Use of 301 is not secure and the user agent = could be maliciously redirected to someplace other than a site owned by = PayPal, for example.

 

A possible = alternative means of determining whether a given host is an HSTS host = could be via WebFinger or the current RFC 6415.  In parallel to = issuing a query to http://www.paypal.com, the user agent could issue a = query to https://www.paypal.com/.well-known/host-meta.json.  Prior = to acting on a response to the HTTP request, the user agent could act on = the response to the WebFinger query.

 

A WebFinger = query might be:

 

GET = /.well-known/host-meta.json HTTP/1.1

Host: www.paypal.com

 

The = WebFinger response might contain something like this:

 

{

  = "properties" : {

    " = strict-transport-security":"yes"

  }

}

 

This = response returns a single response indicating the strict transport = security policy. Note that since this query was issued against an HTTS = server, the above might be redundant since the Strict-Transport-Security = header would have been included.  Even so, this might provide a = standard means of checking the policy.

 

Alternatively, one could issue a query for the = specific URL requested.  Let say the original request is for = http://www.example.com/user/foo.  Using WebFinger, one could = issue:

 

GET /.well-known/host-meta.json?resource=3D http = %3a%2f%2fwww.example.com%2fuser%2ffoo = HTTP/1.1

 

This more = targeted request could report on the requirement to use HTTPS via a = similar means, but we could also use this to facilitate a = redirection.  I’m not so favorable to using WebFinger as a = means of redirecting a client, but if the HTTP path and HTTPS path are = different, perhaps this might provide that secure replacement for 301 on = HTTP.  Thus, the reply might look something like = this:

 

{

  = "subject" : = "http://www.example.com/user/foo",

  "properties" : {

    " = strict-transport-security":"yes"

  },

  = "aliases" :

  = [

    = "https://secure.example.com/user/foo"

  ]

}

 

This would = indicate (again redundantly) what that strict transport security is to = be used, but would also provide an alias address that could be = queried.  This could effectively serve where the 301 is proposed in = the current draft.

 

As yet = another possible alternative to provide an alternate means of 301 = redirection, we might have this reply:

 

{

  = "subject" : = "http://www.example.com/user/foo",

  "links" :

  [

    {

      "rel" : = "strict-transport-security",

      "href" : = "https://secure.example.com/user/foo"

    }

  ]

}

 

What the = above reply does is remove the “strict transport security” = property, thus removing the redundancy in the previous examples.  = In its place, we have a single link relation called = “strict-transport-security” that contains the URL to = substitute for the “subject” URL.

 

I know = it’s a bit late to bring this up, but I thought it is worth = asking.  I apologize if the 301 issue has been beaten like a dead = horse, but it seemed like an open security hole as I read the = draft.  If I’m misreading the draft there, by all means tell = me, but I do think it would be good if we close that hole somehow if it = does exist.

 

Paul

------=_NextPart_000_0225_01CDA2A9.ED3971B0-- From tobias.gondrom@gondrom.org Fri Oct 5 05:18: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 A4E2321F845A for ; Fri, 5 Oct 2012 05:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[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, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCQcwz0KbViy for ; Fri, 5 Oct 2012 05:18:32 -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 466C821F8458 for ; Fri, 5 Oct 2012 05:18:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=kZ8ibk3cQHBzLpFj1YEAHDJaQgaN+TuYjrVD08FIuWU7lUrI/WxKIYG/Y/YTaPAr4mawTAQfXX0aF6y6IFkz0l1jGgKc7J76fC5gRohhxuBvBwJqTomRcpAc4GVoUKz+; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 32241 invoked from network); 5 Oct 2012 14:18:30 +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); 5 Oct 2012 14:18:30 +0200 Message-ID: <506ED016.7070206@gondrom.org> Date: Fri, 05 Oct 2012 13:18:30 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: <99B6B0D7-9559-4BF4-A32A-CB3AAE5FB61A@gmail.com> In-Reply-To: <99B6B0D7-9559-4BF4-A32A-CB3AAE5FB61A@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] HSTS approval generating some news... 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, 05 Oct 2012 12:18:33 -0000 Yes. Nice. As a personal comment, normally the formal release of the draft as RFC is the best time for press releases, because then you can actually refer to the RFC. However, news is always good. And btw. fyi on Sep-24 OWASP released a video tutorial on HSTS: "OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security" http://www.youtube.com/watch?v=zEV3HOuM_Vw (personal disclaimer: I am on the leadership team of OWASP) Best regards, Tobias On 04/10/12 18:34, John Menerick wrote: > Congrats! > > > On Oct 4, 2012, at 9:58 AM, Hodges, Jeff wrote: > >> ..e.g., see... >> >> https://twitter.com/i/#!/search/realtime/hsts >> >> >> http://news.cnet.com/8301-1009_3-57524915-83/web-security-protocol-hsts-wins-proposed-standard-status/ >> >> >> https://threatpost.com/en_us/blogs/ietf-approves-hsts-internet-draft-100312 >> >> >> 8^) >> >> =JeffH >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From Jeff.Hodges@KingsMountain.com Fri Oct 5 10:40:57 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 EAF3621F87AE for ; Fri, 5 Oct 2012 10:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.322 X-Spam-Level: X-Spam-Status: No, score=-100.322 tagged_above=-999 required=5 tests=[AWL=0.173, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crFsEyaLLrpp for ; Fri, 5 Oct 2012 10:40:57 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 4056121F86B3 for ; Fri, 5 Oct 2012 10:40:57 -0700 (PDT) Received: (qmail 28558 invoked by uid 0); 5 Oct 2012 17:40:55 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 5 Oct 2012 17:40:55 -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:To:MIME-Version:From:Date:Message-ID; bh=GUhi6IUmEs41bxFfQ8j4/Yye/Hir8v+TxNwBYbQAexw=; b=ACAL1gM4KpcDVwRWrtI2tO3IKQB1uuJ6DTM6ytnHG1aZyN+xJuLJy91gNv3VktfZjfnBOwYo7oJ8LqPt+9dDN3hKd/1h1o+3OLmP65kLC8QiAUWGDxoUBXvA+/aYYsOr; Received: from [216.113.168.128] (port=11984 helo=[10.244.137.77]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TKBtP-0001gB-0H for websec@ietf.org; Fri, 05 Oct 2012 11:40:55 -0600 Message-ID: <506F1BA7.3040901@KingsMountain.com> Date: Fri, 05 Oct 2012 10:40:55 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: IETF WebSec WG 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] HSTS approval generating some news... 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, 05 Oct 2012 17:40:58 -0000 > As a personal comment, normally the formal release of the draft as RFC > is the best time for press releases of course, tho nobody did a "press release" that I know of (my blog hardly counts). as far as i can tell, the threatpost folks (or/and perhaps others) are simply watching ietf-announce@ietf.org (and mebbe (now) websec@) =JeffH From Jeff.Hodges@KingsMountain.com Fri Oct 5 11: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 DD6B621F880C for ; Fri, 5 Oct 2012 11:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.351 X-Spam-Level: X-Spam-Status: No, score=-100.351 tagged_above=-999 required=5 tests=[AWL=0.144, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgnRXYLLxeTF for ; Fri, 5 Oct 2012 11:27:21 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 0013221F8807 for ; Fri, 5 Oct 2012 11:27:19 -0700 (PDT) Received: (qmail 1217 invoked by uid 0); 5 Oct 2012 18:27:19 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 5 Oct 2012 18:27:19 -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=SnUqyeiR0N/sApW2Y47EXWn8gYB7OM//6eedZt/ZD34=; b=lW4B+CyBFKTChQBUHjt0K/eyUvFUHIAhBC3xUlrrPbvzmLSqImlY4OecSoqrRHFOtHaitJHtkNphFoUfC7jmRsZ5xUIfU3jOwpmygWOsDld/O1wt6VNLG1joqTooNYKZ; Received: from [216.113.168.128] (port=21315 helo=[10.244.137.77]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TKCcJ-00079V-Hl; Fri, 05 Oct 2012 12:27:19 -0600 Message-ID: <506F2688.5080308@KingsMountain.com> Date: Fri, 05 Oct 2012 11:27:20 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Paul E. Jones" 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG , 'Gonzalo Salgueiro' Subject: Re: [websec] draft-ietf-websec-strict-transport-sec and WebFinger 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, 05 Oct 2012 18:27:24 -0000 > Specifically, it is the use of a 301 as specified in Section > 7.2. If a UA requests initially visits a site like www.paypal.com, it would > not know if the host is an HSTS host or not. Use of 301 is not secure and > the user agent could be maliciously redirected to someplace other than a > site owned by PayPal, for example. Yes, this is well-understood and (prominently) noted in the security considerations... ### 14.6. Bootstrap MITM Vulnerability The bootstrap MITM (Man-In-The-Middle) vulnerability is a vulnerability users and HSTS Hosts encounter in the situation where the user manually enters, or follows a link, to an unknown HSTS Host using a "http" URI rather than a "https" URI. Because the UA uses an insecure channel in the initial attempt to interact with the specified server, such an initial interaction is vulnerable to various attacks (see Section 5.3 of [ForceHTTPS]). NOTE: There are various features/facilities that UA implementations may employ in order to mitigate this vulnerability. Please see Section 12 "User Agent Implementation Advice". ### Plus, this spec is now a done deal. However, the notion of devising some means for declaring general (web) host security policy and capabilities is one that's been discussed in various contexts (it's the question you're begging in your msg, IMV) -- and, yes, that's something to (now) put more cycles into thinking about. =JeffH From ynir@checkpoint.com Tue Oct 9 14:05: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 5728521F86D6 for ; Tue, 9 Oct 2012 14:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BEmNWKtsG+h for ; Tue, 9 Oct 2012 14:05:01 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9921F86D4 for ; Tue, 9 Oct 2012 14:05:01 -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 q99L4i0L017809 for ; Tue, 9 Oct 2012 23:04:49 +0200 X-CheckPoint: {50748FFF-0-1B221DC2-2FFFF} 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, 9 Oct 2012 23:04:43 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 9 Oct 2012 23:04:44 +0200 From: Yoav Nir To: IETF WebSec WG Date: Tue, 9 Oct 2012 23:04:42 +0200 Thread-Topic: Compact Header Encoding Thread-Index: Ac2mYbQquIRCdZdnTxe13b/K6Trm+g== Message-ID: References: <20121009113310.19442.26762.idtracker@ietfa.amsl.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_AD8995D6DE2B462CAF0C83B721FFDD37checkpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [websec] Compact Header Encoding 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, 09 Oct 2012 21:05:02 -0000 --_000_AD8995D6DE2B462CAF0C83B721FFDD37checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I've submitted the below draft. Like the Binary Optimized Header Encoding d= raft (from which I have borrowed heavily), this is not meant to be publishe= d, but as an alternative to the proposed header encoding. I believe that a = binary encoding can be more compact and have better security properties tha= n compressing text labels. Yoav Begin forwarded message: From: "internet-drafts@ietf.org" > Subject: New Version Notification for draft-nir-httpbis-che-00.txt Date: October 9, 2012 1:33:10 PM GMT+02:00 To: Yoav Nir > A new version of I-D, draft-nir-httpbis-che-00.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename: draft-nir-httpbis-che Revision: 00 Title: HTTP/2.0 Discussion: Compact Header Encoding Creation date: 2012-10-09 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-nir-httpbis-che-= 00.txt Status: http://datatracker.ietf.org/doc/draft-nir-httpbis-che Htmlized: http://tools.ietf.org/html/draft-nir-httpbis-che-00 Abstract: This document proposes an alternative encoding for HTTP headers. This encoding is considerably more compact than the uncompressed textual encoding in HTTP/1.1 and current HTTP/2.0 draft. --_000_AD8995D6DE2B462CAF0C83B721FFDD37checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

I've= submitted the below draft. Like the Binary Optimized Header Encoding draft= (from which I have borrowed heavily), this is not meant to be published, b= ut as an alternative to the proposed header encoding. I believe that a bina= ry encoding can be more compact and have better security properties than co= mpressing text labels.

Yoav

Begin= forwarded message:

Subject: New Version Notification for draft-nir-httpbis-che= -00.txt
Date: October 9, 2012 1:3= 3:10 PM GMT+02:00
To: Yoav Nir <ynir@checkpoint.com>
=


A new version of I-D, draft-nir-httpbis-che-00.txt
ha= s been successfully submitted by Yoav Nir and posted to the
IETF reposit= ory.

Filename: draft-nir-httpbis-che
Revision: 00
Title: HTTP/2.0 Discussion: Compact Header Encoding<= br>Creation date: = 2012-10-09
WG ID: = Individual Submission
Number of pages: 9
URL:   &n= bsp;         http://www.ietf= .org/internet-drafts/draft-nir-httpbis-che-00.txt
Status:  &nbs= p;       http://datatracker.ietf.org/doc/draft-ni= r-httpbis-che
Htmlized:        http://tools.= ietf.org/html/draft-nir-httpbis-che-00


Abstract:
 &= nbsp;This document proposes an alternative encoding for HTTP headers.
&= nbsp; This encoding is considerably more compact than the uncompressed=
  textual encoding in HTTP/1.1 and current HTTP/2.0 draft.

= --_000_AD8995D6DE2B462CAF0C83B721FFDD37checkpointcom_-- From ynir@checkpoint.com Tue Oct 9 14:14: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 8BCB321F84F0 for ; Tue, 9 Oct 2012 14:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GnQjKJ5uUPm for ; Tue, 9 Oct 2012 14:14:09 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6819B21F84A7 for ; Tue, 9 Oct 2012 14:14: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 q99LE7Zl019369 for ; Tue, 9 Oct 2012 23:14:08 +0200 X-CheckPoint: {50749232-1B-1B221DC2-2FFFF} 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, 9 Oct 2012 23:14:07 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 9 Oct 2012 23:14:07 +0200 From: Yoav Nir To: IETF WebSec WG Date: Tue, 9 Oct 2012 23:14:05 +0200 Thread-Topic: [websec] Compact Header Encoding Thread-Index: Ac2mYwQsY6dA/o3RTjaLO0CmTnUnJg== Message-ID: <69974315-3326-4788-B1C6-3221F1829FD1@checkpoint.com> References: <20121009113310.19442.26762.idtracker@ietfa.amsl.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: multipart/alternative; boundary="_000_6997431533264788B1C63221F1829FD1checkpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: Re: [websec] Compact Header Encoding 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, 09 Oct 2012 21:14:10 -0000 --_000_6997431533264788B1C63221F1829FD1checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. Wrong mailing list On Oct 9, 2012, at 11:04 PM, Yoav Nir wrote: Hi I've submitted the below draft. Like the Binary Optimized Header Encoding d= raft (from which I have borrowed heavily), this is not meant to be publishe= d, but as an alternative to the proposed header encoding. I believe that a = binary encoding can be more compact and have better security properties tha= n compressing text labels. Yoav Begin forwarded message: From: "internet-drafts@ietf.org" > Subject: New Version Notification for draft-nir-httpbis-che-00.txt Date: October 9, 2012 1:33:10 PM GMT+02:00 To: Yoav Nir > A new version of I-D, draft-nir-httpbis-che-00.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename: draft-nir-httpbis-che Revision: 00 Title: HTTP/2.0 Discussion: Compact Header Encoding Creation date: 2012-10-09 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-nir-httpbis-che-= 00.txt Status: http://datatracker.ietf.org/doc/draft-nir-httpbis-che Htmlized: http://tools.ietf.org/html/draft-nir-httpbis-che-00 Abstract: This document proposes an alternative encoding for HTTP headers. This encoding is considerably more compact than the uncompressed textual encoding in HTTP/1.1 and current HTTP/2.0 draft. _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec --_000_6997431533264788B1C63221F1829FD1checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. Wrong mailing list<= div>
On Oct 9, 2012, at 11:04 PM, Yoav Nir wrote:

Hi

I've submitted the below draft. Like the= Binary Optimized Header Encoding draft (from which I have borrowed heavily= ), this is not meant to be published, but as an alternative to the proposed= header encoding. I believe that a binary encoding can be more compact and = have better security properties than compressing text labels.
Yoav

Begin forwarded message:

Subject: New Versi= on Notification for draft-nir-httpbis-che-00.txt
Date: October 9, 2012 1:33:10 PM GMT+02:00
=
To: Yoav Nir <ynir@checkpoint.com>


A new version o= f I-D, draft-nir-httpbis-che-00.txt
has been successfully submitted by Y= oav Nir and posted to the
IETF repository.

Filename: draft-nir-httpbis-ch= e
Revision: 00
Title: = HT= TP/2.0 Discussion: Compact Header Encoding
Creation date: 2012-10-09
WG ID: Individual SubmissionNumber of pages: 9
URL:        &nbs= p;    http://www.ietf.org/internet-drafts/draft-nir-h= ttpbis-che-00.txt
Status:        =   http://datatracker.ietf.org/doc/draft-nir-httpbis-che
Htmlized: &= nbsp;      http://tools.ietf.org/html/draft-nir-httpbis-= che-00


Abstract:
  This document proposes an a= lternative encoding for HTTP headers.
  This encoding is cons= iderably more compact than the uncompressed
  textual encodin= g in HTTP/1.1 and current HTTP/2.0 draft.

<= br>
_______________________________________________
websec ma= iling list
websec@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/websec

<= /body>= --_000_6997431533264788B1C63221F1829FD1checkpointcom_-- From ynir@checkpoint.com Sun Oct 14 04:44:48 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 83F8621F84F3 for ; Sun, 14 Oct 2012 04:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIzXvdKViKHx for ; Sun, 14 Oct 2012 04:44:48 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8825B21F84F2 for ; Sun, 14 Oct 2012 04:44:46 -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 q9EBiiDD014807 for ; Sun, 14 Oct 2012 13:44:44 +0200 X-CheckPoint: {507AA40A-3-1B221DC2-2FFFF} 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; Sun, 14 Oct 2012 13:44:44 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 14 Oct 2012 13:44:44 +0200 From: Yoav Nir To: IETF WebSec WG Date: Sun, 14 Oct 2012 13:44:45 +0200 Thread-Topic: Call for Agenda Items Thread-Index: Ac2qAU0szbZJdZsTSrmokCW8xNfvFw== Message-ID: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [websec] Call for Agenda Items X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 11:44:48 -0000 Hi all The WebSec working group will meet in Atlanta on Thursday, November 8th at = 17:30 for one hour. On the agenda are the current work items: (X-)Frame-Options and Key Pinning= . If anyone has some other issue that they would like to present on (preferab= ly with an I-D!), please contact the chairs soon. Remember that the deadlin= e for new -00 drafts is tomorrow. See you all there, Alexey, Tobias, and Yoav From trac+websec@trac.tools.ietf.org Mon Oct 15 13:34: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 CD07221F89A3 for ; Mon, 15 Oct 2012 13:34:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFbJKb5HMOXu for ; Mon, 15 Oct 2012 13:34:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 36FEF21F893C for ; Mon, 15 Oct 2012 13:34:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:45414 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNrMC-0001bU-Db; Mon, 15 Oct 2012 22:33:48 +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: palmer@google.com X-Trac-Project: websec Date: Mon, 15 Oct 2012 20:33:48 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/50#comment:1 Message-ID: <066.91674ffdb16830cf57e514ccaa6a6031@trac.tools.ietf.org> References: <051.d94c07ecb13014cd35f8ea0580233d57@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <051.d94c07ecb13014cd35f8ea0580233d57@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [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: Mon, 15 Oct 2012 20:34:00 -0000 #50: Handing of pinning DSA public keys Changes (by palmer@…): * owner: draft-ietf-websec-key-pinning@… => palmer@… * status: new => assigned -- -------------------------+----------------------- Reporter: Tom Ritter | Owner: palmer@… Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Oct 15 13:35: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 90CF621F89FB for ; Mon, 15 Oct 2012 13:35:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXbdSBHOhm+G for ; Mon, 15 Oct 2012 13:35: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 307C421F89F4 for ; Mon, 15 Oct 2012 13:35:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:45745 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNrNm-0007Hj-2C; Mon, 15 Oct 2012 22:35:26 +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: palmer@google.com X-Trac-Project: websec Date: Mon, 15 Oct 2012 20:35:26 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/50#comment:2 Message-ID: <066.45ad2a59d36b6aafbe44dc3bff4045ec@trac.tools.ietf.org> References: <051.d94c07ecb13014cd35f8ea0580233d57@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <051.d94c07ecb13014cd35f8ea0580233d57@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [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: Mon, 15 Oct 2012 20:35:38 -0000 #50: Handing of pinning DSA public keys Changes (by palmer@…): * status: assigned => closed * resolution: => fixed Comment: Added this note to the draft. I'll send out a new version of the draft later on today. -- -------------------------+----------------------- Reporter: Tom Ritter | Owner: palmer@… Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+----------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Oct 15 13:42:06 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 1718A21F8A3C for ; Mon, 15 Oct 2012 13:42:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf6+tOYQ5taT for ; Mon, 15 Oct 2012 13:42:05 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 728FB21F8A39 for ; Mon, 15 Oct 2012 13:42:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:46169 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNrTy-0006Qb-42; Mon, 15 Oct 2012 22:41:50 +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: palmer@google.com X-Trac-Project: websec Date: Mon, 15 Oct 2012 20:41:50 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://grenache.tools.ietf.org/wg/websec/trac/ticket/50#comment:3 Message-ID: <066.1afac43bc5a6cd393acada90cd2abb25@trac.tools.ietf.org> References: <051.d94c07ecb13014cd35f8ea0580233d57@trac.tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <051.d94c07ecb13014cd35f8ea0580233d57@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [websec] #50: Handling of pinning DSA public keys (was: 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: Mon, 15 Oct 2012 20:42:06 -0000 #50: Handling of pinning DSA public keys -- -------------------------+----------------------- Reporter: Tom Ritter | Owner: palmer@… Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+----------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Oct 15 13:48: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 E140621F88B8 for ; Mon, 15 Oct 2012 13:48:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11JvKP6D1cto for ; Mon, 15 Oct 2012 13:48:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4311021F88B6 for ; Mon, 15 Oct 2012 13:48:53 -0700 (PDT) Received: from localhost ([127.0.0.1]:47064 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNrab-0000jO-Fc; Mon, 15 Oct 2012 22:48:41 +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: palmer@google.com X-Trac-Project: websec Date: Mon, 15 Oct 2012 20:48:41 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/51#comment:1 Message-ID: <066.91214a61d2329cdb30f30654a316908f@trac.tools.ietf.org> References: <051.e05eae1872f8f91c7be05e9dcd2eafec@trac.tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <051.e05eae1872f8f91c7be05e9dcd2eafec@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [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: Mon, 15 Oct 2012 20:48:54 -0000 #51: Clarification of section 2.4 Changes (by palmer@…): * owner: draft-ietf-websec-key-pinning@… => palmer@… * status: new => assigned -- -------------------------+----------------------- Reporter: Tom Ritter | Owner: palmer@… Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Oct 15 13:50: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 AC77D21F89B8 for ; Mon, 15 Oct 2012 13:50:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Xqni2peYMss for ; Mon, 15 Oct 2012 13:50:05 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 15AD121F8987 for ; Mon, 15 Oct 2012 13:50:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:47106 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNrbv-0003eE-NX; Mon, 15 Oct 2012 22:50:03 +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: palmer@google.com X-Trac-Project: websec Date: Mon, 15 Oct 2012 20:50:03 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/51#comment:2 Message-ID: <066.b08dcbb34294edb9d0450d6efa8bbf8b@trac.tools.ietf.org> References: <051.e05eae1872f8f91c7be05e9dcd2eafec@trac.tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <051.e05eae1872f8f91c7be05e9dcd2eafec@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [websec] #51: Clarification of section 2.4 (ignore pins where SPKI is insufficient) (was: 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: Mon, 15 Oct 2012 20:50:05 -0000 #51: Clarification of section 2.4 (ignore pins where SPKI is insufficient) Changes (by palmer@…): * status: assigned => closed * resolution: => fixed Comment: I have fixed this in the draft that will go out later today. -- -------------------------+----------------------- Reporter: Tom Ritter | Owner: palmer@… Type: defect | Status: closed Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+----------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Oct 15 16:09: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 BFA6821F88A0 for ; Mon, 15 Oct 2012 16:09:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMB-4Rv7KQpK for ; Mon, 15 Oct 2012 16:09:13 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5A14B21F889C for ; Mon, 15 Oct 2012 16:09:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:34988 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNtmP-0003Uy-8C; Tue, 16 Oct 2012 01:09:01 +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: palmer@google.com X-Trac-Project: websec Date: Mon, 15 Oct 2012 23:09:01 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/53 Message-ID: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: [websec] #53: Clarify status of pin validation when used with private trust anchors 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: Mon, 15 Oct 2012 23:09:14 -0000 #53: Clarify status of pin validation when used with private trust anchors Clarify in the I-D whether and how, when a the server's certificate chain chains up to a private trust anchor (as opposed to a publicly-trusted one such as in Mozilla's or Microsoft's root CA programs), the UA should perform pin validation. Options: * If anchor is private, do not perform pin validation * Always perform pin validation, presumably always failing when trust anchor is private * If anchor is private, validate against a database of private pins; ** If there is no DB of private pins, do not perform pin validation ** If there is no DB of private pins, perform pin validation anyway (presumably always failing) * Other options? Currently, Google Chrome opts to not perform pin validation when the trust anchor is private. -- -------------------------+---------------------- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Keywords: -------------------------+---------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Oct 15 16:09:30 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 ED95211E810E for ; Mon, 15 Oct 2012 16:09:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZKzlgfpk8Gl for ; Mon, 15 Oct 2012 16:09:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 57A8A11E810C for ; Mon, 15 Oct 2012 16:09:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:35002 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNtmq-0003Zr-VX; Tue, 16 Oct 2012 01:09:28 +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: palmer@google.com X-Trac-Project: websec Date: Mon, 15 Oct 2012 23:09:28 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/53#comment:1 Message-ID: <073.5ab4c3b95ff433c3679fa79c0ec5ab4a@trac.tools.ietf.org> References: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <058.27d97f66ed18f6f7f41e08788db76253@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [websec] #53: Clarify status of pin validation when used with private trust anchors 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: Mon, 15 Oct 2012 23:09:31 -0000 #53: Clarify status of pin validation when used with private trust anchors Changes (by palmer@…): * status: new => assigned -- -------------------------+----------------------- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Ticket URL: websec From internet-drafts@ietf.org Tue Oct 16 11:35: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 F278921F88C8; Tue, 16 Oct 2012 11:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPxTca4Sdjy2; Tue, 16 Oct 2012 11:35:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D5521F8973; Tue, 16 Oct 2012 11:35:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121016183544.18082.27544.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 11:35:44 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-03.txt 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, 16 Oct 2012 18:35:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Filename : draft-ietf-websec-key-pinning-03.txt Pages : 17 Date : 2012-10-16 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one or more of the pinned fingerprints for that host. By effectively reducing the scope of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities and other authentication errors and attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+websec@trac.tools.ietf.org Tue Oct 16 11:48: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 BF2A921F85F3 for ; Tue, 16 Oct 2012 11:48:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lH5cmEK0tBK for ; Tue, 16 Oct 2012 11:48:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B284121F85C0 for ; Tue, 16 Oct 2012 11:48:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:34172 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOCBk-0004Oq-UD; Tue, 16 Oct 2012 20:48:24 +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: palmer@google.com X-Trac-Project: websec Date: Tue, 16 Oct 2012 18:48:24 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/52#comment:1 Message-ID: <066.53dc0548a11c8bcee6b39cbf7788ab51@trac.tools.ietf.org> References: <051.df0a7eb62cdb49309147ff5b8eb8e401@trac.tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <051.df0a7eb62cdb49309147ff5b8eb8e401@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [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: Tue, 16 Oct 2012 18:48:37 -0000 #52: Clarification of section 2.3.1 Changes (by palmer@…): * owner: draft-ietf-websec-key-pinning@… => palmer@… * status: new => assigned -- -------------------------+----------------------- Reporter: Tom Ritter | Owner: palmer@… Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Ticket URL: websec From palmer@google.com Tue Oct 16 11:49: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 5A76121F87EC for ; Tue, 16 Oct 2012 11:49:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqqqOa05Y+Wb for ; Tue, 16 Oct 2012 11:49:03 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81F1A21F87E4 for ; Tue, 16 Oct 2012 11:49:03 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so5080178lbo.31 for ; Tue, 16 Oct 2012 11:49:02 -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 :content-type:content-transfer-encoding:x-system-of-record; bh=RSxPO6UGXwolLT6DNMijZZz39H/uEE6TILMXGyDDX9o=; b=WLrpbpYzszjUUFuXvvTMjZ9MbWcZDhNx6WsizzLtvSOKwRNKBa5T/11XOTcnHeGlsK funTWYZMqFcKvhHaoyWGj5H8Wozcu6ebj+bGqo8Zr6O0hxWv0ZJ0//cB4GJt0sCydXot 66SU536suNXGWyRWCZLw6PBHdiKK7kAHynT6LU6UJ81hxHGY6cfCS9FW51a8HeeAexYo NuvkVhXz9nQPk/skjX++C+OrtJoKGBMAoC12IGQqAsbXeX6DlpsWrq+/Hg0cWCSvrThJ KwxVkqBCBMJ4CInIhsmA0WSPIbj+ASvT2KJB5xAKnSQfh7ujT+teryFqLt6YsTbqmqiT ThcA== 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 :content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=RSxPO6UGXwolLT6DNMijZZz39H/uEE6TILMXGyDDX9o=; b=QB0QfCHpvjJcI3ZunWwSKVGxlyXM/0sgY/XETgTqJQR02fZpTDfC/n8WJKPRHOB9GT mGFvB5G2n68KwABAoOnaDCfIdjJvbVuPM59gKkSkvj5kLu6drunEMnSbbjVGONtCMTmz FeaGzVTepYrFWWuwtuhh0o5jzc5Sai31DQT9V/9EAqouQmbiwQ95ucW3sObV0QxnvrSd 95lKVdPW6Lvd/WoZ1MUdtiTNqlo1cP8G9McuHxvTxv8gfP/9wALc08QhklZOzKrUXbev N97SgBkf48vsQ+/g5xWlTZdTkGaL5eQ37FzsHJyBNWQAfp8ITdASfQQklp8eS3HjeD94 HaTA== MIME-Version: 1.0 Received: by 10.152.133.140 with SMTP id pc12mr13574547lab.53.1350413342485; Tue, 16 Oct 2012 11:49:02 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Tue, 16 Oct 2012 11:49:02 -0700 (PDT) In-Reply-To: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 11:49:02 -0700 Message-ID: From: Chris Palmer To: IETF WebSec WG , Ryan Sleevi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnes1MVOGMw4GbxPBHrcJOFMTLKSkuChxMXpyNTyQ8mk7QImZns6TEKWAw+4uiunit5dKzJ6OSdlYJGD1aAp4yVLkiNxa67f6zyTN5DXZkatVAjCChGNnzzbXmYR8T0g1RrOrkueZdMTlgbliiz6mCQjFvGVfeGYLxCIIDvTpVQ0fjqtxNf1mYndCX1Ln8zdIRUCVYf Subject: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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, 16 Oct 2012 18:49:04 -0000 Hi all, This is just a quick interim version to respond to Tom Ritter's bugs that he filed in the issue tracker. We still have some issues to resolve around pin activation (=C3=A0 la TACK), max-age, and whether and how to perform pin validation when X.509 chains chain up to private trust anchors. http://trac.tools.ietf.org/wg/websec/trac/ticket/52 http://trac.tools.ietf.org/wg/websec/trac/ticket/53 Any other issues anyone wants to raise? Thanks. ---------- Forwarded message ---------- From: Date: Tue, Oct 16, 2012 at 11:35 AM Subject: New Version Notification for draft-ietf-websec-key-pinning-03.txt To: palmer@google.com Cc: cevans@google.com A new version of I-D, draft-ietf-websec-key-pinning-03.txt has been successfully submitted by Chris Palmer and posted to the IETF repository. Filename: draft-ietf-websec-key-pinning Revision: 03 Title: Public Key Pinning Extension for HTTP Creation date: 2012-10-16 WG ID: websec Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-03.txt Status: http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinn= ing Htmlized: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-0= 3 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-key-pinning-03 Abstract: This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one or more of the pinned fingerprints for that host. By effectively reducing the scope of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities and other authentication errors and attacks. The IETF Secretariat From ynir@checkpoint.com Tue Oct 16 13:16: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 B13271F0C7E for ; Tue, 16 Oct 2012 13:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHK2eNRn-Y33 for ; Tue, 16 Oct 2012 13:16:45 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AA18E1F0C69 for ; Tue, 16 Oct 2012 13:16:44 -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 q9GKGenV030186; Tue, 16 Oct 2012 22:16:40 +0200 X-CheckPoint: {507DBEEB-1-1B221DC2-2FFFF} 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, 16 Oct 2012 22:16:39 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 16 Oct 2012 22:16:39 +0200 From: Yoav Nir To: Chris Palmer Date: Tue, 16 Oct 2012 22:16:38 +0200 Thread-Topic: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt Thread-Index: Ac2r2yZP07IFe9BjSISBP2VVTmv/nQ== Message-ID: <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> References: <20121016183544.18082.34326.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IETF WebSec WG , Ryan Sleevi Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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, 16 Oct 2012 20:16:45 -0000 SGkgQ2hyaXMuDQoNCkdvb2QgdG8gc2VlIHRoaXMuIERvIHlvdSBpbnRlbmQgdG8gcHVibGlzaCBh bm90aGVyIHJldmlzaW9uIGJ5IHRoZSBkcmFmdCBzdWJtaXNzaW9uIGN1dG9mZiBkYXRlIG5leHQg TW9uZGF5Pw0KDQpPciB3b3VsZCB5b3UgbGlrZSB1cyB0byBkaXNjdXNzIHRoZXNlIGlzc3VlcyB0 byByZXNvbHZlIGF0IHRoZSBtZWV0aW5nIGluIEF0bGFudGE/DQoNClRoYW5rcw0KDQpZb2F2DQoN Ck9uIE9jdCAxNiwgMjAxMiwgYXQgODo0OSBQTSwgQ2hyaXMgUGFsbWVyIHdyb3RlOg0KDQo+IEhp IGFsbCwNCj4gDQo+IFRoaXMgaXMganVzdCBhIHF1aWNrIGludGVyaW0gdmVyc2lvbiB0byByZXNw b25kIHRvIFRvbSBSaXR0ZXIncyBidWdzDQo+IHRoYXQgaGUgZmlsZWQgaW4gdGhlIGlzc3VlIHRy YWNrZXIuIFdlIHN0aWxsIGhhdmUgc29tZSBpc3N1ZXMgdG8NCj4gcmVzb2x2ZSBhcm91bmQgcGlu IGFjdGl2YXRpb24gKMOgIGxhIFRBQ0spLCBtYXgtYWdlLCBhbmQgd2hldGhlciBhbmQNCj4gaG93 IHRvIHBlcmZvcm0gcGluIHZhbGlkYXRpb24gd2hlbiBYLjUwOSBjaGFpbnMgY2hhaW4gdXAgdG8g cHJpdmF0ZQ0KPiB0cnVzdCBhbmNob3JzLg0KPiANCj4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvd2cvd2Vic2VjL3RyYWMvdGlja2V0LzUyDQo+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL3dlYnNlYy90cmFjL3RpY2tldC81Mw0KPiANCj4gQW55IG90aGVyIGlzc3VlcyBhbnlvbmUg d2FudHMgdG8gcmFpc2U/IFRoYW5rcy4NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQo+IEZyb206ICA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pg0KPiBEYXRlOiBUdWUsIE9jdCAxNiwgMjAxMiBhdCAxMTozNSBBTQ0KPiBTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtd2Vic2VjLWtleS1waW5uaW5nLTAz LnR4dA0KPiBUbzogcGFsbWVyQGdvb2dsZS5jb20NCj4gQ2M6IGNldmFuc0Bnb29nbGUuY29tDQo+ IA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXdlYnNlYy1rZXkt cGlubmluZy0wMy50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaHJp cyBQYWxtZXIgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmls ZW5hbWU6ICAgICAgICBkcmFmdC1pZXRmLXdlYnNlYy1rZXktcGlubmluZw0KPiBSZXZpc2lvbjog ICAgICAgIDAzDQo+IFRpdGxlOiAgICAgICAgICAgUHVibGljIEtleSBQaW5uaW5nIEV4dGVuc2lv biBmb3IgSFRUUA0KPiBDcmVhdGlvbiBkYXRlOiAgIDIwMTItMTAtMTYNCj4gV0cgSUQ6ICAgICAg ICAgICB3ZWJzZWMNCj4gTnVtYmVyIG9mIHBhZ2VzOiAxNw0KPiBVUkw6DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtd2Vic2VjLWtleS1waW5uaW5nLTAz LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi13ZWJzZWMta2V5LXBpbm5pbmcNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXdlYnNlYy1rZXktcGlubmluZy0wMw0KPiBE aWZmOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXdlYnNl Yy1rZXktcGlubmluZy0wMw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgVGhpcyBtZW1vIGRlc2NyaWJl cyBhbiBleHRlbnNpb24gdG8gdGhlIEhUVFAgcHJvdG9jb2wgYWxsb3dpbmcgd2ViDQo+ICAgaG9z dCBvcGVyYXRvcnMgdG8gaW5zdHJ1Y3QgdXNlciBhZ2VudHMgKFVBcykgdG8gcmVtZW1iZXIgKCJw aW4iKSB0aGUNCj4gICBob3N0cycgY3J5cHRvZ3JhcGhpYyBpZGVudGl0aWVzIGZvciBhIGdpdmVu IHBlcmlvZCBvZiB0aW1lLiAgRHVyaW5nDQo+ICAgdGhhdCB0aW1lLCBVQXMgd2lsbCByZXF1aXJl IHRoYXQgdGhlIGhvc3QgcHJlc2VudCBhIGNlcnRpZmljYXRlIGNoYWluDQo+ICAgaW5jbHVkaW5n IGF0IGxlYXN0IG9uZSBTdWJqZWN0IFB1YmxpYyBLZXkgSW5mbyBzdHJ1Y3R1cmUgd2hvc2UNCj4g ICBmaW5nZXJwcmludCBtYXRjaGVzIG9uZSBvciBtb3JlIG9mIHRoZSBwaW5uZWQgZmluZ2VycHJp bnRzIGZvciB0aGF0DQo+ICAgaG9zdC4gIEJ5IGVmZmVjdGl2ZWx5IHJlZHVjaW5nIHRoZSBzY29w ZSBvZiBhdXRob3JpdGllcyB3aG8gY2FuDQo+ICAgYXV0aGVudGljYXRlIHRoZSBkb21haW4gZHVy aW5nIHRoZSBsaWZldGltZSBvZiB0aGUgcGluLCBwaW5uaW5nIG1heQ0KPiAgIHJlZHVjZSB0aGUg aW5jaWRlbmNlIG9mIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MgZHVlIHRvIGNvbXByb21pc2Vk DQo+ICAgQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllcyBhbmQgb3RoZXIgYXV0aGVudGljYXRpb24g ZXJyb3JzIGFuZA0KPiAgIGF0dGFja3MuDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiB3ZWJzZWMgbWFpbGluZyBsaXN0DQo+IHdlYnNlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnNlYw0KPiBJxqfvv73vv71b77+9KF5yQ++/ vXtT77+91qVJ77+9Lu+/vStyGe+/vV7vv73vv70NCg0K From tom@ritter.vg Wed Oct 17 07:23: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 CADE721F84B6 for ; Wed, 17 Oct 2012 07:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZUl2RHoXxFX for ; Wed, 17 Oct 2012 07:23: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 A18F221F851C for ; Wed, 17 Oct 2012 07:23:45 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so8245881vbb.31 for ; Wed, 17 Oct 2012 07:23:44 -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=JRIsQQ4HGfSYJp8FUr7cRh0sRVIgKlhXC9rU+YcvH5c=; b=zZdJVhX6dCjgGzfwziMHcSY0KDmJfLptkfdEdr1g2r8h/dOxfkju8ytL6tG1CU4i/z iKiJmHx6RrFk6wKW/E/5XhJ8hvyB80JrRgyejyw50qcoha1gJXAzoWsFOiu1Xtf2zt6L RX2a4QWRdwggR1WlPr3A1LkEf1TLHXQpQPPP0= 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=JRIsQQ4HGfSYJp8FUr7cRh0sRVIgKlhXC9rU+YcvH5c=; b=l8QC4d8khlAsC+x3pARKJW6L/q7dgEB75CZhO2taM/QfEebBdzEDkZvty6a5uiz1Ek Vai3DyvN+MJNjyfHVF+PTp+hS4NH8egdm+O+rHqPqX1VSAFp1A69n3utSZZHnZ0OIzOt DiRP8xM/7fm2gZYDu0uT6RTrDQNuginFhoZfqlKjqYEcDZ3AeSa5zIq6OGHHktySkLvu jXNGGwR+V43I77XHQFug7FcITG6k9EBoGe5rXUkhcoqNWgTEsXs+tQYoFAeMGmzfNnu7 0bgfMULCM5UT3VGm7vBS/u+ZYE316HuOuYk6UMAdlqh8uu0gvy/yZ4QkEle7BvMxciDS lQ4Q== Received: by 10.58.239.162 with SMTP id vt2mr6723553vec.1.1350483824308; Wed, 17 Oct 2012 07:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Wed, 17 Oct 2012 07:23:24 -0700 (PDT) In-Reply-To: <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> From: Tom Ritter Date: Wed, 17 Oct 2012 10:23:24 -0400 Message-ID: To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn86THlmscG6u5gfjAFlXFNDc6RbsgcymywJxucUhWTEPS2GKSoCyYD9Bp844woAGG14dcb Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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: Wed, 17 Oct 2012 14:23:53 -0000 Some musings after reading again: Section 2.3 "Noting Pins": I wonder if it is worth moving "The UAs MUST ignore Public-Key-Pins response header fields received on HTTP (non-HTTPS) connections." outside the criteria to be unambiguous that a client should not "discard any previously set Pinning Metadata" if it receives the header over HTTP. Or if it's reasonable enough to assume no one would get confused. Similarly, I wonder if there was some situation that could result in an attacker-induced 'errored' TLS connection that still sent the header, resulting in the data being discarded... Section 2.4: "Validating Pinned Connections": For the purposes of Pin Validation, the UA MUST ignore certificates who SPKI cannot be taken in isolation and superfluous certificates in the chain that do not form part of the validating chain. I know I just modified this, but the second phrase just hit me. Because path construction is non-standard, could a client wind up in a situation where the site pinned to CA_Alice, with the intended path CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was trusted, the ultimate validating chain was simply CA_Bob -> Intermediate -> Leaf? I'm not sure what the right way to counteract that would be... 2.5: "Pin Validity Times" I find the "current + current - initial" / "(b) the amount of time the pin has been noted" item confusing, and am not sure what it means from reading only the draft. If I'm not the only one, it might be worth clarifying. 2.6. "Interactions With Preloaded Pin Lists" If closing private browsing mode or clearing saved data also clears preloaded pins (and I think it should), this would cause a revert to the preloaded pins, which may break sites. A workaround may be to disable a preloaded pin if a new pin is seen, and keep that disabled even after the saved data wipe/private browsing mode close. To prevent using this as a backdoor into tracking, the preloaded pins should be sanity checked for "Is this organization likely to abuse the feature." Again, excited about this - thanks for the work. -tom From ryan-ietfhasmat@sleevi.com Wed Oct 17 09:36:46 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 760EB21F86A3 for ; Wed, 17 Oct 2012 09:36:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG2cMhnMmzeV for ; Wed, 17 Oct 2012 09:36:45 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC9A21F8698 for ; Wed, 17 Oct 2012 09:36:45 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 0E3121F0084; Wed, 17 Oct 2012 09:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=DaQqwk//p0+0mpUWcQpmHO2r6Oo=; b=qrs0dZLp389bcjrs3 s0GXdRZE7Y03XcDlZdmYNvryQdyMMNiG9MEP33iDFezJSay+1+53zZKIpuiGg4GV yH4M5L9RxTARCkW9BvaDpnMMZaU4Iijmhc7yUU61iXJJIupIrQiqNL3pbJMKVWc1 877229tOkYlH8WQHYgtW0x+QUA= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPA id ABEA91F001E; Wed, 17 Oct 2012 09:36:44 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 17 Oct 2012 09:36:43 -0700 Message-ID: <2a70aa074ea293a87a82b85febcfbd70.squirrel@webmail.dreamhost.com> In-Reply-To: References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> Date: Wed, 17 Oct 2012 09:36:43 -0700 From: "Ryan Sleevi" To: "Tom Ritter" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 16:36:46 -0000 On Wed, October 17, 2012 7:23 am, Tom Ritter wrote: > Section 2.4: "Validating Pinned Connections": > > For the purposes of Pin Validation, the UA MUST ignore > certificates who SPKI cannot be taken in isolation and superfluous > certificates in the chain that do not form part of the validating > chain. > > I know I just modified this, but the second phrase just hit me. > Because path construction is non-standard, could a client wind up in a > situation where the site pinned to CA_Alice, with the intended path > CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was > trusted, the ultimate validating chain was simply CA_Bob -> > Intermediate -> Leaf? I'm not sure what the right way to counteract > that would be... Yes. This is one of the troubling areas of the current draft, and that ha= s been particularly challenging when implementing within Chromium. It's not clear whether your case was demonstrative of the inter-organizational cross-signing relationships (a new CA getting cross-certified by an existing, established CA) or whether it was an intra-organizational relationship, such as a SHA-1 root cross-signing the SHA-2 root, until such a time as the SHA-2 root is included in the trust stores. In the case of inter-organizational, where CA_Alice and CA_Bob are two distinct entities, it's generally seen as unlikely that the "site" would pin to CA_Alice, since their business relationship is almost certainly with CA_Bob (by virtue of CA_Bob having certified Intermediate). So if th= e site were to pin to CA_Bob, their issue would be mitigated. However, for the intra-organizational scenario, where intermediates and roots are changed or re-issued more commonly than site operators may realized or be re-configuring, I agree that this is a very real problem. The mitigation for this has been to make the pins an appropriate cross-section of both root and intermediates - intermediates in the event of new roots being issued, and roots in the event of the CA issuing new intermediates (and serving them up via AIA, as the common case is) This leaves the broader question of "How does the site operator know abou= t CA_Alice and CA_Bob to begin with". One possible solution for this is a report-but-unenforced mode, where user agents could describe their observed chains to the site. As unseemly as this is, it's very likely tha= t many site operators - even Very Large, High Value sites - may not have a full understanding of the PKI that they're a participant in. Another solution is to rely on policy changes in root stores, such as Mozilla's recent proposed CA Certificate Store requirements change, which would encourage (by requiring, with only one acceptable alternative) the public disclosure of such CA hierarchies. As a result of such changes, there would be knowledge of the relationship between CA_Alice and CA_Bob, which under today's model, is actually quite hard for site operators to discover. Because pinning permits multiple entries, and is considered satisfied so long as at least one SPKI appears in the client validated chain, the issu= e here is largely not a technical challenge, but an operational one, and that's why this issue is not critical, but remains very important. From carl@redhoundsoftware.com Wed Oct 17 10:04:15 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 EAD7A21F8552 for ; Wed, 17 Oct 2012 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.37 X-Spam-Level: X-Spam-Status: No, score=-4.37 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtaQ8eVKuOzy for ; Wed, 17 Oct 2012 10:04:15 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 510F321F8587 for ; Wed, 17 Oct 2012 10:04:15 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so7053068qcg.31 for ; Wed, 17 Oct 2012 10:04:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=gvQ9f5T42UanvgANbxN06Bgs39o25Te9BXPHam9vCVk=; b=SL1QmMZnTEFkJtOe98EQzXnu9/phZqBuV3wysbTc5G1oT4fUrjODTGqLwibNKyQg0G qHY16tbmODfzbe+v2fQam29d0UWbpY6ytw6wO5WcBlqiU5+fBDn89goYEHqw74X+LtOn /7DO+mrxJKgXw2KwZ10hjR5XciexzQ1CvoNd3OKJ2m8sQfzDia3ciRhCyUIJGATiNk1t Sz0p8ZDLotVngvzw/Q5rZ1oxHv8kiYGhaB8jESrJ+HCRjSE8RjDQ0CRw/YrbsNx06R3t x6i41nx8bWAuHuYXjH0QmNmFrAwPrbYzm7rPR3AJjCzin7U2hX8TFTKtL77U5Lambm2q vAxA== Received: by 10.224.207.8 with SMTP id fw8mr33061371qab.92.1350493452886; Wed, 17 Oct 2012 10:04:12 -0700 (PDT) Received: from [192.168.2.8] (pool-72-66-83-116.washdc.fios.verizon.net. [72.66.83.116]) by mx.google.com with ESMTPS id a8sm20085159qew.11.2012.10.17.10.04.10 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 10:04:11 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 17 Oct 2012 13:04:06 -0400 From: Carl Wallace To: , Tom Ritter Message-ID: Thread-Topic: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt In-Reply-To: <2a70aa074ea293a87a82b85febcfbd70.squirrel@webmail.dreamhost.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnXtuPEohGWMAmZSn/V3162PT3ouPxZ5R0N/yMoWa7+wIFE5VUqupzBi0BywSMtVxj/3WbJ Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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: Wed, 17 Oct 2012 17:04:16 -0000 On 10/17/12 12:36 PM, "Ryan Sleevi" wrote: > >This leaves the broader question of "How does the site operator know about >CA_Alice and CA_Bob to begin with". One possible solution for this is a >report-but-unenforced mode, where user agents could describe their >observed chains to the site. As unseemly as this is, it's very likely that >many site operators - even Very Large, High Value sites - may not have a >full understanding of the PKI that they're a participant in. A tool that builds all possible paths that the site operator can run without involving any users would be good too. The site operator mainly needs to know where its certificate chains against public stuff and could check that independently. This should come close to relegating the user report tool to oddball instances. >Another solution is to rely on policy changes in root stores, such as >Mozilla's recent proposed CA Certificate Store requirements change, which >would encourage (by requiring, with only one acceptable alternative) the >public disclosure of such CA hierarchies. As a result of such changes, >there would be knowledge of the relationship between CA_Alice and CA_Bob, >which under today's model, is actually quite hard for site operators to >discover. Even with disclosure a builder tool that illustrates possible chains would be useful. From ryan-ietfhasmat@sleevi.com Wed Oct 17 10:52:55 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 9826221F8673 for ; Wed, 17 Oct 2012 10:52:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faD78Tgcad0X for ; Wed, 17 Oct 2012 10:52:54 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9981D21F8639 for ; Wed, 17 Oct 2012 10:52:54 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 21662350079; Wed, 17 Oct 2012 10:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=ifqme3Jz6HQ5yh0nu9YljA0quoU=; b=KU0+gWDorHxER/zrM hRoz0T7zAWTvT9Xk8ljX3T3+WBnLovSindRS7CeiDH2H2Q+INa4minx1jbaiN5Qp KN8tJqGr9bIBO1LxhZAoFLiq31ortjst5x1XQOXDbNl3sGTWqAs5G/bO5Fc9eRTT t/JmwhVU5mwMvKjqFzS7x4U1ZQ= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 7FF75350058; Wed, 17 Oct 2012 10:52:53 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 17 Oct 2012 10:52:52 -0700 Message-ID: In-Reply-To: References: Date: Wed, 17 Oct 2012 10:52:52 -0700 From: "Ryan Sleevi" To: "Carl Wallace" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:52:55 -0000 On Wed, October 17, 2012 10:04 am, Carl Wallace wrote: > > On 10/17/12 12:36 PM, "Ryan Sleevi" wrote= : > > > > >This leaves the broader question of "How does the site operator know > > about > >CA_Alice and CA_Bob to begin with". One possible solution for this is = a > >report-but-unenforced mode, where user agents could describe their > >observed chains to the site. As unseemly as this is, it's very likely > > that > >many site operators - even Very Large, High Value sites - may not have= a > >full understanding of the PKI that they're a participant in. > > A tool that builds all possible paths that the site operator can run > without involving any users would be good too. The site operator main= ly > needs to know where its certificate chains against public stuff and co= uld > check that independently. This should come close to relegating the us= er > report tool to oddball instances. The problem in general with such tools (and I'm sure this will be a talking point during the WPKOPS and CERTTRANS BOFs) is that it's actually a rather hard problem to know exactly what certificates exist. Beyond the issues such as "What user agents have what behaviour" and "wha= t intermediates are baked into what platforms," one of the more problematic areas is related to the AIA chasing that is functionally and fundamentall= y necessary to maintain parity and access to a depressingly vast majority o= f sites. When the site operator installs their cert, they may only install on thei= r HTTPS server (Site_Cert, Intermediate). This is because CA_Bob and the site operator are assuming that CA_Bob can be omitted, since it's the roo= t of trust. For clients that don't trust CA_Bob, Intermediate has an AIA to a URL tha= t contains CA_Bob, which is cross-certified by CA_Alice. So the possible chains are: Site_Cert (via TLS) -> Intermediate (via TLS) -> CA_Bob (obtained out-of-band) Site_Cert (via TLS) -> Intermediate (via TLS) -> CA_Bob (obtained via AIA= ) -> CA_Alice (obtained out of band) Now what if CA_Bob goes out of business/is acquired? Well, one common trick is to update the URL of Intermediate to point to a new version, signed by CA_Charles. When the path building for Intermediate (via TLS) fails, user agents may "unwind" their depth search, and attempt the AIA fetch from Site_Cert, leading to a new chain. Site_Cert (via TLS) -> Intermediate (via AIA) -> CA_Charles (obtained out-of-band) Or CA_Bob may decide they want to sever ties with CA_Alice, and go with CA_Charlene. They simply replace the AIA URL used to serve up the cross-certified CA_Bob. This is all well and good for "point in time" evaluation - but the added crux on this is that the site operator may be noticing all these shenanigans, and now explicitly configure their server to send a particular chain they believe is accurate/optimal. Also, clients may be caching intermediates as well. So it's "Very Hard" to actually know what *all* possible paths are, because the possible paths change over time, and some paths may no longer be knowable by such a tool when the certificate is being evaluated, because the old certificates served at URL X are now replaced with newer ones. You may think I'm just grasping at edge cases, but unfortunately every situation I just described above has been done by major CAs, including some that might be considered of the "Too big too fail" variety. So it's definitely an issue, and that's some from of client reporting seems necessary (with transparency + disclosure to make it easier to write such tools in the future) From carl@redhoundsoftware.com Wed Oct 17 11:08: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 61EAF21F8681 for ; Wed, 17 Oct 2012 11:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxWs8BuAOlPd for ; Wed, 17 Oct 2012 11:08:13 -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 6ABA721F84D3 for ; Wed, 17 Oct 2012 11:08:13 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so9190008vcb.31 for ; Wed, 17 Oct 2012 11:08:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=4d4OnzSVGCVR3eZbk2/lhlTv5TAZ6EsUdgN1zPupmvQ=; b=pOT6gOysRvb9X/chXbrAjZNzItLubu+PEjLfv5BRe+iRYPizwTG18P9qaB4e0W/1ni /KeDc6e3SmM0BAY5cAM233nfGtzOoDvHkMSikMsy3XOdHICcNv9ietiEo+EfIz6ZKH8m 3iaqOMsP8rM4vjYZkls1LRGQHleILC2GCVKhUWXePgij6Wcj/DEkg73FkIksknV7WHIQ +JuZwxTBeuzYFN9Wi3/8IvsC4wnQUn8CDS1GrS+0Jgeg/uIik2MQOYICkDL0Avux3uHe TSZZ3drGeH6vck+huSrPYnCiondGfNXs446uamQlFof4vF/J1Nz4MpHck5HSRoiTl3sQ Ievg== Received: by 10.52.77.101 with SMTP id r5mr8702986vdw.25.1350497286123; Wed, 17 Oct 2012 11:08:06 -0700 (PDT) Received: from [192.168.2.8] (pool-72-66-83-116.washdc.fios.verizon.net. [72.66.83.116]) by mx.google.com with ESMTPS id rx5sm1555363vec.11.2012.10.17.11.07.56 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 11:08:05 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 17 Oct 2012 14:07:48 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmUX5h3MVqUpF+BAq7jPQ0SUOqf7pk3qHhBTOR0KQhJZn6QhIfT031PfxMUIo3T3e/k/pjl Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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: Wed, 17 Oct 2012 18:08:14 -0000 On 10/17/12 1:52 PM, "Ryan Sleevi" wrote: >On Wed, October 17, 2012 10:04 am, Carl Wallace wrote: >> >> On 10/17/12 12:36 PM, "Ryan Sleevi" wrote: >> >> > >> >This leaves the broader question of "How does the site operator know >> > about >> >CA_Alice and CA_Bob to begin with". One possible solution for this is a >> >report-but-unenforced mode, where user agents could describe their >> >observed chains to the site. As unseemly as this is, it's very likely >> > that >> >many site operators - even Very Large, High Value sites - may not have >>a >> >full understanding of the PKI that they're a participant in. >> >> A tool that builds all possible paths that the site operator can run >> without involving any users would be good too. The site operator >>mainly >> needs to know where its certificate chains against public stuff and >>could >> check that independently. This should come close to relegating the >>user >> report tool to oddball instances. > >The problem in general with such tools (and I'm sure this will be a >talking point during the WPKOPS and CERTTRANS BOFs) is that it's actually >a rather hard problem to know exactly what certificates exist. Why do you care what certificates exist vs. what certificates are generally available (via AIAs and such)? The certificates available from most AIAs are constant for most people. I'm not suggesting that a tool would be a 100% solution, but it'd be a good first shot vs. collecting data from some (manually run?) user tool after a problem is observed. > >Beyond the issues such as "What user agents have what behaviour" and "what >intermediates are baked into what platforms," one of the more problematic >areas is related to the AIA chasing that is functionally and fundamentally >necessary to maintain parity and access to a depressingly vast majority of >sites. There would be some homework to collect the full set of trust anchors that may be encountered. This shouldn't be that hard to maintain if a collective effort focused on it. It'd make no difference if the set used to harvest public keys was too large. >When the site operator installs their cert, they may only install on their >HTTPS server (Site_Cert, Intermediate). This is because CA_Bob and the >site operator are assuming that CA_Bob can be omitted, since it's the root >of trust. > >For clients that don't trust CA_Bob, Intermediate has an AIA to a URL that >contains CA_Bob, which is cross-certified by CA_Alice. > >So the possible chains are: >Site_Cert (via TLS) -> Intermediate (via TLS) -> CA_Bob (obtained >out-of-band) >Site_Cert (via TLS) -> Intermediate (via TLS) -> CA_Bob (obtained via AIA) >-> CA_Alice (obtained out of band) > >Now what if CA_Bob goes out of business/is acquired? Well, one common >trick is to update the URL of Intermediate to point to a new version, >signed by CA_Charles. When the path building for Intermediate (via TLS) >fails, user agents may "unwind" their depth search, and attempt the AIA >fetch from Site_Cert, leading to a new chain. > >Site_Cert (via TLS) -> Intermediate (via AIA) -> CA_Charles (obtained >out-of-band) > >Or CA_Bob may decide they want to sever ties with CA_Alice, and go with >CA_Charlene. They simply replace the AIA URL used to serve up the >cross-certified CA_Bob. > >This is all well and good for "point in time" evaluation - but the added >crux on this is that the site operator may be noticing all these >shenanigans, and now explicitly configure their server to send a >particular chain they believe is accurate/optimal. Also, clients may be >caching intermediates as well. What is a user report but a "point in time" evaluation? >So it's "Very Hard" to actually know what *all* possible paths are, >because the possible paths change over time, and some paths may no longer >be knowable by such a tool when the certificate is being evaluated, >because the old certificates served at URL X are now replaced with newer >ones. Monitoring is necessary to keep track of changes. It sucks, but it's the way it is. >You may think I'm just grasping at edge cases, but unfortunately every >situation I just described above has been done by major CAs, including >some that might be considered of the "Too big too fail" variety. So it's >definitely an issue, and that's some from of client reporting seems >necessary (with transparency + disclosure to make it easier to write such >tools in the future) I don't doubt any of this, but still think a crawler tool would be sufficient in many (if not most) cases. It'd probably be instructive to run for the site operators in the worst case. Note, I did not suggest that a user report feature was not a good or necessary thing, only that a builder tool for the site operator to run without bothering any users would be nice to have in the toolbox too. Thinking about it, they may well be the same tool if the user reporting tool is aggressive enough. From ryan-ietfhasmat@sleevi.com Wed Oct 17 11:33: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 7CC5521F84DE for ; Wed, 17 Oct 2012 11:33:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVKU3rdfomfd for ; Wed, 17 Oct 2012 11:33:46 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFA621F8504 for ; Wed, 17 Oct 2012 11:33:46 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 7088D598060; Wed, 17 Oct 2012 11:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=E9Ey9NFiTyKt2D8pp2MzS+c2Vic=; b=vE3GkP5Cdt1/ZwW/E HUCU8crTVHJukhjhd+ZT/7vJmyUCUxZApnMSgrYg5HoBRh42AoDEU0k7fPkizX5A 7WfcgWFTjQPb2gns4LPSSmS3TWaKj7qQ8fCP57mKSbGn2Oqo8CjIWMs7Ao7Pe3Ah bEDyT/y1Pddh6ZFRDQaFR1s8K8= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id 102A359807B; Wed, 17 Oct 2012 11:33:34 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 17 Oct 2012 11:33:34 -0700 Message-ID: In-Reply-To: References: Date: Wed, 17 Oct 2012 11:33:34 -0700 From: "Ryan Sleevi" To: "Carl Wallace" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:33:47 -0000 On Wed, October 17, 2012 11:07 am, Carl Wallace wrote: > I don't doubt any of this, but still think a crawler tool would be > sufficient in many (if not most) cases. It'd probably be instructive = to > run for the site operators in the worst case. Note, I did not suggest > that a user report feature was not a good or necessary thing, only tha= t a > builder tool for the site operator to run without bothering any users > would be nice to have in the toolbox too. Thinking about it, they may > well be the same tool if the user reporting tool is aggressive enough. Ah, I misunderstood your point to be suggesting that a crawler would be sufficient, and reporting would be unnecessary. I'm a big fan of the crawler - both for purposes of pinning and for purposes of generally understanding the nature of the web PKI. Public datasets such as the EFF SSL Observatory data [1], along with private datasets such as those that inform tools such as Qualys' SSL Labs [2] or the Google's Certificate Catalog [3], would go a good deal to establish what the known-possible certificate hierarchies are. I just thing there will be a tail of oddities and legacy that are only picked up by reporting. [1] https://www.eff.org/observatory [2] https://www.ssllabs.com/ [3] http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificat= e-security.html From barryleiba@gmail.com Wed Oct 17 19:25: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 D553A21F85A0; Wed, 17 Oct 2012 19:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ-zbS5vzQt9; Wed, 17 Oct 2012 19:25:17 -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 F264C21F858F; Wed, 17 Oct 2012 19:25:16 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9059434vbb.31 for ; Wed, 17 Oct 2012 19:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=wDQUSB9tpDe14FGwx645Vg/vnew7n8nYqFeGQB6O4aE=; b=rzY++5GMc6OqwX7RSVaS0nPa7hZGiYaEfPteBu1izozhiDV8oX3vMDA/cUhjP4/ofb fDLLB3IIn0+mmvfVB6kQgp6IMPufbLHBhLS73XaHs+GOZdn7WkPXNo22dSH8WebcPRGi ypyZ7prrfaAYqaXfcIo4rCIkOZg93lHz+8rZIKqAtd2do3Sgkw+1a25gYF7efyX8XOuJ /WcOeYevY30MH5+sQPxvViYnWkNx/EbGs/06Gr4KkcKWIVJIXUiuBfQu7tjuTAYK8BGw YOhluEo8kV7W3AbBWqjV0K9UzTEFiH93lPknyQSozjviJ3vEluNu6InCEh3kSfhi8oFh DgJg== MIME-Version: 1.0 Received: by 10.220.220.5 with SMTP id hw5mr2987796vcb.53.1350527116394; Wed, 17 Oct 2012 19:25:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Wed, 17 Oct 2012 19:25:16 -0700 (PDT) Date: Wed, 17 Oct 2012 22:25:16 -0400 X-Google-Sender-Auth: FotLzZ0QiWKnuBHTBtR-wzeeV4Y Message-ID: From: Barry Leiba To: http-state@ietf.org, websec@ietf.org, ietf-http-wg@w3.org, apps-discuss@ietf.org, oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: saag@ietf.org List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 02:25:18 -0000 A document titled "Secure Cookie Sessions for HTTP" has been submitted to the Independent Stream Editor (ISE): http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ The IESG has been asked to review the document, as specified in RFC 5742, Section 3. The Security and Applications Area Directors are looking for input for that review. Please post any relevant comments to the Security Area list, , as soon as possible, and at least by 1 November 2012. Note: Please do NOT post responses to any of these mailing lists. Respond only to (using the subject line of this message). Please read RFC 5742, Section 3, and be aware that we are not looking for detailed comments on the document itself (see below). We specifically need input on whether this document is in conflict with work that's being done in the IETF. Look at the five possible responses specified in that section, and help us determine whether any of 2 through 5 applies. Please be specific in your response. In addition to this, we're sure that the authors and the ISE would appreciate comments about the document. If you have those, you may send them directly to the authors at and to the ISE at . General discussion of the document on these lists or the saag list will likely not get to the authors or the ISE. Barry Leiba, Applications AD From trac+websec@trac.tools.ietf.org Thu Oct 18 16:57:11 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 AF54B21F8512 for ; Thu, 18 Oct 2012 16:57:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzpVJ-+VAFJG for ; Thu, 18 Oct 2012 16:57:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 20C2021F8232 for ; Thu, 18 Oct 2012 16:57:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:33148 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOzxS-00088v-IG; Fri, 19 Oct 2012 01:56:58 +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: palmer@google.com X-Trac-Project: websec Date: Thu, 18 Oct 2012 23:56:58 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/54 Message-ID: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> X-Trac-Ticket-ID: 54 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org, sleevi@google.com Subject: [websec] #54: Specify a report-only mode 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: Thu, 18 Oct 2012 23:57:11 -0000 #54: Specify a report-only mode Should there be a "report-only" mode, allowing site operators to see how using HPKP would affect their site's operation in browsers supporting HPKP? (Probably.) If so, specify how that mode would work. -- -------------------------+---------------------- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Keywords: -------------------------+---------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Thu Oct 18 16:57: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 6661321F8510 for ; Thu, 18 Oct 2012 16:57:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt3-6ahVELxO for ; Thu, 18 Oct 2012 16:57:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E2F4721F8827 for ; Thu, 18 Oct 2012 16:57:17 -0700 (PDT) Received: from localhost ([127.0.0.1]:33173 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TOzxk-00089b-Is; Fri, 19 Oct 2012 01:57:16 +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: palmer@google.com X-Trac-Project: websec Date: Thu, 18 Oct 2012 23:57:16 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/54#comment:1 Message-ID: <073.9d23915b9223ebdb40cc9bba5aee0d4d@trac.tools.ietf.org> References: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, sleevi@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #54: Specify a report-only mode X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 23:57:18 -0000 #54: Specify a report-only mode Changes (by palmer@…): * status: new => assigned -- -------------------------+----------------------- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Ticket URL: websec From palmer@google.com Thu Oct 18 17:17:59 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 53B7521F84A2 for ; Thu, 18 Oct 2012 17:17:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu5cKL8XYEOb for ; Thu, 18 Oct 2012 17:17:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23B3A21F849F for ; Thu, 18 Oct 2012 17:17:57 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so7073668lbo.31 for ; Thu, 18 Oct 2012 17:17:57 -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 :content-type:content-transfer-encoding:x-system-of-record; bh=PDGffl1F6Zlf4QhVwzqIlL0PJkwwGG7H//6v+8tXVQc=; b=AZRjCj3MzsfaluS1LA2QnilyH2S2MoxHQsDVZPCPjIrgeKq+PGbXKQjEBbrq9gSs+i OTLCGfOqoGpIvhO9hBz44/owgO06/RfKmrH683bANjVLrz8HrpxZfdRtUdhBOkaOzShI Zp0pDHC06D0ZJSkgYJiXomYOjDtT2SfQIU+C8SdKij9DAkUClQzjoufJEzEAuqAa9nHv 0OMLd4418nklOl8wi68kC1UGItc1q7FdwVxu0YYQY9pOMBw8FRemm4O/qxIAZ1jSlstJ UMoLthauih9dKfanaKJIEB/t4IWEDX8F5QV4hSLhONAnOtTZYopXhVJCHOZ6jnrKN6CC 8KAg== 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 :content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=PDGffl1F6Zlf4QhVwzqIlL0PJkwwGG7H//6v+8tXVQc=; b=LJx4HN7zTsUCKMWD+7FRrGM4jUxCHL/M8t6KqaPd/SwosM9B1LWftSwTzjK8sYz7SO hhmBLzQyTgr/foum5L9KqTUyMszL3kjXzyurb13N0TUlypez4GZGR2bkPjr0ITdqZkU7 6I6Z8GwPo/J1pDUB6JlCNPy7Q5lmqoJ9sIYgYw8bx15MbRZ2uTk+IsFTHOoLM6bOb/uc 0arSVAMHjEFtKiRUJvO2TcuhkaYLKpXqrtJI+/ZL9R/JnRCmzQ7WTzs1UkYttVF9wIoV EWKLmd4yxWLI4yU+kCN4tX1cccWPulfegRPiZWtTBsZPPcML4oI0T2ukRXrYxKVq7VPM 8z7w== MIME-Version: 1.0 Received: by 10.112.99.37 with SMTP id en5mr8571947lbb.1.1350605876971; Thu, 18 Oct 2012 17:17:56 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Thu, 18 Oct 2012 17:17:56 -0700 (PDT) In-Reply-To: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> References: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> Date: Thu, 18 Oct 2012 17:17:56 -0700 Message-ID: From: Chris Palmer To: websec@ietf.org, sleevi@google.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkf2EeXPhpS/zJkZgrg+hXDBdchezg5jGvnm7RNEtyMCby+n1TeA/Zn56ZhZde5nQOXxhejxQ2hIg+KIgOyGPhSnzd/DfdeIaarCXqfvXKEbpkHWGC4A6UCH/RgestYgJSv1D4ezv1JbP3OvOS0tLkSteZ8yZggmTeGoxIM5cnASV11AP7x2pNz817ggrIC15MyceZf Subject: Re: [websec] #54: Specify a report-only mode 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, 19 Oct 2012 00:17:59 -0000 On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker wrote: > #54: Specify a report-only mode > > Should there be a "report-only" mode, allowing site operators to see how > using HPKP would affect their site's operation in browsers supporting > HPKP? (Probably.) > > If so, specify how that mode would work. What are people's thoughts on this? The motivation for a report-only mode is twofold: (1) site operators want to see what would happen before going live with pinning; and (2) site operators often don't know all their keys, or all their intermediate signers' keys, or all their trust anchors' keys, and a reporting mode could help them find out. (2) implies that the reporting interface would have to allow the UA to tell the site not just "pin validation succeeded/failed", but also why (probably by simply reporting the entire validated certificate chain that the UA computed/observed). The reporting interface must be one that is easy for site operators to implement =E2=80=94 writing code to collect the reports should not be a hug= e burden for developers. Perhaps a simple JSON blob: { "pin-validation-succeeded": (true|false), "expected-pins": [ "sha1/blahblah", "sha256/foobar", ... ], "validated-chain": [ "PEM blob of EE", "PEM blob of intermediate", ..., "PEM blob of anchor" ] } The next issue is, should the site be able to specify a URL to which the UA will POST the JSON blob, or should we specify a single, well-known URL path? Using a well-known path seems simpler and less error-prone generally. From palmer@google.com Thu Oct 18 17:27:29 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 520C921F84C9 for ; Thu, 18 Oct 2012 17:27:29 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxnZF9gUfsEg for ; Thu, 18 Oct 2012 17:27:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88DD121F84BD for ; Thu, 18 Oct 2012 17:27:28 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so423lbo.31 for ; Thu, 18 Oct 2012 17:27:27 -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=Nt7eBEDBeqrrhlOihH8D+h7ReTT4Wor3ulotUHG3zJU=; b=G9dFUnVEOSjSzaFdneyoF4vFAssMn1xvg5O7dT3k0d0PnwV7MK7/mHOH+eJW/iDGG0 mus58KjHOu2jr+9tiewOkvk/b195f2gyryMa9mLW4GCOmeeWUEVnueQ6fqEbnwhpYekS 4UPdL68hglQR8x0TNqRVU5Fv0iGLz0pM1bN30YT9p396stA2LoQXWE0LMg21pC8DPvG1 Eu97dexJRs+QNdObGmSZiw1guw9v8SYzrzrpbac+swbsilV/3bcBkloGFbGvmEkUUQ6K y+SMMgz+NOf5dgo/y2h1drWaeKrcuY67v0AuIvHWQKBSgfMMcNA6Tujm7tN63cdkFnaa zz/w== 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=Nt7eBEDBeqrrhlOihH8D+h7ReTT4Wor3ulotUHG3zJU=; b=Gmrzn2+zqCDfy7dsqU3FeV3dIEW4yxC0UfcqIj6uFsUKGP5E286f++WLm9AEkG+evU cOO0GwoCkD8dRSJG6fsd78pCT99QkjWNRwBdkFFW4fLqnpyvDhxk+tVuVP7ZaGQ/xtJ1 JACuiLl2IJICdC+FEarQKi/F9QqbB/qQ+z6GBBYZxOQXOSHWRLir3mXOFVhI9eaD/cHm f4UGwY3gzE27TLVkceoW4bQR9CGCtumwMSNEq9PEfqbKRS67EKDryUWowaO1GAUyH/s0 +caFMm/Fmw8WVEhW9FuOfvL4/RfxzkUEaflmE/+/yPCD8ntuQpn1IdFnzxKMvWvXE3LA QrMg== MIME-Version: 1.0 Received: by 10.152.146.101 with SMTP id tb5mr16225904lab.44.1350606447501; Thu, 18 Oct 2012 17:27:27 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Thu, 18 Oct 2012 17:27:27 -0700 (PDT) In-Reply-To: <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> Date: Thu, 18 Oct 2012 17:27:27 -0700 Message-ID: From: Chris Palmer To: Yoav Nir Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlnd5sPWMmQWnNzcVcueE/WY/b9iD3FNFOnFe/4rqbjvxhJn7xT4RE5/OVZjTEreU2lVkUIMxQ6g8D4/YJbZkpfxYEkRGCi6xO/7Zn0a9BOkKDIDTMN63pr0/gXr1/747ZK/zrXq+FuY4Oub+GrsKEYyG2+0Cb0bxgi3r62/D2joLZ/Jp/FeTMibCTzDW31BEC9fznw Cc: IETF WebSec WG , Ryan Sleevi Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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, 19 Oct 2012 00:27:29 -0000 On Tue, Oct 16, 2012 at 1:16 PM, Yoav Nir wrote: > Good to see this. Do you intend to publish another revision by the draft submission cutoff date next Monday? It's quite possible, but I can't guarantee it right now. > Or would you like us to discuss these issues to resolve at the meeting in Atlanta? Ryan will be at Atlanta, and I won't be. I think it's easier for me if we continue to discuss things here on the mailing list. From ryan-ietfhasmat@sleevi.com Thu Oct 18 17:40: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 4C66B21F8477 for ; Thu, 18 Oct 2012 17:40:43 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-SI0s0KR4ab for ; Thu, 18 Oct 2012 17:40:42 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3F221F8475 for ; Thu, 18 Oct 2012 17:40:42 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2D69350806E; Thu, 18 Oct 2012 17:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=bRwXXQiVnis5mhldDe8jPGcvyio=; b=QWKfU2/iuTGCqUl/6 yFWoiHB3kasYHNj4yfL2hSRWvVHUdFcqmaeHidipiSvLPPf2NeNjLRzftlMtvKqo KJf18lj5bCozxcwn3RuW7VgKCzagSzotlxfOdQ0bo1Hayb8hvOQ/y8iIL0vcDGA0 Mr82cHY6Mc1RIAqIviLjbFtvOs= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id DBB9A508069; Thu, 18 Oct 2012 17:40:41 -0700 (PDT) Received: from 216.239.45.4 (proxying for 216.239.45.4) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 18 Oct 2012 17:40:42 -0700 Message-ID: <2f70ca2ca41763af074a4abbe7bddd18.squirrel@webmail.dreamhost.com> In-Reply-To: References: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> Date: Thu, 18 Oct 2012 17:40:42 -0700 From: "Ryan Sleevi" To: "Chris Palmer" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #54: Specify a report-only mode X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 00:40:43 -0000 On Thu, October 18, 2012 5:17 pm, Chris Palmer wrote: > On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker > wrote: > > > #54: Specify a report-only mode > > > > Should there be a "report-only" mode, allowing site operators to see > > how > > using HPKP would affect their site's operation in browsers supportin= g > > HPKP? (Probably.) > > > > If so, specify how that mode would work. > > What are people's thoughts on this? The motivation for a report-only > mode is twofold: (1) site operators want to see what would happen > before going live with pinning; and (2) site operators often don't > know all their keys, or all their intermediate signers' keys, or all > their trust anchors' keys, and a reporting mode could help them find > out. > > (2) implies that the reporting interface would have to allow the UA to > tell the site not just "pin validation succeeded/failed", but also why > (probably by simply reporting the entire validated certificate chain > that the UA computed/observed). > > The reporting interface must be one that is easy for site operators to > implement =E2=80=94 writing code to collect the reports should not be = a huge > burden for developers. Perhaps a simple JSON blob: > > { > "pin-validation-succeeded": (true|false), > "expected-pins": [ "sha1/blahblah", "sha256/foobar", ... ], > "validated-chain": [ "PEM blob of EE", "PEM blob of intermediate", > ..., "PEM blob of anchor" ] > } > > The next issue is, should the site be able to specify a URL to which > the UA will POST the JSON blob, or should we specify a single, > well-known URL path? Using a well-known path seems simpler and less > error-prone generally. To wit, this was also brought up by several people during the IETF 84 presentation. As an example of how such behaviour might be specified, a similar report-only mode is implemented with Content Security Policy [1]. In CSP, both the "Content-Security-Policy" and the "Content-Security-Policy-Report-Only" headers may be present, both are considered, and both may contain independent/conflicting policies. In CSP, one of the token/directives is "report-uri", which indicates the URI to use to send violation reports to, as well as a defined format for what the contents of the report should contain. The distinction here between PKP and CSP is that CSP is evaluated per-resource load within a web origin, whereas PKP is enforced at the transport layer. A PKP violation is nominally detected during the TLS handshake, and depending on client implementation, may either be treated as an error during the TLS handshake or immediately following it, prior t= o using the connection to transmit the (original) HTTPS request. If a report-only mode is supported, the following considerations should b= e worked out: - Should the origin of the report URI be constrained the the origin of the target URI? - Should the report URI be allowed to specify HTTPS? - If the report URI specifies HTTPS, and the report URI origin is the same as the target URI, but the report URI violates either the PKP or PKP-Report-Only policy, should the report still be submitted? - Is there a blacklist or whitelist of headers that should be used to prevent against abuse or compromise. For example, presumably including cookies in the report submission for an invalid PKP over the same connection that generated the invalid PKP would be bad, as it may (will) lead to the compromise of the users' data. - If the report contains validated certificates, what should the format be? draft-josepfsson-pkix-textual [3] may be of normative use here. [1] http://www.w3.org/TR/CSP/#content-security-policy-report-only-header-fiel= d , with the expired, less-comprehensive draft submitted to IETF at http://tools.ietf.org/html/draft-gondrom-websec-csp-header-00#section-4.2 [2] http://www.w3.org/TR/CSP/#report-uri [3] http://tools.ietf.org/html/draft-josefsson-pkix-textual From palmer@google.com Thu Oct 18 18:15: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 71E1121F852C for ; Thu, 18 Oct 2012 18:15:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1SC-hNXPI2l for ; Thu, 18 Oct 2012 18:15:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC3421F84FE for ; Thu, 18 Oct 2012 18:15:35 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so20547lbo.31 for ; Thu, 18 Oct 2012 18:15:34 -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=e7RheKouxK3UaRxz2OOeJtvfp0CHz35/HBdRAEGkZxI=; b=kxEI8TGzcCJ4lc0rwPJCVJcMjgoZMRzFnBO4o0NHvLrqpwLdLxxYlZfHjcXmiKKde8 /vgRG6rusOybyedFG6jvHNpeS5wqIKA2D5cg1vzU2qnhdCGv1K5MD8ke+gn69bNVjgUZ fqu7/vRf3SqepdNnJZz7FQqpIN6Yq8yL3TqV0wJvfG7zPIutC+LXjyyoYzgyKk1a2fvB egOnr9Pm7MGd6U4mVyu1cafVc3Kts1z6IJsvKkR+06Mo10BXtRLfQBbiIjY5oQj0S7dV bwBBg3R6gRbBm49GpUS5dw12SUe7oP+cr9WIH15Pd4kw1PeJAwjMFDXy3b+9VkblImqC Iv5Q== 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=e7RheKouxK3UaRxz2OOeJtvfp0CHz35/HBdRAEGkZxI=; b=IX2enKOnNsSMKVNmxSxDGQS9UMQvaIqZV8hsDUfDyK1g3bVsO3kjOU4AlKL3AwFqtg ONMHfa0MAAI2yuxLRGL0LFhMaZellz6+5TBEfqUqlTUG2L6uY5eAhjiCjoJTLTLnss+B 5ZRcXT0S/sC0JntOFVlxjYhUs9G+H2HHzud/jcgGTh+GFy76pird/1ggWaOzGjYIj4+6 yDisBhMjKnepMzftNCbD+aXNtU+js2O7Up1bCVkP8Fs+rWJQEMNWBBoHf0yXP8ZPWOM4 2v6QZvKBm5h1fqw2Ndz1SZmbyo/XR1fxNw0syT7lBmyw1BJMnQ7FVUcuEftDIB2typqF koXg== MIME-Version: 1.0 Received: by 10.152.122.11 with SMTP id lo11mr20158193lab.3.1350609334683; Thu, 18 Oct 2012 18:15:34 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Thu, 18 Oct 2012 18:15:34 -0700 (PDT) In-Reply-To: References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> Date: Thu, 18 Oct 2012 18:15:34 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn/xs46gxdnyaOLk8wIfIacja0d55IViNT52Y2Zd2Gv/qXzDBGFye+l0XtCcAtkSaGEoQz1TFBgE+LxHwx5XGgTdAkdYtxA6OHDT3rcOkQS8bqIflU7VEMqZGIi4Jo3jEsOrm1nc5JcpSxbcpMNWxNA37ziSfYlt0FZ7mmLIPyHelw603lC3QbKSi7tVeLN7eMAR35P Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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, 19 Oct 2012 01:15:37 -0000 On Wed, Oct 17, 2012 at 7:23 AM, Tom Ritter wrote: > Section 2.3 "Noting Pins": > > I wonder if it is worth moving "The UAs MUST ignore Public-Key-Pins > response header fields received on HTTP (non-HTTPS) connections." > outside the criteria to be unambiguous that a client should not > "discard any previously set Pinning Metadata" if it receives the > header over HTTP. Or if it's reasonable enough to assume no one would > get confused. I think it's reasonable enough. However I did add this: """The UA MUST note the pins if and only if it received the Public-Key-Pins response header field over an error-free TLS connection. The UAs MUST ignore Public-Key-Pins response header fields received on HTTP (non-HTTPS) connections and on HTTPS connections that are not error-free.""" to (hopefully) resolve this: > Similarly, I wonder if there was some situation that could result in > an attacker-induced 'errored' TLS connection that still sent the > header, resulting in the data being discarded... Thoughts? > Section 2.4: "Validating Pinned Connections": > > For the purposes of Pin Validation, the UA MUST ignore > certificates who SPKI cannot be taken in isolation and superfluous > certificates in the chain that do not form part of the validating > chain. > > I know I just modified this, but the second phrase just hit me. > Because path construction is non-standard, could a client wind up in a > situation where the site pinned to CA_Alice, with the intended path > CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was > trusted, the ultimate validating chain was simply CA_Bob -> > Intermediate -> Leaf? I'm not sure what the right way to counteract > that would be... Yes, Ryan raised this hilarious point to me a while back, and now I see he has responded to your question here on the list. So, it's a strong motivating factor for a report-only mode. I've created an issue tracker entry and a discussion thread for that. > 2.5: "Pin Validity Times" > > I find the "current + current - initial" / "(b) the amount of time the > pin has been noted" item confusing, and am not sure what it means from > reading only the draft. If I'm not the only one, it might be worth > clarifying. Yes, even after a lot of thought I am still undecided about this. I see several possible approaches: (a) simply have the validity time be the same as for HSTS; (b) the same as HSTS but with a 30-day maximum; (c) the current attempt to mirror TACK, except clarified and with examples; or (d) something else. Of these, I think I currently like (b) best. Thoughts? > 2.6. "Interactions With Preloaded Pin Lists" > > If closing private browsing mode or clearing saved data also clears > preloaded pins (and I think it should), I think you mean "clears dynamic pins"? In Chromium's Incognito, any accrued dynamic pins will be lost when you close your last Incognito window. (If not, that is a bug and you can assign it to palmer@chromium.org.) Also, in Chromium, when you clear browsing history, chrome://chrome/settings/clearBrowserData, *and you select "from the beginning of time"* (or presumably any time that predates when your HSTS data is from), your HSTS metadata (e.g. ~/.config/chromium/Default/TransportSecurity) is indeed wiped clean. That was true last time I checked, on 7 May 2012. Again, if you find otherwise, assign me a bug. > this would cause a revert to > the preloaded pins, which may break sites. A workaround may be to > disable a preloaded pin if a new pin is seen, and keep that disabled > even after the saved data wipe/private browsing mode close. Good point. I'll add a note to that effect and ship it in the next draft. > To prevent using this as a backdoor into tracking, I don't consider the implicit tracking cookie problem to be solvable. I think EFF's Panopticlick conclusively shows that it cannot be solved. Tracking with HSTS and HPKP metadata would be a notably noisy and inefficient way to implicitly track people; much "better" methods exist now and always will. See http://www.w3.org/TR/hr-time/ just as a random example... > the preloaded pins > should be sanity checked for "Is this organization likely to abuse the > feature." I suppose we could press the Safe Browsing list into service for this (and data and API for that are open), but it's a stretch. SB is about malware and phishing, which is a different thing than implicit tracking. It could at best be a "UAs MAY choose to ignore HSTS and pinning metadata for certain sites... a mechanism to do so is beyond the scope of this I-D..." thing. > Again, excited about this - thanks for the work. Thank you for all your help! From tobias.gondrom@gondrom.org Fri Oct 19 00:52: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 B84D721F845E for ; Fri, 19 Oct 2012 00:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=0.000, 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, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr0Qcnion13v for ; Fri, 19 Oct 2012 00:52: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 7111E21F8432 for ; Fri, 19 Oct 2012 00:52:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=pZO6otZ+Xjzq6lJM1XuCDYBUz3ayHVjaoJ8G5mZVDIzqAMrUzwKj4PBK4xgi+Ur39mXJWjVnMH2AzWe600J/Tgjb81p5rRPMdITI7v2weSNP3OjtXNAfAwq/kucro8Ql; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 16056 invoked from network); 19 Oct 2012 09:52:05 +0200 Received: from 188-223-113-88.zone14.bethere.co.uk (HELO ?192.168.1.65?) (188.223.113.88) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Oct 2012 09:52:05 +0200 Message-ID: <508106A5.5020704@gondrom.org> Date: Fri, 19 Oct 2012 08:52:05 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: palmer@google.com References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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, 19 Oct 2012 07:52:18 -0000 On 19/10/12 01:27, Chris Palmer wrote: > On Tue, Oct 16, 2012 at 1:16 PM, Yoav Nir wrote: > >> Good to see this. Do you intend to publish another revision by the draft submission cutoff date next Monday? > It's quite possible, but I can't guarantee it right now. > >> Or would you like us to discuss these issues to resolve at the meeting in Atlanta? > Ryan will be at Atlanta, and I won't be. I think it's easier for me if > we continue to discuss things here on the mailing list. Hi Chris, yes, please. Discussion on the mailing-list is the right place. In addition, we will be looking forward to a presentation and discussion on the open issues from Ryan on your behalf during our websec meeting in Atlanta. Best regards, Tobias From tom@ritter.vg Fri Oct 19 07:29: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 9D7E221F8699 for ; Fri, 19 Oct 2012 07:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtEJXCfLDkyq for ; Fri, 19 Oct 2012 07:29:52 -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 78DEA21F869E for ; Fri, 19 Oct 2012 07:29:52 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so636499vbb.31 for ; Fri, 19 Oct 2012 07:29:52 -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=xxBBiXVe+oR3BytNmNWhUaDfgAkB6scADaKHw/G5Z48=; b=Ua6nMJgEPNaRw7Nz0pCtgfgKli4X9AYMmGhMkpwJq8CQH1EVGC3GSnrXzJDK7zFBOY 7cwZMtbMMjWY7RymVorJqbrxXnXsAr5S0lm59y4B3bZoIHsIowgZ/nYIu/mt5AFCT/wm yREK3ZBDTSH5NX+IAlGQ+gycREF/Kp6hhEDAE= 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=xxBBiXVe+oR3BytNmNWhUaDfgAkB6scADaKHw/G5Z48=; b=aPg7pFk+iVwi79XUvBQN/uw7LjotoytXDbZ/IMhScIwbrQbD60Iwlx/Q883YjLjajB LUoIHLRjKDun209bcnO998xjXB6wQgyAWObTAAOLD7InfI8Rql8Dx9I6U07weAkpC5ZD sMbsi4YuhO6RznMnLCsa7TE7NLnAwwszRZNQTbqH8xR15LgpB+omxuYX0lwZ/7cowhfI gtTACHDjwjT32Sle4oRZYBXccX7g/zb1+Pal8Q/23pxvk7lb+VCS1q39jC/5bxBkNycy jL2l3dn06KLje5YnE2yu+M2E45poQwVtU5WuYewvJyKRvmJp9986AT1UeegxhqNCQw1F qtWQ== Received: by 10.52.34.168 with SMTP id a8mr1448684vdj.49.1350656991814; Fri, 19 Oct 2012 07:29:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Fri, 19 Oct 2012 07:29:31 -0700 (PDT) In-Reply-To: References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> From: Tom Ritter Date: Fri, 19 Oct 2012 10:29:31 -0400 Message-ID: To: Chris Palmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkmWcTiEukT8s6J24Gl0EbRrPX41yoFs2/C/40HcLqeRXEkeI64EK6skWXvLyhX4QuhijMc Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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, 19 Oct 2012 14:29:53 -0000 On 18 October 2012 21:15, Chris Palmer wrote: > I think it's reasonable enough. However I did add this: > > """The UA MUST note the pins if and only if it received the > Public-Key-Pins response header field over an error-free TLS > connection. The UAs MUST ignore Public-Key-Pins response header fields > received on HTTP (non-HTTPS) connections and on HTTPS connections that > are not error-free.""" > > to (hopefully) resolve this: > >> Similarly, I wonder if there was some situation that could result in >> an attacker-induced 'errored' TLS connection that still sent the >> header, resulting in the data being discarded... > > Thoughts? Sorry, but I think that introduces more confusion. Point 1 includes a criteria and a "Do Something if not Criteria" but the following paragraph after the Criteria also includes a "Do Something if not Criteria". I would suggest moving the "do something" out of the first criteria. I would suggest the following, which moves the 'do something' out of criteria 1, clarifies that the discarding action only applies to currently Pinned Hosts, and states explictly that when we say "error-free TLS" this includes the validation in Section 2.4 if applicable. >>>> The UA MUST observe these conditions when noting a host: o The UA MUST note the pins if and only if it received the Public-Key-Pins response header field over an error-free TLS connection. If the host is a Pinned Host, this includes the validation added in Section 2.4 o The UA MUST note the pins if and only if the TLS connection was authenticated with a certificate chain containing at least one of the SPKI structures indicated by at least one of the given fingerprints. (See Section 2.4.) o The UA MUST note the pins if and only if the given set of pins contains at least one pin that does NOT refer to an SPKI in the certificate chain. (That is, the host must set a Backup Pin; see Section 3.1.) If the Public-Key-Pins response header field does not meet all three of these criteria, the UA MUST NOT note the host as a Pinned Host. A Public-Key-Pins response header field that meets all these critera is known as a Valid Pinning Header. The UAs MUST ignore Public-Key-Pins response header fields received on connections that do not meet the first criteria. If the UA recives a Public-Key-Pins header from a Pinned Host that meets the first criteria, but not the following two, the UA MUST discard any previously set Pinning Metadata for that host in its non-volatile store. <<<< >> 2.5: "Pin Validity Times" >> >> I find the "current + current - initial" / "(b) the amount of time the >> pin has been noted" item confusing, and am not sure what it means from >> reading only the draft. If I'm not the only one, it might be worth >> clarifying. > > Yes, even after a lot of thought I am still undecided about this. I > see several possible approaches: > > (a) simply have the validity time be the same as for HSTS; > (b) the same as HSTS but with a 30-day maximum; > (c) the current attempt to mirror TACK, except clarified and with examples; or > (d) something else. > > Of these, I think I currently like (b) best. Thoughts? I think A. I believe (without evidence) there are institutions that would eventually like to use this that have customers that work with them on a quarterly or annual basis. Likewise, I believe (without evidence) that a institution who was risk adverse would mitigate that risk by pinning to several large CA roots, not by saying "Oh well our customers can't access us for the next 30 days, but it's only 30 days who cares - but 60, that would be unacceptable!" I do like TACK's notion of 'growing' out pins but only in a "That sounds like a feature we're anticipating people wanting" way. If people actually hold off on deploying this because of that and that alone, it SHOULD be possible to add a new directive, ignored by older browsers who don't implement it. Public-Key-Pins: max-age=600; grow-to=86400; pin-sha1="4n972HfV354KP560yw4uqe/baXc="; The spec should probably note that directives not understood should be ignored, and not invalidate the header, to allow for future expansion. Right? > I think you mean "clears dynamic pins"? Yes, dynamic pins. > I don't consider the implicit tracking cookie problem to be solvable. > I think EFF's Panopticlick conclusively shows that it cannot be > solved. > ... > I suppose we could press the Safe Browsing list into service for this > (and data and API for that are open), but it's a stretch. SB is about > malware and phishing, which is a different thing than implicit > tracking. I was actually saying "Chrome shouldn't ship preloaded pins for Marketing Firms, because if a MF sends Pins to a user in Incognito Mode, then the user closes Incognito Mode - MF can learn that a user is a repeat visitor even though they visited in Incognito Mode." But AFAICT that would be all the information a Marketing Firm would be able to learn - binary visited or not. BUT: Even if UAs did not ship pins for Marketing Firms, it wouldn't matter because an attacker could use Cross Origin Img Loads with a stolen certificate to learn the same amount of information (whether a user visited in Incognito mode) about a valid, non-marketing site (e.g. Abuse Counseling site). > It could at best be a "UAs MAY choose to ignore HSTS and pinning > metadata for certain sites... a mechanism to do so is beyond the scope > of this I-D..." thing. I recant, I don't think this is necessary, because the above is not solvable in the technical constraints and Incognito Mode clears pins. -tom From tom@ritter.vg Fri Oct 19 08:57: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 ACD9921F8764 for ; Fri, 19 Oct 2012 08:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcl1GguBJ9Vv for ; Fri, 19 Oct 2012 08:57:16 -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 AC89B21F845E for ; Fri, 19 Oct 2012 08:57:16 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so759387vbb.31 for ; Fri, 19 Oct 2012 08:57:16 -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=ud0Gz/ZAsh9LZvHBwvgz3rtq3UlCFuu+LvxPI+DXY+M=; b=GW36jQrmQlaLHTReRuaTu2Qb4IoAkOEt4eTCBjVkIL80u4FkHv9WrCHRMEVnlBNeST 2JGpXFVyccYFNRaWv2B63h9MZdprs1ycuSH8gFa5l7ug4Goy2mmJR1HfWZaEnGs34zEP 94pc3enLHGG/X6/qRrBLcPcTSU65gFHKNFNhI= 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=ud0Gz/ZAsh9LZvHBwvgz3rtq3UlCFuu+LvxPI+DXY+M=; b=gBb6zqj+br6T0aQDAi+3zMBQEeRv6xC/A2pszZxBig2JdPnK47RYwd4ba+/Yrp/e0s tkydbYkZXkjTNDgVlYAsyYdG8BhlfBl0dYA9iZ4z+P9FW6NdFCHAqxbwyUzeYsvxrQKG i+yj2/2cTHCYl3/YZjCawIBjJrBa/cIbvpDibJPGb9IWw2OiKZ7LpSDGekLHa36r1RAM NtHa8LjkXWZ61xNRurYLdxkDdduUaqvGnJ4Mb8F5OMHGoo9JOu+X04bYDNdUouhJF2zR ebl5mov6eS7nfM5wwtlVbBrND5koj4LCp+gsWsoJH3ZzuR+4TRMnTy41wtLDgP6PU0nH bLJw== Received: by 10.58.0.83 with SMTP id 19mr2207086vec.53.1350662236151; Fri, 19 Oct 2012 08:57:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Fri, 19 Oct 2012 08:56:55 -0700 (PDT) In-Reply-To: <2f70ca2ca41763af074a4abbe7bddd18.squirrel@webmail.dreamhost.com> References: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> <2f70ca2ca41763af074a4abbe7bddd18.squirrel@webmail.dreamhost.com> From: Tom Ritter Date: Fri, 19 Oct 2012 11:56:55 -0400 Message-ID: To: ryan-ietfhasmat@sleevi.com, Chris Palmer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnB5Ok4IfJoK+rDUMxx8tTb+TxaZHhr5hbOzXyXx2PFS8awFazu+C7J1mbSQpsMriYy5wbV Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #54: Specify a report-only mode X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.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, 19 Oct 2012 15:57:17 -0000 >> On Thu, Oct 18, 2012 at 4:56 PM, websec issue tracker >> What are people's thoughts on this? It hurts me to say so, because it's going to be more work and complication and delay - but I agree a reporting system should be added. >> The reporting interface must be one that is easy for site operators to >> implement =E2=80=94 writing code to collect the reports should not be a= huge >> burden for developers. Perhaps a simple JSON blob: >> >> { >> "pin-validation-succeeded": (true|false), >> "expected-pins": [ "sha1/blahblah", "sha256/foobar", ... ], >> "validated-chain": [ "PEM blob of EE", "PEM blob of intermediate", >> ..., "PEM blob of anchor" ] >> } I like this, although I would include the entire PKP header, the Host header, and request URI. On 18 October 2012 20:40, Ryan Sleevi wrote: > - Should the origin of the report URI be constrained the the origin of > the target URI? No, you should be allowed to specify a third party domain. I could easily see a third party service collecting these reports as a free or paid service. Google Webmaster Tools may even grow into collecting it and CSP violations. > - Should the report URI be allowed to specify HTTPS? Yes. This is potentially sensitive information, and we would like it to be protected in transit. > - If the report URI specifies HTTPS, and the report URI origin is the > same as the target URI, but the report URI violates either the PKP or > PKP-Report-Only policy, should the report still be submitted? Honestly I don't see why not. If it is an attacker, the attacker will know the user rejected the TLS connection, and will have a good idea it was because of pinning. So what's the harm in telling them the additional information. Vs if it is a legit screw-up by the site, they would still like to have the information. > - Is there a blacklist or whitelist of headers that should be used to > prevent against abuse or compromise. For example, presumably including > cookies in the report submission for an invalid PKP over the same > connection that generated the invalid PKP would be bad, as it may > (will) lead to the compromise of the users' data. I don't think any headers other than the PKP, Host, and URL would be needed= . > - If the report contains validated certificates, what should the format > be? draft-josepfsson-pkix-textual [3] may be of normative use here. I have no opinion. -tom From ryan-ietfhasmat@sleevi.com Fri Oct 19 09:10:23 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 07C8A21F85E7 for ; Fri, 19 Oct 2012 09:10:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfjBH2iLnRu0 for ; Fri, 19 Oct 2012 09:10:22 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFCE21F859E for ; Fri, 19 Oct 2012 09:10:22 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id B971C678063; Fri, 19 Oct 2012 09:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=01fbTPN4wtUKf4SL3ggvgT750Wo=; b=UjF8McOYYxT2CdOrk cxy2AfaUtv+c4anPCZxCe+cw3lrkoLtSfsFM3uRQtASf7o96iBSnjcdyfFpNgrei FpaPNBPJtsOR2+QvWENGjbyOr9q+2XQuuMlzZEnq4YkrCbZMsXdjIylRiqcHTOgr 4csu+yR/9jfhWYQhx7AvCgmv4I= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 21FA9678055; Fri, 19 Oct 2012 09:10:21 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 19 Oct 2012 09:10:21 -0700 Message-ID: <821c3fa4d7d01343b978af70cc776ca4.squirrel@webmail.dreamhost.com> In-Reply-To: References: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> <2f70ca2ca41763af074a4abbe7bddd18.squirrel@webmail.dreamhost.com> Date: Fri, 19 Oct 2012 09:10:21 -0700 From: "Ryan Sleevi" To: "Tom Ritter" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #54: Specify a report-only mode X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:10:23 -0000 On Fri, October 19, 2012 8:56 am, Tom Ritter wrote: > > - Should the report URI be allowed to specify HTTPS? > > Yes. This is potentially sensitive information, and we would like it > to be protected in transit. > > > - If the report URI specifies HTTPS, and the report URI origin is t= he > > same as the target URI, but the report URI violates either the PKP or > > PKP-Report-Only policy, should the report still be submitted? > > Honestly I don't see why not. If it is an attacker, the attacker will > know the user rejected the TLS connection, and will have a good idea > it was because of pinning. So what's the harm in telling them the > additional information. Vs if it is a legit screw-up by the site, > they would still like to have the information. > I should have mentioned the other scenario that is closely related, which is that independent of whether the report URI is different than the targe= t URI, what to do when the report URI violates its own PKP/PKP-Report-Only policy. The concern I have here is the disconnect between expectations. If the site operator specifies HTTPS for a Report URI, presumably, they expect exactly what you mentioned - that sensitive information will be protected in transit. If Report URIs fail the (previously stored) PKP policy, should the report still be submitted or not? Does it match site author expectation? A related, but subtle, implementation issue that is expected to arise if HTTPS is allowed is ensuring that reporting loops are not formed. For example, if submitting a report over HTTPS (via POST, presumably), and th= e response data includes a PKP which the current connection violates, and a report URI for the same URI as what was just posted, should the new violation be reported? This can occur when the Report URI is independent of the initial Target URI (so the second report would be unique) and when the Report URI is identical to the Target URI (so the second report is redundant). My reaction to all of this is that, when the PKP header is received following the submission of a report, that the PKP header is ignored. This is just some of the complexity with report URIs that will need to be worked out - although I agree with your responses, and I agree that, even for the complexity brought, it seems like it will be a necessary and useful part of policy configuration. From palmer@google.com Fri Oct 19 13:38: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 1296221F87E2 for ; Fri, 19 Oct 2012 13:38:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7zK-V1qcsfi for ; Fri, 19 Oct 2012 13:38:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA37F21F87DF for ; Fri, 19 Oct 2012 13:38:35 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so686461lbo.31 for ; Fri, 19 Oct 2012 13:38:34 -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=senNXHtjzJo7LySw84oIqLLdhfYlatCr2+OkPO8JcHE=; b=dNTpPBZyWluWh2Vf+p6vN/RwN5Qt05edeJsEEvCv9QLh08GN4cH9qfMrZhTLLF53O2 0HtKqrEcyJf++p4JiB/VhR0Q5bIhYeFRZhACGClSABLndQl+YaZ5YkiyXEpjS0/X+fyA Ylvw9vG7UycqXPkPrQjLZCKZ54HJhdwPdh9e1iP0YT5F0NZsa2HZ9VtmiNQNteH08cf5 mruoyHHkl4SeXMXr1+5hPy1iBw8AxgJ3CasuWFiYTnH5mZq5qDhkD0ZyWGPbNIHPJOqR uWHQMaeB5o0Px6nJTnzPmwIn/bKdbIgU1PrdECybLwHiC+NTLlHYaRtedm3adq7qnLkt w05Q== 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=senNXHtjzJo7LySw84oIqLLdhfYlatCr2+OkPO8JcHE=; b=HYMSx5ZsM+pdYmyqsyaGKGrVK/dimyd967L+1x4gYTVpgHEnB0QLvrY/586hX623os zFzq3CMJV3Z1gRt4l0fIvzxkCf3cpkMrCQXOo8oqNfT5QKg/3BZVVxccDJed/rlCHlGB NFNB6CTEZxftWU6DDQDoLqEdBSoQ1K147T3SEIjhXGxittjpCzYDg++xapisxkM47JPz OTwhKHhrgGIwy5SRLr3nEeK96VAPLZHX8fqH+iyBl/tQwXz8ZgqkE0nMVtwM6oqO1Cko JNwKAuekX6+W8s1vGqdhmy9ocaHZR0+J7Bgr3YC46C1/yIl62nwjjMSoTVyNY3IeEiJl MJRg== MIME-Version: 1.0 Received: by 10.152.105.68 with SMTP id gk4mr2034310lab.48.1350679114618; Fri, 19 Oct 2012 13:38:34 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Fri, 19 Oct 2012 13:38:34 -0700 (PDT) In-Reply-To: References: <20121016183544.18082.34326.idtracker@ietfa.amsl.com> <7F0FC8A6-D30D-4AAD-A420-0796F9703184@checkpoint.com> Date: Fri, 19 Oct 2012 13:38:34 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmXuf4/kTJxXbT2/FkH8DaBxDNhJxn5BA/GHija+ef1CQ0l8KD35J/aXpL32pD1CsrFvq6P/4rgJK8FbvD7dnDDHW56w/BQStE5sZ5aZ2FOyHBE40MswUyW7koztM1EKUsw7ajI4ijB7RP/xZgz8pMLVbnFjiEioEJxmnQR0YAqB8a9cBuJoK49exiOdhsC6iL7D3ko Cc: IETF WebSec WG Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt 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, 19 Oct 2012 20:38:37 -0000 On Fri, Oct 19, 2012 at 7:29 AM, Tom Ritter wrote: >>>>> > The UA MUST observe these conditions when noting a host: > > o The UA MUST note the pins if and only if it received the > Public-Key-Pins response header field over an error-free TLS > connection. If the host is a Pinned Host, this includes the > validation added in Section 2.4 > > o The UA MUST note the pins if and only if the TLS connection was > authenticated with a certificate chain containing at least one of > the SPKI structures indicated by at least one of the given > fingerprints. (See Section 2.4.) > > o The UA MUST note the pins if and only if the given set of pins > contains at least one pin that does NOT refer to an SPKI in the > certificate chain. (That is, the host must set a Backup Pin; see > Section 3.1.) > > If the Public-Key-Pins response header field does not meet all three > of these criteria, the UA MUST NOT note the host as a Pinned Host. > A Public-Key-Pins response header field that meets all these critera is > known as a Valid Pinning Header. > > The UAs MUST ignore Public-Key-Pins response header fields received on > connections that do not meet the first criteria. If the UA recives > a Public-Key-Pins header from a Pinned Host that meets the first > criteria, but not the following two, the UA MUST discard any previously > set Pinning Metadata for that host in its non-volatile store. > <<<< Thanks again, Tom. I've adopted this in my copy. By the way, people can follow my copy here: https://code.google.com/p/key-pinning-draft >> (a) simply have the validity time be the same as for HSTS; >> (b) the same as HSTS but with a 30-day maximum; >> (c) the current attempt to mirror TACK, except clarified and with examples; or >> (d) something else. >> >> Of these, I think I currently like (b) best. Thoughts? > > I think A. I believe (without evidence) there are institutions that > would eventually like to use this that have customers that work with > them on a quarterly or annual basis. Likewise, I believe (without > evidence) that a institution who was risk adverse would mitigate that > risk by pinning to several large CA roots, not by saying "Oh well our > customers can't access us for the next 30 days, but it's only 30 days > who cares - but 60, that would be unacceptable!" Makes sense. Any other votes? > I do like TACK's notion of 'growing' out pins but only in a "That > sounds like a feature we're anticipating people wanting" way. If > people actually hold off on deploying this because of that and that > alone, it SHOULD be possible to add a new directive, ignored by older > browsers who don't implement it. Makes sense. > Public-Key-Pins: max-age=600; grow-to=86400; > pin-sha1="4n972HfV354KP560yw4uqe/baXc="; > > The spec should probably note that directives not understood should be > ignored, and not invalidate the header, to allow for future expansion. > Right? Yes. In fact Chrome's implementation does do that. I thought I had specified it in this I-D, but apparently not. I propose this parapgrah: For forward compatibility, the UA MUST ignore any unrecognized Public-Key-Pins header directives, while still processing those directives it does recognize. specifies the two directives max-age and pins, but future specifications and implementations might use additional directives. at the end of the Noting Pins section. From palmer@google.com Fri Oct 19 14:29: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 1738921F8748 for ; Fri, 19 Oct 2012 14:29:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kek7KqB8JTIy for ; Fri, 19 Oct 2012 14:29:16 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33F21F8721 for ; Fri, 19 Oct 2012 14:29:15 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so658511lam.31 for ; Fri, 19 Oct 2012 14:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=JG2esl4CCtY/x5yVI01zKd2O+B2UdHD//TvOiVPUe5g=; b=MX1ulpQFVfPobV7E7R/Lf907nVQhgPgcAdrrs/T6Wo1/g7lvaC/635ynKDCl3obN/0 3HWEb7KNoie5ziUxZmFSdxPSEA/sgnN/8dNNMfsy7J1gKO5W9fL3/ek4QyxmHldbGji5 ZWUH8inGKcP7RcUNaIwxk+N49aYw1+dSg4CDWVHywx/W/35B47/BuUi80eSkZxk6eHmv S+avDubyuq/7HxW9/YkTMrrZmbEHXUn+3dYjWeDPSa5w5ChI1CaJXpW56OlyszYE6jGc z+gyLMUR+IMSP3dLHui+a3vI7fmffJMZNC+jLJ6gYWANoUlbfHMdm3oiq5doY6y8hOeV uj3g== 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=JG2esl4CCtY/x5yVI01zKd2O+B2UdHD//TvOiVPUe5g=; b=THW6kiQAmVnjQVTeFNM+r2tnCp6wLlOoyAtrsGnINd8kYYspfEFUcjdBKfEb/IM9V2 MnaGcrkwc62JpgEZLAZVZZEYSAZNCFqyqmCs7thwe3H7akkPcv59F0bluDADxXp0wieS dA7RfRHk8a+4JYO2eyX/gFx2MOvoC0euDwjgCZo8z+nt7qlJ+UMpS6FtVIHNsBbp/yyD ME2TIXK0dTeTwgQBlmdUPQUNlBgZUAQ5oXDlcDw6AeH1pgBFGjqavPQL++9KTtg99P2K T7u9IHR37QK1Nuij8jioGnB7BenVDvqo/GnBgFrA7nbc/B8af7i0tgKtJ974m2KxcltO TjHQ== MIME-Version: 1.0 Received: by 10.152.106.110 with SMTP id gt14mr2186318lab.1.1350682154909; Fri, 19 Oct 2012 14:29:14 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Fri, 19 Oct 2012 14:29:14 -0700 (PDT) In-Reply-To: References: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> <2f70ca2ca41763af074a4abbe7bddd18.squirrel@webmail.dreamhost.com> Date: Fri, 19 Oct 2012 14:29:14 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn2BjvBa2MJqCmGLve03ZRXwPZRQEi3fTwjOPuHqeLASixycxO82GazbHk5t1hdzwl1Et3Nvg+9T8nsOM5AEt2hVtE+/WAYOcFJ/KtmBmrpCg6PHb3o5ncPLWlvV0OMXIj+u7MTY24JFOvnTOzB1GUecq/TbhDxB8wiCFjhLDGN4c3qR6pMyd+Ttz6HdLZanWw4ycpL Cc: websec@ietf.org, sleevi@google.com Subject: Re: [websec] #54: Specify a report-only mode X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.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, 19 Oct 2012 21:29:17 -0000 On Fri, Oct 19, 2012 at 8:56 AM, Tom Ritter wrote: > It hurts me to say so, because it's going to be more work and > complication and delay - but I agree a reporting system should be > added. :) >>> { >>> "pin-validation-succeeded": (true|false), >>> "expected-pins": [ "sha1/blahblah", "sha256/foobar", ... ], >>> "validated-chain": [ "PEM blob of EE", "PEM blob of intermediate", >>> ..., "PEM blob of anchor" ] >>> } > > I like this, although I would include the entire PKP header, the Host > header, and request URI. OK. >> - Should the origin of the report URI be constrained the the origin of >> the target URI? > > No, you should be allowed to specify a third party domain. I could > easily see a third party service collecting these reports as a free or > paid service. Google Webmaster Tools may even grow into collecting it > and CSP violations. I think we should follow precedent, i.e. CSP, and allow aribtrary report URIs. This too hurts me to say. :) But consistency with existing specifications and implementations is preferable to inventing a new behavior for a similar feature. >> - Should the report URI be allowed to specify HTTPS? > > Yes. This is potentially sensitive information, and we would like it > to be protected in transit. Agreed. >> - If the report URI specifies HTTPS, and the report URI origin is the >> same as the target URI, but the report URI violates either the PKP or >> PKP-Report-Only policy, should the report still be submitted? > > Honestly I don't see why not. If it is an attacker, the attacker will > know the user rejected the TLS connection, and will have a good idea > it was because of pinning. So what's the harm in telling them the > additional information. Vs if it is a legit screw-up by the site, > they would still like to have the information. Agreed. >> - Is there a blacklist or whitelist of headers that should be used to >> prevent against abuse or compromise. For example, presumably including >> cookies in the report submission for an invalid PKP over the same >> connection that generated the invalid PKP would be bad, as it may >> (will) lead to the compromise of the users' data. > > I don't think any headers other than the PKP, Host, and URL would be needed. So, whitelist. That is good. >> - If the report contains validated certificates, what should the format >> be? draft-josepfsson-pkix-textual [3] may be of normative use here. > > I have no opinion. draft-josepfsson-pkix-textual works fine for me. From trac+websec@trac.tools.ietf.org Fri Oct 19 14:33:03 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 305ED21F8780 for ; Fri, 19 Oct 2012 14:33:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILy3j7LDLvZ9 for ; Fri, 19 Oct 2012 14:33:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 96C2421F8757 for ; Fri, 19 Oct 2012 14:33:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:38304 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKBg-0003il-MU; Fri, 19 Oct 2012 23:33:00 +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: palmer@google.com X-Trac-Project: websec Date: Fri, 19 Oct 2012 21:33:00 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/55 Message-ID: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: [websec] #55: Clarify that the newest pinning information takes precedence 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: Fri, 19 Oct 2012 21:33:03 -0000 #55: Clarify that the newest pinning information takes precedence In section "Interactions With Preloaded Pin Lists", we need to specify that the newest information, even "stop pinning", must take precedence. I propose this text: UAs MUST use the newest information — built-in or set via Valid Pinning Header — when performing Pin Validation for the host. If the result of noting a Valid Pinning Header is to disable pinning for the host (such as because the host set a max-age directive with a value of 0), UAs MUST allow this new nformation to override any built-in pins. That is, a host must be able to un-pin itself even from built-in pins. -- -------------------------+---------------------- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: new Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Keywords: -------------------------+---------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Fri Oct 19 14:33:11 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 0AC9B21F8757 for ; Fri, 19 Oct 2012 14:33:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmFKA2cKnYeG for ; Fri, 19 Oct 2012 14:33:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC3121F883A for ; Fri, 19 Oct 2012 14:33:10 -0700 (PDT) Received: from localhost ([127.0.0.1]:38336 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKBp-0006M3-5k; Fri, 19 Oct 2012 23:33:09 +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: palmer@google.com X-Trac-Project: websec Date: Fri, 19 Oct 2012 21:33:09 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/55#comment:1 Message-ID: <073.15e9c306cba99e702849c3e01003b3a2@trac.tools.ietf.org> References: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: palmer@google.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: websec@ietf.org Subject: Re: [websec] #55: Clarify that the newest pinning information takes precedence 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: Fri, 19 Oct 2012 21:33:11 -0000 #55: Clarify that the newest pinning information takes precedence Changes (by palmer@…): * status: new => assigned -- -------------------------+----------------------- Reporter: palmer@… | Owner: palmer@… Type: defect | Status: assigned Priority: major | Milestone: Component: key-pinning | Version: Severity: - | Resolution: Keywords: | -------------------------+----------------------- Ticket URL: websec From palmer@google.com Fri Oct 19 14:47:51 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 72C2A21F87DD for ; Fri, 19 Oct 2012 14:47:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEzsSUT5b2yH for ; Fri, 19 Oct 2012 14:47:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5121F894B for ; Fri, 19 Oct 2012 14:47:50 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so717041lbo.31 for ; Fri, 19 Oct 2012 14:47:49 -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 :content-type:content-transfer-encoding:x-system-of-record; bh=tO8iWNBQXLNqde7PvG5TJfzVNydPjEJteXlXuN1hUb8=; b=WxNdYyIce9YIpSSj9CxvItyaKySySqb4pfBZcl3uaLXb/W7drFwGS1s8JUVgOhFvQd 9Sx1EZcnZlsii77iimRe/xSHnI8/ljY2xUs1lodblHfyV3g/0WIly4Qyjwf0LrsQOLqi t5QJfjeCN6VXgPcMZaSU6wmyM1qJnx+ZhNObSmD2tUlV+Ko5T4P1Kv2gwqLaotaweWt+ +++DIupJhp7c/ixe4hl7JwyrS4L6mu7xLdHA66TnxKk81Bv7tdhnUwIWN3vUEuZBiGOm fuAMBFFQjQfbW/uSW5W4haXVoSyRdgo12+XmwllJ/DkbW1byekYQMgIE4Ihs9YGtf6SR F6Og== 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 :content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=tO8iWNBQXLNqde7PvG5TJfzVNydPjEJteXlXuN1hUb8=; b=dIn74rP84zmGuyVWAmDD7yknEWpfOSg9BF4mT22zZk2wIWR63K7tgE0+BlOnzlf0Ze Q5iIk58dci5n8UWx8ofatWyyL5vLPpuAXh64eHZzpJP+OTqfqDHaJ5YpkfSVvGyV4h32 OzKa8xYfbev3emwj/KjZPFeKYOeezPEdVL3YJ1dHuDeTUTw+7HhsNeNU+oo5OnwnuaEI e2e8YJqe0O4lIrtr1kz5JUXjhvyiJarZjQNsc78lvnUgItxa+bjUMmdH5IiiKBc9RB4M bBmhrh6qaQBPIVrQaV/Asxir1YtzQibBSKfbSjIbkmVpoywYAir2tVIsMY0su5Ov7coZ 682Q== MIME-Version: 1.0 Received: by 10.152.110.74 with SMTP id hy10mr2184650lab.54.1350683269476; Fri, 19 Oct 2012 14:47:49 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Fri, 19 Oct 2012 14:47:49 -0700 (PDT) In-Reply-To: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> References: <058.106749b7ec8d8775c9a7c03ff71b6de4@trac.tools.ietf.org> Date: Fri, 19 Oct 2012 14:47:49 -0700 Message-ID: From: Chris Palmer To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnlg1oCb3rkoYoP6k63+j+Ym3U9WLbsOTQmF6iuFVBoJJZj3/N4wvUOs6mNqE5ZVGzMNrCFGblUr8on0UoWiLa+anqWUbb0e3elLuzaJjBqJUmqe5PKY17dF1Ll2cwHbrsPljGn8uPOGOSXRkVfTAN/rSF21i/m2BGmvvLy6DUGvYhy+XAO+D8lTfcD9l2FsxE4AEOU Subject: Re: [websec] #55: Clarify that the newest pinning information takes precedence 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, 19 Oct 2012 21:47:51 -0000 Any thoughts on this text? On Fri, Oct 19, 2012 at 2:33 PM, websec issue tracker wrote: > #55: Clarify that the newest pinning information takes precedence > > In section "Interactions With Preloaded Pin Lists", we need to specify > that the newest information, even "stop pinning", must take precedence. = I > propose this text: > > UAs MUST use the newest information =E2=80=94 built-in or set via Valid = Pinning > Header =E2=80=94 when performing Pin Validation for the host. If the res= ult of > noting a Valid Pinning Header is to disable pinning for the host (such a= s > because the host set a max-age directive with a value of 0), UAs MUST > allow this new nformation to override any built-in pins. That is, a hos= t > must be able to un-pin itself even from built-in pins. From internet-drafts@ietf.org Mon Oct 22 15:24: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 EB18921F8443; Mon, 22 Oct 2012 15:24:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz1xSaJ0PcNJ; Mon, 22 Oct 2012 15:24:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8D521F84AB; Mon, 22 Oct 2012 15:24:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022222404.7257.77875.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 15:24:04 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-01.txt 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, 22 Oct 2012 22:24:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : HTTP Header X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-01.txt Pages : 9 Date : 2012-10-22 Abstract: To improve the protection of web applications against Clickjacking this standard defines an http response header that declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages. This drafts serves to document the existing use and specification of X-Frame-Options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tobias.gondrom@gondrom.org Tue Oct 23 10:12:35 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 5A14311E80D5 for ; Tue, 23 Oct 2012 10:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.062 X-Spam-Level: X-Spam-Status: No, score=-95.062 tagged_above=-999 required=5 tests=[AWL=0.300, 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, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIoU0zZdw2c5 for ; Tue, 23 Oct 2012 10:12:34 -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 0DFC411E80D1 for ; Tue, 23 Oct 2012 10:12:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=HtaTz2iYV2kZbuyYJBmkEKW+CTvzyHqVRfJfA5km9XDlDFtQQfkFqOYufpYlJJ864P3w0K4jbpx4grRdNbomxA9XJOkQWXHP3JCQwcR4OpHodM+utAVciYqUIM8qTCkE; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:Content-Transfer-Encoding; Received: (qmail 25807 invoked from network); 23 Oct 2012 19:12:31 +0200 Received: from unknown (HELO ?10.71.45.180?) (12.201.145.130) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 Oct 2012 19:12:30 +0200 Message-ID: <5086CFFD.9080800@gondrom.org> Date: Tue, 23 Oct 2012 12:12:29 -0500 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: <20120906000758.12304.41648.idtracker@ietfa.amsl.com> In-Reply-To: <20120906000758.12304.41648.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120906000758.12304.41648.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Fwd: NomCom 2012-2013: Call for Feedback 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, 23 Oct 2012 17:12:35 -0000 Hello dear websec fellows, Nomcom is asking for input and feedback about the IESG/IAB/IAOC candidates. They're working hard to select the best candidates and your community input is very important for them. So if you know a candidate and could spare a few minutes to provide feedback on him/her, your help would be very valuable for the good functioning of our IETF community. https://www.ietf.org/group/nomcom/2012/input Please find more details in their email below. Kind regards and thanks a lot for your help, Tobias (co-chair of websec) -------- Original Message -------- Subject: NomCom 2012-2013: Call for Nomination and Feedback Date: Wed, 05 Sep 2012 17:07:58 -0700 From: NomCom Chair To: ietf@ietf.org This is an announcement that the NomCom is seeking feedback on individuals who have accepted nominations for IETF leadership positions. As we are following the advice of RFC 5680, the list of individuals who have agreed to be considered for various positions can be found on the NomCom Community Feedback Tool: https://www.ietf.org/group/nomcom/2012/input Within the coming weeks, we will be updating the list of individuals we are considering for each position as more individuals accept nominations. All feedback provided to the NomCom about these individuals is kept strictly confidential (as per RFC 3777). Your honest feedback is very important to the NomCom process. The open positions being considered by this year's NomCom can be found at the end of this email or on the NomCom 2012-2013 website: https://www.ietf.org/group/nomcom/2012/ With the exception of publicly listing willing nominees, the confidentiality requirements of RFC 3777 remain in effect. All feedback and NomCom deliberations will remain confidential and will not be disclosed. The NomCom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. This year, the NomCom willing be filling the positions currently held by the following individuals, whose terms expire in March 2013: IAOC: -------- Dave Crocker IAB: -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: -------- Russ Housley (IETF Chair) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) In addition to nominations, the Nominating Committee is actively seeking community input on the jobs that need to be filled. We have received the job descriptions from the IAB, IESG, and IAOC and they can be found at: https://www.ietf.org/group/nomcom/2012/iaoc-requirements https://www.ietf.org/group/nomcom/2012/iab-requirements https://www.ietf.org/group/nomcom/2012/chair-requirements https://www.ietf.org/group/nomcom/2012/iesg-requirements However, we also need the community's views and input on the jobs within each organization. If you have ideas on job responsibilities (more, less, different), please let us know. Please send suggestions and feedback to nomcom12@ietf.org. Thank you for your help in identifying qualified nominees, and in providing feedback about individuals we are considering for IETF leadership positions. Matt Lepinski nomcom-chair@ietf.org From ynir@checkpoint.com Tue Oct 23 15:39:50 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 D59491F0C8E for ; Tue, 23 Oct 2012 15:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.583 X-Spam-Level: X-Spam-Status: No, score=-10.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtGf5L+VR-4j for ; Tue, 23 Oct 2012 15:39:50 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 07F1E1F0C3A for ; Tue, 23 Oct 2012 15:39:49 -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 q9NMdl9M016405 for ; Wed, 24 Oct 2012 00:39:47 +0200 X-CheckPoint: {50871AA4-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 24 Oct 2012 00:39:46 +0200 From: Yoav Nir To: IETF WebSec WG Date: Wed, 24 Oct 2012 00:39:45 +0200 Thread-Topic: WGLC for X-Frame-Options Thread-Index: Ac2xb0zTHb33hMtRQwuRaMJzUgzEDQ== Message-ID: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] WGLC for X-Frame-Options 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, 23 Oct 2012 22:39:50 -0000 Hi all This is to initiate WGLC for the X-Frame-Options draft (not to be confused = with the Frame-Options draft). Please go to http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-0= 1, read the draft and send comments. As usual, we would very much like to hear comments about clarity, thoroughn= ess and applicability. Since this draft documents existing behavior, rather= than prescribing future behavior, we would especially like to hear from pe= ople familiar with current implementations that support the X-Frame-Option = header about whether the draft accurately describes the behavior of those i= mplementations. WGLC is usually for two weeks. However, the following two weeks include an = IETF meeting, so I am extending this period to a little over three weeks. W= GLC will end on Friday, November 16th. Please send your comments early, so = that we might use our session in Atlanta to discuss issues that come up. Yoav= From ynir@checkpoint.com Tue Oct 23 16:07: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 949AF1F0CB2 for ; Tue, 23 Oct 2012 16:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VloX97NqSpWK for ; Tue, 23 Oct 2012 16:07:01 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 78CC01F0CAB for ; Tue, 23 Oct 2012 16:07:01 -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 q9NN701J019567 for ; Wed, 24 Oct 2012 01:07:00 +0200 X-CheckPoint: {50872105-6-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 24 Oct 2012 01:07:00 +0200 From: Yoav Nir To: IETF WebSec WG Date: Wed, 24 Oct 2012 01:06:58 +0200 Thread-Topic: Preliminary agenda uploaded Thread-Index: Ac2xcxp2rz0shvw0Sw+o3hLSOl/lKA== Message-ID: <9584A3A8-A490-4F9B-829C-E4F39CA0EB2F@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Preliminary agenda uploaded 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, 23 Oct 2012 23:07:02 -0000 Hi all We've uploaded the preliminary agenda for the Atlanta meeting. http://www.ietf.org/proceedings/85/agenda/agenda-85-websec IETF-85 WebSec Thursday, November 8, 17:30-18:30 ---------------------------------- 1. Note Well, Agenda, Note Takers, Blue sheets (5 min) 2. Document Status (5 min) 3. Pinning (20 min) http://tools.ietf.org/html/draft-ietf-websec-key-pinning-03 4. Future of Frame-Options (10 min) http://tools.ietf.org/html/draft-gondrom-frame-options-02 5. Security Framework (15 min) - Jeff Hodges http://tools.ietf.org/html/draft-hodges-websec-framework-reqs-02 6. Open Mike (5 min) Alexey, Tobias, & Yoav From julian.reschke@gmx.de Fri Oct 26 05:01: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 745D121F8566 for ; Fri, 26 Oct 2012 05:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.654 X-Spam-Level: X-Spam-Status: No, score=-103.654 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foODAEbm5ger for ; Fri, 26 Oct 2012 05:01:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D20C021F84F0 for ; Fri, 26 Oct 2012 05:01:36 -0700 (PDT) Received: (qmail invoked by alias); 26 Oct 2012 12:01:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 26 Oct 2012 14:01:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19ZkL4JSlNZKFZiqPq5GedNijIlSyqNKB4nTX159/ dYZeGG0F51hJxk Message-ID: <508A7B9D.9060804@gmx.de> Date: Fri, 26 Oct 2012 14:01:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: websec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [websec] Twitter / GPHemsley: I am now officially the editor ... 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, 26 Oct 2012 12:01:38 -0000 FYI: > @GPHemsley > > I am now officially the editor of the @WHATWG MIME Sniffing spec: http://mimesniff.spec.whatwg.org Best regards. Julian From ynir@checkpoint.com Fri Oct 26 23:42:51 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 CC20D21F868F for ; Fri, 26 Oct 2012 23:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.588 X-Spam-Level: X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDn8byEuKI2C for ; Fri, 26 Oct 2012 23:42:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BFAD221F8625 for ; Fri, 26 Oct 2012 23:42:50 -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 q9R6gmg4012692 for ; Sat, 27 Oct 2012 08:42:48 +0200 X-CheckPoint: {508B8033-2-1B221DC2-2FFFF} 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; Sat, 27 Oct 2012 08:42:47 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 27 Oct 2012 08:42:48 +0200 From: Yoav Nir To: IETF WebSec WG Date: Sat, 27 Oct 2012 08:42:47 +0200 Thread-Topic: Issue that came up about HSTS Thread-Index: Ac20DkaD8zHkXAo/SM6CcAwX5Nsjzw== Message-ID: <70C766B8-FBF5-4421-B6CE-BCE616FC023B@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [websec] Issue that came up about HSTS 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, 27 Oct 2012 06:42:52 -0000 Hi all draft-ietf-websec-strict-transport-sec is now being edited by the RFC edito= r. An issue has come up. We need to resolve this quickly, so please read th= e following and reply to the list with your opinions. Section 8.4 begins as follows: 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]. The list of example ways that the UA employs to validate certificates inclu= des CRLs and OCSP. The authors believe that the list should be extended to = also include a reference to the succinctly-named RFC 6125 ("Representation = and Verification of Domain-Based Application Service Identity within Intern= et Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context= of Transport Layer Security (TLS)"). See the below suggested text, the new= stuff begins with "as well as" on the penultimate line. 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], as well as via server identity checking [RFC6125].=20 Note that this is not an additional Last Call. If nobody strongly objects t= o this addition, we will add it. We have already heard from Barry that this= addition is fine, and will not require a new LC. Please respond soon, as the RFC editor is working on this document now. Thanks Yoav From paul.hoffman@vpnc.org Sat Oct 27 08:55: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 A813F21F84FC for ; Sat, 27 Oct 2012 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gueNSGWRe5j9 for ; Sat, 27 Oct 2012 08:55:33 -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 D8D8121F84FB for ; Sat, 27 Oct 2012 08:55:32 -0700 (PDT) Received: from [10.20.30.101] (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 q9RFtIHp058596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2012 08:55:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <70C766B8-FBF5-4421-B6CE-BCE616FC023B@checkpoint.com> Date: Sat, 27 Oct 2012 08:55:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <867E7110-38EB-4739-8FCF-0A5324EA0C26@vpnc.org> References: <70C766B8-FBF5-4421-B6CE-BCE616FC023B@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1499) Cc: IETF WebSec WG Subject: Re: [websec] Issue that came up about HSTS 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, 27 Oct 2012 15:55:33 -0000 On Oct 26, 2012, at 11:42 PM, Yoav Nir wrote: > draft-ietf-websec-strict-transport-sec is now being edited by the RFC = editor. An issue has come up. We need to resolve this quickly, so please = read the following and reply to the list with your opinions. This looks like a useful, harmless addition. --Paul Hoffman= From asteingruebl@paypal-inc.com Sun Oct 28 19:53: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 3160F21F8539 for ; Sun, 28 Oct 2012 19:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di0CKSIeRJ5w for ; Sun, 28 Oct 2012 19:53:36 -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 9000321F8538 for ; Sun, 28 Oct 2012 19:53:24 -0700 (PDT) DomainKey-Signature: s=paypalcorp; 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: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=U3P7WGtUik/RcjyrCtmB3QAjLrcM/nlsosGqdfAzCpT8yTRVW7lxiJju TxF8Dr0s9R3a/7/hQkFR4L++hf8zEvHXPFD0XX5Dig2Ft9IU2ubIttWfQ 3zJaZxPQ/zDGsghBtwc81S33+5X83wBkmYejWQuV+rGpHnK9gENSjIV4a s=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1351479217; x=1383015217; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PT1s13G+1+XOb/nV5JRq0sCT1Cc4uNv6aU8KZetehHA=; b=uR2cqoCd0x8gyCB92oInTBTequYtN5c2RA/tl+RnZrltr6U0wiYNExcK +TbkKllidLPs3Zw9OKXQ2TZK2Zrh4IB/YnE5DgD/ASwQGiHn2bj3g5k93 QMUv1mvi7t1oz+A/xvd2V05SHEGRRmOoR0wsKxCpowNTVDXlF7KHxzLOe A=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.80,668,1344236400"; d="scan'208";a="11027578" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 28 Oct 2012 19:53:24 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-002.corp.ebay.com ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.02.0318.001; Sun, 28 Oct 2012 20:53:23 -0600 From: "Steingruebl, Andy" To: Paul Hoffman , Yoav Nir Thread-Topic: [websec] Issue that came up about HSTS Thread-Index: Ac20DkaD8zHkXAo/SM6CcAwX5NsjzwAf3tgAADyjKrA= Date: Mon, 29 Oct 2012 02:53:23 +0000 Message-ID: <1DFCCAFE421024488073B74EEA0173E13884DF@DEN-EXDDA-S12.corp.ebay.com> References: <70C766B8-FBF5-4421-B6CE-BCE616FC023B@checkpoint.com> <867E7110-38EB-4739-8FCF-0A5324EA0C26@vpnc.org> In-Reply-To: <867E7110-38EB-4739-8FCF-0A5324EA0C26@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: IETF WebSec WG Subject: Re: [websec] Issue that came up about HSTS 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, 29 Oct 2012 02:53:37 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Paul Hoffman >=20 > On Oct 26, 2012, at 11:42 PM, Yoav Nir wrote: >=20 > > draft-ietf-websec-strict-transport-sec is now being edited by the RFC > editor. An issue has come up. We need to resolve this quickly, so please = read > the following and reply to the list with your opinions. >=20 > This looks like a useful, harmless addition. If you need a second, consider this it :) - Andy From ynir@checkpoint.com Sun Oct 28 23:02:40 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 89B1621F85E4 for ; Sun, 28 Oct 2012 23:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84P7rjV-yN2z for ; Sun, 28 Oct 2012 23:02:40 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A503121F85E0 for ; Sun, 28 Oct 2012 23:02:39 -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 q9T62VUI018396; Mon, 29 Oct 2012 08:02:31 +0200 X-CheckPoint: {508E19AC-0-1B221DC2-2FFFF} 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; Mon, 29 Oct 2012 08:02:31 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 29 Oct 2012 08:02:31 +0200 From: Yoav Nir To: "Steingruebl, Andy" Date: Mon, 29 Oct 2012 08:02:31 +0200 Thread-Topic: [websec] Issue that came up about HSTS Thread-Index: Ac21mvqY2C1/3iSoRV2cnSg2SFjqqw== Message-ID: References: <70C766B8-FBF5-4421-B6CE-BCE616FC023B@checkpoint.com> <867E7110-38EB-4739-8FCF-0A5324EA0C26@vpnc.org> <1DFCCAFE421024488073B74EEA0173E13884DF@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <1DFCCAFE421024488073B74EEA0173E13884DF@DEN-EXDDA-S12.corp.ebay.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Cc: IETF WebSec WG , Paul Hoffman Subject: Re: [websec] Issue that came up about HSTS 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, 29 Oct 2012 06:02:40 -0000 On Oct 29, 2012, at 4:53 AM, Steingruebl, Andy wrote: >> -----Original Message----- >> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On >> Behalf Of Paul Hoffman >>=20 >> On Oct 26, 2012, at 11:42 PM, Yoav Nir wrote: >>=20 >>> draft-ietf-websec-strict-transport-sec is now being edited by the RFC >> editor. An issue has come up. We need to resolve this quickly, so please= read >> the following and reply to the list with your opinions. >>=20 >> This looks like a useful, harmless addition. >=20 > If you need a second, consider this it :) That's good to know. What we're really after is the presence of (or lack of) statements such as = "oh my god, this is a horrible idea", preferably followed by something begi= nning with "because" :) Otherwise, the authors are for this change (it was Jeff's idea) and if nobo= dy objects, it will go in. Yoav From ynir@checkpoint.com Wed Oct 31 01:04:46 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 6D6E921F86E8 for ; Wed, 31 Oct 2012 01:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE5FlUTzTi6o for ; Wed, 31 Oct 2012 01:04:45 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6D46A21F86DE for ; Wed, 31 Oct 2012 01:04:45 -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 q9V84haV022753 for ; Wed, 31 Oct 2012 10:04:43 +0200 X-CheckPoint: {5090D937-B-1B221DC2-2FFFF} 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; Wed, 31 Oct 2012 10:04:42 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 31 Oct 2012 10:04:42 +0200 From: Yoav Nir To: IETF WebSec WG Date: Wed, 31 Oct 2012 10:04:43 +0200 Thread-Topic: [websec] WGLC for X-Frame-Options Thread-Index: Ac23PmGElApaX6j1RIe6FweDt2lS+g== Message-ID: <124AE7B2-5EB7-42E6-A4CA-F89B2AEF43F8@checkpoint.com> References: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: Re: [websec] WGLC for X-Frame-Options 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: Wed, 31 Oct 2012 08:04:46 -0000 Hi all Don't forget to review and comment the X-Frame-Options draft. Here's my review (no hats) Informational documents do not specify standards. The boilerplate says so: This document is not an Internet Standards Track specification; it is published for informational purposes. I suggest in the abstract changing "... this standard defines" to "... thi= s document describes" The abstract is a little hard to read. Suggested text: OLD: To improve the protection of web applications against Clickjacking this standard defines an http response header that declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages. This drafts serves to document the existing use and specification of X-Frame-Options. NEW: To improve the protection of web applications against Clickjacking, this document describes an http response header that declares a policy communicated from the server to the client browser on whether the browse= r may display the transmitted content in frames that are part of other web pages. This drafts serves to document the existing use and specification of X-Frame-Options. Section 1: the draft is not going to be replaced, but hopefully, the header= is.=20 OLD: This draft is to document the current use of X-Frame-Options header and shall in the future be replaced by the Frame-Options [FRAME-OPTIONS] standard. NEW: This draft documents the current use of the X-Frame-Options header, which shall in the future be replaced by the Frame-Options [FRAME-OPTIONS] standards- based header. =20 Section 2. I don't think you should have a MUST NOT after 'whether'. Also, = the capitalization seems to indicate normative language, while what you are= actually describing are the semantics of the header. OLD: The X-Frame-Options HTTP response header indicates a policy whether a browser MUST NOT allow to render a page in a or