From alexey.melnikov@isode.com Sun Dec 4 15:04:16 2011 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 98FA921F853B for ; Sun, 4 Dec 2011 15:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9kYhj93v8PN for ; Sun, 4 Dec 2011 15:04:16 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id AE81021F8ACA for ; Sun, 4 Dec 2011 15:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1323039854; d=isode.com; s=selector; i=@isode.com; bh=jYtJBSj716T4DsQomJhI777/eEQkvjkNjuH3W8DmXSI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=d6yb1VYC7QimxEvrNezuA2OZyrwgXUMBLkEr1PVSXH2T/cIesNWGC1C6FkMy0EsfCTSZbe M8+qq7CmCPuNy9tqY/RmENzRYFa0+3vrPN4gjvOHNDKt9QpGAW13De9kNPOcRvHE5n6ySi vQaB3c9p+BqxtA7Jg+QZ653McJ8yFbQ=; Received: from [188.28.137.121] (188.28.137.121.threembb.co.uk [188.28.137.121]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 4 Dec 2011 23:04:14 +0000 Message-ID: <4EDBFC6C.9060607@isode.com> Date: Sun, 04 Dec 2011 23:04:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: IETF WebSec WG References: <4EC2D2DF.8050206@stpeter.im> <4EC2DD19.2040003@stpeter.im> <4EC4CD53.8000802@isode.com> In-Reply-To: <4EC4CD53.8000802@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] Acceptance of draft-evans-palmer-key-pinning as a WG document 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, 04 Dec 2011 23:04:16 -0000 On 17/11/2011 09:01, Alexey Melnikov wrote: > Dear WG participants, > > During the WebSec WG face-to-face meeting in Taipei there was room's > rough consensus to accept draft-evans-palmer-key-pinning as a WG > document. This is of course subject to confirmation on the WebSec > mailing list and this message is doing just that. > > Please state your preferences about accepting or rejecting this > document as a WG document before November 25th in reply to this > message, or directly to Tobias and myself. To close the loop on this: I've seen several statement of support on the mailing list with nobody voicing opposition. There is WG consensus to accept the document and as you might have noticed a -00 version of the WG document was posted. Best Regards, Alexey, as a WebSec WG co-chair. From palmer@google.com Thu Dec 8 18:25:15 2011 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 CF8DB1F0C47 for ; Thu, 8 Dec 2011 18:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20Y-jnpVPQEi for ; Thu, 8 Dec 2011 18:25:15 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C87C81F0C49 for ; Thu, 8 Dec 2011 18:25:14 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so3601237wgb.13 for ; Thu, 08 Dec 2011 18:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=q11UR+3zWptHsKxPdFH41k19sVOAOThb9nv0R2ZdSFI=; b=gkGeOnsZ14DyL255cd/WnYs0R1SNgM6Jcd+SCC/j9Np0Bm/qepLdPtTQOz+h+jy62O ipdS0BPWFzrO8lmWtnWw== Received: by 10.216.229.199 with SMTP id h49mr250065weq.96.1323397514027; Thu, 08 Dec 2011 18:25:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.229.199 with SMTP id h49mr250060weq.96.1323397513942; Thu, 08 Dec 2011 18:25:13 -0800 (PST) Received: by 10.216.201.217 with HTTP; Thu, 8 Dec 2011 18:25:13 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1138A2F4206@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1138A2F4206@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 8 Dec 2011 18:25:13 -0800 Message-ID: From: Chris Palmer To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "websec@ietf.org" Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning-00 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, 09 Dec 2011 02:25:15 -0000 On Tue, Nov 29, 2011 at 7:44 PM, Manger, James H wrote: > First, nice work. Thanks! > > If the Public-Key-Pins response header field does not meet all three > > of these criteria [error-free TLS; current key; backup pin], the UA MUS= T > > NOT note the host as a Pinned Host, > > and MUST discard any previously set Pinning Metadata for that host in > > its non-volatile store. > > This seems to make it too easy for an attacker to force a UA to discard > previously set pins for a host, removing the protection they offered. If = an > attacker inserts a Public-Key-Pins HTTP response header into an HTTP (not > HTTPS) response from the server it will fail the 1st criteria (over an > error-free TLS connection). Is that all it takes to turn off pinning for > that host? I think I can satisfy your concern by adding a sentence saying that UAs MUST only pay attention to the Public-Key-Pins response header field if the connection is over TLS. I think that is implicit now, e.g. in the first criterion: """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.""" I'll change it to: """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.""" How is that? > > if the TLS connection has errors=E2=80=A6 the UA might=E2=80=A6 allow t= he user the option > > of continuing with the connection anyway > > If the connection has no errors, the UA will then apply a new > > correctness check: Pin Validation. > > Does this mean pin validation is bypassed if the cert was, say, expired a= nd > the user said continue anyway? > > It doesn=E2=80=99t look right if the UA MUST fail with a non-recoverable = error if > pin validation fails, but an attacker can cause an earlier failure (eg > expired cert) and users will be allowed to click-through that warning and > get to the site. Or the user can click-through a recoverable cert error; = pin > validation is then bypassed; then a Public-Key-Pins header fails the > error-free TLS connection criteria so the UA removes all pinning for this > site. Good point. I have changed the paragraph to: When a UA connects to a Pinned Host, if the TLS connection has errors, the UA MUST terminate the connection without allowing the user to proceed anyway. (This behavior is the same as that required by . > Might be worth explicitly mentioning that only certificates that are > actually used in the validated certificate chain should be used in Pin > Validation, which is not necessarily all the certificates in a TLS > Certificate message (even if the two are supposed to be the same). Good point again. Added this language: If the connection has no errors, the UA will then apply a new correctnes= s check: Pin Validation. To perform Pin Validation, the UA will compute the fingerprints of the SPKI structures in each certificate in the host's validated certificate chain. (The UA ignores superfluous certificates in th= e chain that do not form part of the validating chain.) The UA will then chec= k that the set of these fingerprints intersects the set of fingerprints in that host's Pinning Metadata. If there is set intersection, the UA continue= s with the connection as normal. Otherwise, the UA MUST treat this Pin Failure as a non-recoverable error. > =C2=A0 For hosts that are Known HSTS Hosts the UA MUST terminate > =C2=A0the connection in case of TLS errors, as required by [hsts-draft]. > It is ok to refer to HSTS but this spec shouldn=E2=80=99t repeat a =E2=80= =9CMUST=E2=80=9D from HSTS. That text is gone now. > =C2=A72.1 =E2=80=9CResponse Header Field Syntax=E2=80=9D: The ABNF and th= e examples don=E2=80=99t match > at all. Weird; I thought I updated the examples to match the ABNF but I guess not. Fixing that now... > Typo: =C2=A72.4 =E2=80=9CValidating Pinned Connections=E2=80=9D: =E2=80= =9Cmight or might now=E2=80=9D should be > =E2=80=9Cmight or might not=E2=80=9D That text is gone now. Thanks! I've added you to the Acknowledgements section. From internet-drafts@ietf.org Fri Dec 9 12:14:51 2011 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 EE6D021F893C; Fri, 9 Dec 2011 12:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnLRu+4AJ6bd; Fri, 9 Dec 2011 12:14:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5464121F8880; Fri, 9 Dec 2011 12:14:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111209201451.6282.3929.idtracker@ietfa.amsl.com> Date: Fri, 09 Dec 2011 12:14:51 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-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: Fri, 09 Dec 2011 20:14:52 -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 IET= F. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Filename : draft-ietf-websec-key-pinning-01.txt Pages : 16 Date : 2011-12-09 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-01.txt From James.H.Manger@team.telstra.com Sat Dec 10 06:30:41 2011 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 B2CFF21F88B7 for ; Sat, 10 Dec 2011 06:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muGQ9ybw9N1V for ; Sat, 10 Dec 2011 06:30:41 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id D0ABF21F8564 for ; Sat, 10 Dec 2011 06:30:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,331,1320584400"; d="scan'208";a="55205894" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 11 Dec 2011 01:30:36 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6555"; a="44953114" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbvi.tcif.telstra.com.au with ESMTP; 11 Dec 2011 01:30:36 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Sun, 11 Dec 2011 01:30:35 +1100 From: "Manger, James H" To: "websec@ietf.org" Date: Sun, 11 Dec 2011 01:30:34 +1100 Thread-Topic: Key pinning for DSA keys with inherited domain params Thread-Index: Acy3SEcePub/mpKpSQiq3HeRF5fpVA== Message-ID: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [websec] Key pinning for DSA keys with inherited domain params 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, 10 Dec 2011 14:30:41 -0000 QSBEU0EgcHVibGljIGtleSBjb25zaXN0cyBvZiBhbiBpbnRlZ2VyIHksIHBsdXMgZG9tYWluIHBh cmFtZXRlcnMgcCwgcSwgYW5kIGcuIFRoZSBkb21haW4gcGFyYW1ldGVycyBtYXkgYmUgaW5jbHVk ZWQgaW4gYSBTdWJqZWN0UHVibGljS2V5SW5mbyB2YWx1ZSBmb3IgdGhlIGtleSBpbiBhIGNlcnRp ZmljYXRlLCBidXQgdGhleSBtYXkgYWxzbyBiZSBvbWl0dGVkIGlmIHRoZSBDQSB0aGF0IGlzc3Vl ZCB0aGUgY2VydGlmaWNhdGUgdXNlcyB0aGUgc2FtZSBkb21haW4gcGFyYW1ldGVycyBmb3IgaXRz IGtleS4gW1NlZSBSRkMgMzI3OSBBbGdvcml0aG1zIGFuZCBJZGVudGlmaWVycyBmb3IgUEtJWCwg c2VjdGlvbiAyLjMuMjsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzI3OSNzZWN0aW9u LTIuMy4yXQ0KDQpUaGlzIHNlZW1zIGxpa2UgYSBwcm9ibGVtIGZvciBrZXkgcGlubmluZyBhcyBz cGVjaWZpZWQgaW4gZHJhZnQtaWV0Zi13ZWJzZWMta2V5LXBpbm5pbmctMDEsIHdoZXJlIGEgcGlu IGlzIHRoZSBoYXNoIG9mIGEgU3ViamVjdFB1YmxpY0tleUluZm8gdmFsdWUuIE15IGd1ZXNzIGlz IHRoYXQgaXQgaXMgaW5zZWN1cmUgZm9yIGEgcGluIHRvIG9ubHkgY292ZXIgeSwgYnV0IG5vdCBw LCBxLCBhbmQgZy4NCg0KV2l0aG91dCBnb2luZyBiYWNrIHRvIHRoZSBtYXRocyBvZiBEU0EsIEkg c3VzcGVjdCBhbiBhdHRhY2tlciBjYW4gZmluZCBhbm90aGVyIHNldCBvZiBkb21haW4gcGFyYW1l dGVycyBhbmQgcHJpdmF0ZSBrZXkgdGhhdCBoYXZlIHRoZSBzYW1lIHB1YmxpYyBrZXkgKHkpIGFz IGEgdmljdGltLiBUaGlzIGF0dGFja2VyIGtleSBjYW4gaGF2ZSB0aGUgc2FtZSBwaW4gYXMgdGhl IHZpY3RpbSdzLg0KDQpJIHRoaW5rIHRoZSBzYW1lIGlzc3VlIGFwcGxpZXMgdG8gRUNEU0EgYW5k IEVDREgga2V5cywgYW5kIHBvdGVudGlhbGx5IG90aGVyIHB1YmxpYyBrZXkgYWxnb3JpdGhtcyBh cyB3ZWxsLg0KDQpQb3NzaWJsZSBzb2x1dGlvbnM6DQoNCjEuIFNheSB0aGUgcGlubmluZyBtZWNo YW5pc20gTVVTVCBOT1QgYmUgdXNlZCB3aGVuIGEgU3ViamVjdFB1YmxpY0tleUluZm8gdmFsdWUg ZG9lcyBub3QgY29tcGxldGVseSBzcGVjaWZ5IHRoZSBwdWJsaWMga2V5LCBzdWNoIGFzIHdoZW4g aG9sZGluZyBhIERTQSBrZXkgd2l0aG91dCBpdHMgZG9tYWluIHBhcmFtZXRlcnMuIFRoaXMgd291 bGQgYmUgYWNjZXB0YWJsZSBpZiBubyBvbmUgdXNlcyB0aGUgaW5oZXJpdC1wYXJhbWV0ZXJzLWZy b20tdGhlLUNBIG9wdGlvbi4gSSBoYXZlIG5vIGlkZWEgd2hldGhlciBvciBub3QgdGhhdCBpcyB0 cnVlLg0KDQoyLiBEZWZpbmUgYSBzcGVjaWFsIHJ1bGUgZm9yIGVhY2gga25vd24gYWxnb3JpdGht IHRoYXQgY2FuIGluaGVyaXQgcGFyYW1ldGVycyAoc3VjaCBhcyBEU0EpOiB0aGUgZG9tYWluIHBh cmFtZXRlcnMgTVVTVCBiZSBhZGRlZCAoZnJvbSB0aGUgQ0EgY2VydCwgZm9yIGluc3RhbmNlKSBi ZWZvcmUgY2FsY3VsYXRpbmcgdGhlIHBpbi4gVGhhdCBpcyBhIGJpdCBvZiBhIGJ1cmRlbiBmb3Ig YWxsIGltcGxlbWVudGF0aW9ucy4NCg0KLS1KYW1lcyBNYW5nZXINCg== From davidillsley@gmail.com Sun Dec 11 05:04:10 2011 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 8C63321F8540 for ; Sun, 11 Dec 2011 05:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHWFyE7cqgt6 for ; Sun, 11 Dec 2011 05:04:09 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8521F851F for ; Sun, 11 Dec 2011 05:04:09 -0800 (PST) Received: by wgbds13 with SMTP id ds13so6464872wgb.1 for ; Sun, 11 Dec 2011 05:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=wpbhuoRe7ZHaU155BCmZUy9zDCeuB1ozjsn22hWu4pU=; b=pRCxJlyGBh9cIIoiGu/IkpwrkF0rWyqrTgEm/76437B4N2v5VEvZwC3S5THKysGfgE MKMPeyOV1Getv+HUZX41PCaBl35PpC9yIaLfDgcOdNtBezpIc2BKFWwx06F809dbm7Gk 7UoKIv2heFz9cmC3elQWrr3bs4HsqXA4Ybm1o= Received: by 10.180.103.36 with SMTP id ft4mr18108686wib.59.1323608648440; Sun, 11 Dec 2011 05:04:08 -0800 (PST) Received: from [10.72.156.152] ([217.39.4.84]) by mx.google.com with ESMTPS id u5sm19732179wbm.2.2011.12.11.05.04.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Dec 2011 05:04:06 -0800 (PST) From: davidillsley@gmail.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Dec 2011 13:03:31 +0000 Message-Id: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> To: IETF WebSec WG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [websec] Feedback on draft-ietf-websec-key-pinning-01 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, 11 Dec 2011 13:04:10 -0000 Hi all, It's good to see the progress in draft-ietf-websec-key-pinning-01. I'm = still concerned about the impact of pinning on non-pinned domains, and = don't see anything present to warn about or mitigate this. Apologies if = I've missed discussion of this on-list/in the archives. My concern centers on domains which aren't currently secured, and in the = current environment (IMHO) reasonably so e.g. news.bbc.co.uk or = theregister.co.uk With pinning, if they lose control of their DNS*, visitors during that = period can be HSTS+pinned to a certificate which the domain owner has no = access to, leading them open to long-term denial of service (beyond = reclamation of DNS) or extortion. There's a variant with TLS enabled sites without pinning which could = still be pinned to keys which the domain owner doesn't have access to. There are a few responses to this I can think of: 1. It's 2011/2012... everyone should be using TLS+HSTS+Pinning 2. It's fine - important sites will have decent pull with browser = vendors to ship unlock pins... 3. Modify the spec to make the vulnerability smaller 1 may be a valid response, but in that case, I think the spec should = call out this potential vulnerability in section 3 and highlight that = the only complete mitigation is to go to TLS+HSTS+Pinning. I think it's = important to call out to implementors this possibility, and that they = might have to deal with something like (2). 2 isn't really a solution and doesn't sit well as inevitably smaller = sites won't have as good a pull with vendors and could be disadvantaged. = Also, I doubt the vendors really want to get into the game of = identifying this game. My only thought for 3 is to narrow the vulnerability by softening/not = enforcing the pin until it's seen multiple times over at least some = minimum period of time in which a DNS etc problem is likely to be = rectified. There's already a bootstrapping hole, and I don't know that = widening it by a small time period is a huge deal. Cheers, David * once your registrar is compromised and nameservers changed, getting a = DV cert is trivial for the attacker= From wwwrun@rfc-editor.org Sun Dec 11 14:18:45 2011 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 CEDE521F846B; Sun, 11 Dec 2011 14:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WbyGI9d1rAq; Sun, 11 Dec 2011 14:18:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 78FDF21F8446; Sun, 11 Dec 2011 14:18:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 372A462179; Sun, 11 Dec 2011 14:17:56 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111211221756.372A462179@rfc-editor.org> Date: Sun, 11 Dec 2011 14:17:56 -0800 (PST) Cc: websec@ietf.org, rfc-editor@rfc-editor.org Subject: [websec] RFC 6454 on The Web Origin Concept 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, 11 Dec 2011 22:18:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6454 Title: The Web Origin Concept Author: A. Barth Status: Standards Track Stream: IETF Date: December 2011 Mailbox: ietf@adambarth.com Pages: 20 Characters: 41363 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-websec-origin-06.txt URL: http://www.rfc-editor.org/rfc/rfc6454.txt This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] This document is a product of the Web Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From paul.hoffman@vpnc.org Sun Dec 11 16:38:32 2011 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 A5E1321F844D for ; Sun, 11 Dec 2011 16:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA1fkJsY0O-d for ; Sun, 11 Dec 2011 16:38:31 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8E021F844C for ; Sun, 11 Dec 2011 16:38:31 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBC0cUlQ000264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 11 Dec 2011 17:38:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> Date: Sun, 11 Dec 2011 16:38:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> To: IETF WebSec WG X-Mailer: Apple Mail (2.1251.1) Subject: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 00:38:32 -0000 Greetings again. Alexey asked me to review draft-ietf-websec-key-pinning = with an eye towards which areas are likely to need more work. I hope the = following comments are helpful. - There needs to be an early balancing the advantages of pinning versus = the disadvantages. A description of the possible downsides should be at = least partially listed in Section 1, with a pointer to the Security = Considerations. - Some of the significant disadvantages of pinning are not covered. The = biggest of these (although I could be wrong) is that an MITM can start = using the pinning header with a long max-age before the "real" site has = used the pinning header. When the user finally gets to the "real" site, = they will not connect to it because of the MITM's pin, giving the MITM a = second attempt to come back later. There are probably some other nasty = consequences of this.=20 - While hash agility is a good thing, the current draft's way of doing = this is not the right way. I propose that it instead be changed to "must = be sha-256 or sha-384, and later algorithms can be added only by an RFC = updating this document". - The first paragraph of Section 3 should have its own sub-head to = clarify that it is not superior to the text in Section 3.1. But, more = importantly, Section 3 needs to list the areas where this protocol gives = an MITM better attacks than they have now, and should list those first. Early nit: The first paragraph of Section 1 makes it sound like the = pinning header "does not scale"; this is clearly not what is intended. --Paul Hoffman= From stephen.farrell@cs.tcd.ie Sun Dec 11 16:54:03 2011 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 3C14B21F84ED for ; Sun, 11 Dec 2011 16:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luPZillA9+07 for ; Sun, 11 Dec 2011 16:54:00 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B17F21F84DA for ; Sun, 11 Dec 2011 16:54:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A6C7E1535E7; Mon, 12 Dec 2011 00:53:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1323651238; bh=7cJ7zviDXCappx hxuXkunncAJfH60umOLBkeb0XgaZY=; b=NaPr/thXd1SEfgfplBkJkRAUMkLzCx zWRzGFP4NWTn949AvIDmn2fTAJJxeeen0FzVJ4qADoFwfYcEjnhCBIUmAda8AHEa puOyca5X7GTxvcKoW02COOqeWP836nmjO0uBIe0FGQhoX9gKZNVJ+r+Cokxh2FNl MF5QyjLwdtUchSEfjQsRqeZujmv/rvW0S6T2UfPEzh4ENo1lLsibwww4G41Kk1po y/LaI3fFv5rJ8BqVWaxfyI4mzpw7d2cF8E3GMCXpfh9XYH8MnUBs79xKckprJWme Z6A0k8MNm8vZDboU00G5lLk9P5Dhvy3zQRIU7c08toJnrosCL0dv7dvw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id WMNnlwaXZSLi; Mon, 12 Dec 2011 00:53:58 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.45.62.243]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 37E60153595; Mon, 12 Dec 2011 00:53:57 +0000 (GMT) Message-ID: <4EE550A4.5000801@cs.tcd.ie> Date: Mon, 12 Dec 2011 00:53:56 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Hoffman References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> In-Reply-To: <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 00:54:03 -0000 One other thing... I guess I wonder if the "ni" URI scheme thing [1] is really useful for this or not. That was after all the reason for the earlier discussion on this list. (I think.) Note that I don't really mind if the answer is yes or no. I do think that one way to use URIs to name things via hash function outputs is a good thing, and that two or more ways to do that would be a bad thing, but not all uses of hashes to identify things need to use URIs and I'm not sure which analysis applies here. In any case, be good to decide that too. S. [1] http://tools.ietf.org/html/farrell-decade-ni-00 On 12/12/2011 12:38 AM, Paul Hoffman wrote: > Greetings again. Alexey asked me to review draft-ietf-websec-key-pinning with an eye towards which areas are likely to need more work. I hope the following comments are helpful. > > - There needs to be an early balancing the advantages of pinning versus the disadvantages. A description of the possible downsides should be at least partially listed in Section 1, with a pointer to the Security Considerations. > > - Some of the significant disadvantages of pinning are not covered. The biggest of these (although I could be wrong) is that an MITM can start using the pinning header with a long max-age before the "real" site has used the pinning header. When the user finally gets to the "real" site, they will not connect to it because of the MITM's pin, giving the MITM a second attempt to come back later. There are probably some other nasty consequences of this. > > - While hash agility is a good thing, the current draft's way of doing this is not the right way. I propose that it instead be changed to "must be sha-256 or sha-384, and later algorithms can be added only by an RFC updating this document". > > - The first paragraph of Section 3 should have its own sub-head to clarify that it is not superior to the text in Section 3.1. But, more importantly, Section 3 needs to list the areas where this protocol gives an MITM better attacks than they have now, and should list those first. > > Early nit: The first paragraph of Section 1 makes it sound like the pinning header "does not scale"; this is clearly not what is intended. > > --Paul Hoffman > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From ynir@checkpoint.com Mon Dec 12 06:57:20 2011 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 1CD3821F8B57 for ; Mon, 12 Dec 2011 06:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZZ46ewVsrUq for ; Mon, 12 Dec 2011 06:57:19 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7321F8B54 for ; Mon, 12 Dec 2011 06:57:18 -0800 (PST) X-CheckPoint: {4EE614F7-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBCEvG5V021176; Mon, 12 Dec 2011 16:57:16 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 12 Dec 2011 16:57:16 +0200 From: Yoav Nir To: Paul Hoffman Date: Mon, 12 Dec 2011 16:57:34 +0200 Thread-Topic: [websec] A few comments on draft-ietf-websec-key-pinning Thread-Index: Acy43lavfvwSbCXnRPGWihkJFs86yg== Message-ID: <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> In-Reply-To: <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> 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 Cc: IETF WebSec WG Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 14:57:20 -0000 On Dec 12, 2011, at 2:38 AM, Paul Hoffman wrote: > Greetings again. Alexey asked me to review draft-ietf-websec-key-pinning = with an eye towards which areas are likely to need more work. I hope the fo= llowing comments are helpful. >=20 > - There needs to be an early balancing the advantages of pinning versus t= he disadvantages. A description of the possible downsides should be at leas= t partially listed in Section 1, with a pointer to the Security Considerati= ons. >=20 > - Some of the significant disadvantages of pinning are not covered. The b= iggest of these (although I could be wrong) is that an MITM can start using= the pinning header with a long max-age before the "real" site has used the= pinning header. When the user finally gets to the "real" site, they will n= ot connect to it because of the MITM's pin, giving the MITM a second attemp= t to come back later. There are probably some other nasty consequences of t= his.=20 Section 2.3 does say that pins must only be noted if they come over an erro= r-free HTTPS connection, where the chain contains the pinned SPKI. So the M= ITM would have to be able to take over the DNS (at least for a while) as in= the attack described by David on 11-Dec. Maybe we can mitigate this with a version of this header (or another one) t= hat says "no pins for the next x seconds" >=20 > - While hash agility is a good thing, the current draft's way of doing th= is is not the right way. I propose that it instead be changed to "must be s= ha-256 or sha-384, and later algorithms can be added only by an RFC updatin= g this document". A year from now, "sha-256" is going to be ambiguous. Better to say "sha2-25= 6". >=20 > - The first paragraph of Section 3 should have its own sub-head to clarif= y that it is not superior to the text in Section 3.1. But, more importantly= , Section 3 needs to list the areas where this protocol gives an MITM bette= r attacks than they have now, and should list those first. >=20 > Early nit: The first paragraph of Section 1 makes it sound like the pinni= ng header "does not scale"; this is clearly not what is intended. >=20 > --Paul Hoffman > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Scanned by Check Point Total Security Gateway. From agl@google.com Mon Dec 12 07:03:06 2011 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 705E321F8B71 for ; Mon, 12 Dec 2011 07:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GZL9s9NaNTn for ; Mon, 12 Dec 2011 07:03:06 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF9F421F8B6C for ; Mon, 12 Dec 2011 07:03:05 -0800 (PST) Received: by qcsf15 with SMTP id f15so4258534qcs.31 for ; Mon, 12 Dec 2011 07:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=bxrsDCybWwGL5M/ipT4d7TT5jejEG+Ob+BovM7t9AuY=; b=tcN0CuPcDNVQ5sSu+VMuAd9Bu++431exZVQHH960YxatauttSrTJ0L6Np22/VMY7qK Ljhz0Q5WLYsIy/VV2BHg== Received: by 10.50.203.100 with SMTP id kp4mr16103163igc.7.1323702184944; Mon, 12 Dec 2011 07:03:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.100 with SMTP id kp4mr16103153igc.7.1323702184842; Mon, 12 Dec 2011 07:03:04 -0800 (PST) Received: by 10.231.122.69 with HTTP; Mon, 12 Dec 2011 07:03:04 -0800 (PST) In-Reply-To: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.com> References: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.com> Date: Mon, 12 Dec 2011 10:03:04 -0500 Message-ID: From: Adam Langley To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "websec@ietf.org" Subject: Re: [websec] Key pinning for DSA keys with inherited domain params 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, 12 Dec 2011 15:03:06 -0000 On Sat, Dec 10, 2011 at 9:30 AM, Manger, James H wrote: > 1. Say the pinning mechanism MUST NOT be used when a SubjectPublicKeyInfo= value does not completely specify the public key, such as when holding a D= SA key without its domain parameters. This would be acceptable if no one us= es the inherit-parameters-from-the-CA option. I have no idea whether or not= that is true. I believe that you're correct that this is a problem and I suggest your solution (1): a public key pin cannot be formed if the SPKI is incomplete when taken in isolation. Cheers AGL From paul.hoffman@vpnc.org Mon Dec 12 07:06:22 2011 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 916AA21F8B6D for ; Mon, 12 Dec 2011 07:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp34WsTdcUx9 for ; Mon, 12 Dec 2011 07:06:22 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1382D21F8B6C for ; Mon, 12 Dec 2011 07:06:22 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBCF6BEH028281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Dec 2011 08:06:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> Date: Mon, 12 Dec 2011 07:06:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1251.1) Cc: IETF WebSec WG Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 15:06:22 -0000 On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote: > Section 2.3 does say that pins must only be noted if they come over an = error-free HTTPS connection, where the chain contains the pinned SPKI. = So the MITM would have to be able to take over the DNS (at least for a = while) as in the attack described by David on 11-Dec. I don't agree that the MITM must control the DNS for this attack to = work. As long as the MITM can intercept the TLS handshake, and the = client isn't doing OCSP (or the MITM intercepts that too), using a rogue = cert works; thus the rogue pinning works as well. > Maybe we can mitigate this with a version of this header (or another = one) that says "no pins for the next x seconds" That still doesn't deal with the site that hears about the pinning = header after the MITM does. > A year from now, "sha-256" is going to be ambiguous. Better to say = "sha2-256". Good point, and one that might be made on the SAAG list as well. --Paul Hoffman From ynir@checkpoint.com Mon Dec 12 07:19:06 2011 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 00A5921F8B63 for ; Mon, 12 Dec 2011 07:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9njOEFU-f3Eb for ; Mon, 12 Dec 2011 07:19:05 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 15CC621F8B5B for ; Mon, 12 Dec 2011 07:19:04 -0800 (PST) X-CheckPoint: {4EE61A11-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBCFJ2Gw028291; Mon, 12 Dec 2011 17:19:03 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 12 Dec 2011 17:19:02 +0200 From: Yoav Nir To: Paul Hoffman Date: Mon, 12 Dec 2011 17:19:19 +0200 Thread-Topic: [websec] A few comments on draft-ietf-websec-key-pinning Thread-Index: Acy44WCFEd1hqCPMSaaMm9HkSlnUDg== Message-ID: References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> In-Reply-To: <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> 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 Cc: IETF WebSec WG Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 15:19:06 -0000 On Dec 12, 2011, at 5:06 PM, Paul Hoffman wrote: >=20 > On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote: >=20 >> Section 2.3 does say that pins must only be noted if they come over an e= rror-free HTTPS connection, where the chain contains the pinned SPKI. So th= e MITM would have to be able to take over the DNS (at least for a while) as= in the attack described by David on 11-Dec. >=20 > I don't agree that the MITM must control the DNS for this attack to work.= As long as the MITM can intercept the TLS handshake, and the client isn't = doing OCSP (or the MITM intercepts that too), using a rogue cert works; thu= s the rogue pinning works as well. The rogue cert works only if it validates. So the attacker will have to hav= e compromised the CA as well. Besides, one could argue that using a certifi= cate without OCSP or checking the CRL is not "error-free", but that would h= ave to be clarified. >=20 >> Maybe we can mitigate this with a version of this header (or another one= ) that says "no pins for the next x seconds" >=20 > That still doesn't deal with the site that hears about the pinning header= after the MITM does. Agree, but it allows me to make my site safe from rogue pinning attacks now= . >=20 >> A year from now, "sha-256" is going to be ambiguous. Better to say "sha2= -256". >=20 > Good point, and one that might be made on the SAAG list as well. >=20 From marsh@extendedsubset.com Mon Dec 12 07:52:37 2011 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 69D7921F8B55 for ; Mon, 12 Dec 2011 07:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vrz5V8Mi5pp for ; Mon, 12 Dec 2011 07:52:36 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id B99B021F8B0C for ; Mon, 12 Dec 2011 07:52:36 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Ra8BA-000Me2-AW; Mon, 12 Dec 2011 15:52:36 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F041C63C1; Mon, 12 Dec 2011 15:52:34 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19km9KDYvsFzlgdB8RJXfKaT0yTH27E3AI= Message-ID: <4EE62342.9030303@extendedsubset.com> Date: Mon, 12 Dec 2011 09:52:34 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Paul Hoffman References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> In-Reply-To: <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 15:52:37 -0000 On 12/12/2011 09:06 AM, Paul Hoffman wrote: > > On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote: >> A year from now, "sha-256" is going to be ambiguous. Better to say >> "sha2-256". > > Good point, and one that might be made on the SAAG list as well. It's already somewhat ambiguous now that NIST has defined SHA[-2]-512/256. http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 - Marsh From paul.hoffman@vpnc.org Mon Dec 12 09:06:55 2011 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 3052521F8AF4 for ; Mon, 12 Dec 2011 09:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euxum7kIFYGT for ; Mon, 12 Dec 2011 09:06:54 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74321F8ADC for ; Mon, 12 Dec 2011 09:06:54 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBCH6hZk033970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Dec 2011 10:06:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 12 Dec 2011 09:06:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CAB0F5E-B2EF-4098-99A1-CFF936A0D191@vpnc.org> References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> To: Yoav Nir X-Mailer: Apple Mail (2.1251.1) Cc: IETF WebSec WG Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 17:06:55 -0000 On Dec 12, 2011, at 7:19 AM, Yoav Nir wrote: >=20 > On Dec 12, 2011, at 5:06 PM, Paul Hoffman wrote: >=20 >>=20 >> On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote: >>=20 >>> Section 2.3 does say that pins must only be noted if they come over = an error-free HTTPS connection, where the chain contains the pinned = SPKI. So the MITM would have to be able to take over the DNS (at least = for a while) as in the attack described by David on 11-Dec. >>=20 >> I don't agree that the MITM must control the DNS for this attack to = work. As long as the MITM can intercept the TLS handshake, and the = client isn't doing OCSP (or the MITM intercepts that too), using a rogue = cert works; thus the rogue pinning works as well. >=20 > The rogue cert works only if it validates. So the attacker will have = to have compromised the CA as well. Of course. That is exactly the scenario (and pretty much the only = scenario) where key pinning gives the relying party better security. > Besides, one could argue that using a certificate without OCSP or = checking the CRL is not "error-free", but that would have to be = clarified. We disagree. OCSP and CRL checking only bring benefit to the relying = party if a certificate is revoked. The key pinning scenario is about a = rogue CA issuing a certificate they should not have. There is no = revocation issue in that scenario, is there? >>> Maybe we can mitigate this with a version of this header (or another = one) that says "no pins for the next x seconds" >>=20 >> That still doesn't deal with the site that hears about the pinning = header after the MITM does. >=20 > Agree, but it allows me to make my site safe from rogue pinning = attacks now. Sure, but I don't think that is a good enough reason to argue against = more information in the spec about this problem, which is what I am = requesting. --Paul Hoffman From ynir@checkpoint.com Mon Dec 12 10:54:55 2011 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 D67BF21F8A96 for ; Mon, 12 Dec 2011 10:54:55 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeH9LoKS0IzT for ; Mon, 12 Dec 2011 10:54:55 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 207BA21F84A8 for ; Mon, 12 Dec 2011 10:54:50 -0800 (PST) X-CheckPoint: {4EE64CA2-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBCIsknt017306; Mon, 12 Dec 2011 20:54:46 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 12 Dec 2011 20:54:46 +0200 From: Yoav Nir To: Marsh Ray Date: Mon, 12 Dec 2011 20:55:02 +0200 Thread-Topic: [websec] A few comments on draft-ietf-websec-key-pinning Thread-Index: Acy4/4QdGupFAw5YRbCyw2bIQrQ2zw== Message-ID: <601A5BD0-2ED5-4F97-9B1E-EF355D95B63E@checkpoint.com> References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> <4EE62342.9030303@extendedsubset.com> In-Reply-To: <4EE62342.9030303@extendedsubset.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 Cc: IETF WebSec WG , Paul Hoffman Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 18:54:56 -0000 On Dec 12, 2011, at 5:52 PM, Marsh Ray wrote: > On 12/12/2011 09:06 AM, Paul Hoffman wrote: >>=20 >> On Dec 12, 2011, at 6:57 AM, Yoav Nir wrote: >>> A year from now, "sha-256" is going to be ambiguous. Better to say >>> "sha2-256". >>=20 >> Good point, and one that might be made on the SAAG list as well. >=20 > It's already somewhat ambiguous now that NIST has > defined SHA[-2]-512/256. >=20 > http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 Then that is what it must be called: "sha2-512/256". I think that's a legal= string in HTTP headers. Supposedly this is faster on 64-bit applications. I wonder if that is true = in practice. So far, I have seen no implementations of this hash function. From msk@cloudmark.com Mon Dec 12 11:01:28 2011 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 DD34D21F8AD1 for ; Mon, 12 Dec 2011 11:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.847 X-Spam-Level: X-Spam-Status: No, score=-101.847 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id motyuxIrHMl2 for ; Mon, 12 Dec 2011 11:01:28 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 445EC21F854E for ; Mon, 12 Dec 2011 11:01:25 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Dec 2011 11:01:24 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 12 Dec 2011 11:01:24 -0800 From: "Murray S. Kucherawy" To: "websec@ietf.org" Date: Mon, 12 Dec 2011 11:01:23 -0800 Thread-Topic: Same Origins and email Thread-Index: Acy5AHD6JLGjr493SS+DT264pQWIcw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15518EXCHC2corpclo_" MIME-Version: 1.0 Subject: [websec] Same Origins and email 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, 12 Dec 2011 19:01:29 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15518EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, long-time lurker, first-time poster. I don't work in the web browser business so much as I do the messaging anti= -abuse business. But this stuff has gotten my attention. Now that RFC6454= is published, I have a few questions about its possible application in my = context. My first question (probably of several): What is the origin of an HTML docu= ment when it's viewed in an HTML-aware MUA because it arrived by email? -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C15518EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all, long-tim= e lurker, first-time poster.

 =

I don’t work in the web browser busine= ss so much as I do the messaging anti-abuse business.  But this stuff = has gotten my attention.  Now that RFC6454 is published, I have a few = questions about its possible application in my context.

My first question (pro= bably of several): What is the origin of an HTML document when it’s v= iewed in an HTML-aware MUA because it arrived by email?

 

-MSK

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C15518EXCHC2corpclo_-- From ietf@adambarth.com Mon Dec 12 11:09:25 2011 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 934E521F8ACA for ; Mon, 12 Dec 2011 11:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kekDl3K-ShW for ; Mon, 12 Dec 2011 11:09:25 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49321F8ABE for ; Mon, 12 Dec 2011 11:09:24 -0800 (PST) Received: by qcsf15 with SMTP id f15so4556565qcs.31 for ; Mon, 12 Dec 2011 11:09:24 -0800 (PST) Received: by 10.50.183.201 with SMTP id eo9mr16866728igc.79.1323716964207; Mon, 12 Dec 2011 11:09:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id r18sm33181724ibh.4.2011.12.12.11.09.22 (version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 11:09:23 -0800 (PST) Received: by iaek3 with SMTP id k3so10750994iae.31 for ; Mon, 12 Dec 2011 11:09:22 -0800 (PST) Received: by 10.50.183.201 with SMTP id eo9mr16866650igc.79.1323716962127; Mon, 12 Dec 2011 11:09:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.159.138 with HTTP; Mon, 12 Dec 2011 11:08:51 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Mon, 12 Dec 2011 11:08:51 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 19:09:25 -0000 On Mon, Dec 12, 2011 at 11:01 AM, Murray S. Kucherawy w= rote: > Hi all, long-time lurker, first-time poster. > > I don=92t work in the web browser business so much as I do the messaging > anti-abuse business.=A0 But this stuff has gotten my attention.=A0 Now th= at > RFC6454 is published, I have a few questions about its possible applicati= on > in my context. > > My first question (probably of several): What is the origin of an HTML > document when it=92s viewed in an HTML-aware MUA because it arrived by em= ail? That depends on the MUA. In Gmail, for example, the origin is https://mail.google.com. It depends on the URL the MUA assigns to the HTML document contained in the email. Adam From msk@cloudmark.com Mon Dec 12 11:13:29 2011 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 823A821F84F9 for ; Mon, 12 Dec 2011 11:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaR8IsZ56ml1 for ; Mon, 12 Dec 2011 11:13:29 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1591B21F84F8 for ; Mon, 12 Dec 2011 11:13:29 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Dec 2011 11:13:28 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 12 Dec 2011 11:13:28 -0800 From: "Murray S. Kucherawy" To: "websec@ietf.org" Date: Mon, 12 Dec 2011 11:13:27 -0800 Thread-Topic: [websec] Same Origins and email Thread-Index: Acy5AZDt9P4QjQXiRwqxcARgKUZXZgAAHl8A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 19:13:29 -0000 > -----Original Message----- > From: Adam Barth [mailto:ietf@adambarth.com] > Sent: Monday, December 12, 2011 11:09 AM > To: Murray S. Kucherawy > Cc: websec@ietf.org > Subject: Re: [websec] Same Origins and email >=20 > That depends on the MUA. In Gmail, for example, the origin is > https://mail.google.com. It depends on the URL the MUA assigns to the > HTML document contained in the email. What about something like Outlook or alpine, where we're not talking about = a web-based MUA but one that pulls from a local store? -MSK From tony@att.com Mon Dec 12 11:14:35 2011 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 5D5BE21F850D for ; Mon, 12 Dec 2011 11:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.49 X-Spam-Level: X-Spam-Status: No, score=-105.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tTkoE2CTbA7 for ; Mon, 12 Dec 2011 11:14:34 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 88C7721F84F9 for ; Mon, 12 Dec 2011 11:14:34 -0800 (PST) X-Env-Sender: tony@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1323717272!5430909!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20552 invoked from network); 12 Dec 2011 19:14:33 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Dec 2011 19:14:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pBCJF07f021330 for ; Mon, 12 Dec 2011 14:15:01 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pBCJEt2j021219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Dec 2011 14:14:56 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Mon, 12 Dec 2011 14:14:19 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pBCJEJII002052 for ; Mon, 12 Dec 2011 14:14:19 -0500 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pBCJEDRT001848 for ; Mon, 12 Dec 2011 14:14:13 -0500 Received: from [135.91.110.247] (ds135-91-110-247.dhcps.ugn.att.com[135.91.110.247]) by maillennium.att.com (mailgw1) with ESMTP id <20111212191252gw100e4lphe> (Authid: tony); Mon, 12 Dec 2011 19:12:52 +0000 X-Originating-IP: [135.91.110.247] Message-ID: <4EE65284.2060807@att.com> Date: Mon, 12 Dec 2011 14:14:12 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Yoav Nir References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> <4EE62342.9030303@extendedsubset.com> <601A5BD0-2ED5-4F97-9B1E-EF355D95B63E@checkpoint.com> In-Reply-To: <601A5BD0-2ED5-4F97-9B1E-EF355D95B63E@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: IETF WebSec WG Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 19:14:35 -0000 On 12/12/2011 1:55 PM, Yoav Nir wrote: > On Dec 12, 2011, at 5:52 PM, Marsh Ray wrote: > >> It's already somewhat ambiguous now that NIST has >> defined SHA[-2]-512/256. >> >> http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 > Then that is what it must be called: "sha2-512/256". I think that's a legal string in HTTP headers. > > Supposedly this is faster on 64-bit applications. I wonder if that is true in practice. So far, I have seen no implementations of this hash function. I've done a complete bit-level implementation. It's a straight-forward modification to RFC 6234. Tony Hansen tony@att.com From Jeff.Hodges@KingsMountain.com Mon Dec 12 11:17:29 2011 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 9B7CD21F8AF0 for ; Mon, 12 Dec 2011 11:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.78 X-Spam-Level: X-Spam-Status: No, score=-98.78 tagged_above=-999 required=5 tests=[AWL=0.885, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlBxJNZx-NPd for ; Mon, 12 Dec 2011 11:17:29 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id D37A121F8AD9 for ; Mon, 12 Dec 2011 11:17:28 -0800 (PST) Received: (qmail 11244 invoked by uid 0); 12 Dec 2011 19:17:07 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 12 Dec 2011 19:17:07 -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=R8OEF9aaaaRwCQBN6DfstJ85he+OxhAo9hJYhkVAkBc=; b=DCaCXpMFQp/jkG5yhk5zZU16EIZFVbx+nR7vBCEnu8Vnv6nEs2P9lO2DQUA9xAZiHh5gie/tZvWPNgyFdVrvLr9r+BjiYmPaE3SbRxdCvvJZfKEmiXmh2Q8bsxW/8iws; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.187]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RaBN4-0005KJ-N0 for websec@ietf.org; Mon, 12 Dec 2011 12:17:06 -0700 Message-ID: <4EE65331.8070201@KingsMountain.com> Date: Mon, 12 Dec 2011 11:17:05 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 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] RFC 6454 on The Web Origin Concept 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, 12 Dec 2011 19:17:29 -0000 Congrats to Adam and the working group on getting this spec out the door -- it's a super contribution to our collective gradual chipping away at and documenting web folklore. =JeffH From stpeter@stpeter.im Mon Dec 12 11:23:18 2011 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 5233A21F8B00 for ; Mon, 12 Dec 2011 11:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.294 X-Spam-Level: X-Spam-Status: No, score=-103.294 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhyxHtLQYhy3 for ; Mon, 12 Dec 2011 11:23:17 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DA42521F8AFF for ; Mon, 12 Dec 2011 11:23:17 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 76E85423AD; Mon, 12 Dec 2011 12:30:49 -0700 (MST) Message-ID: <4EE654A4.6070108@stpeter.im> Date: Mon, 12 Dec 2011 12:23:16 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: =JeffH References: <4EE65331.8070201@KingsMountain.com> In-Reply-To: <4EE65331.8070201@KingsMountain.com> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] RFC 6454 on The Web Origin Concept 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, 12 Dec 2011 19:23:18 -0000 On 12/12/11 12:17 PM, =JeffH wrote: > Congrats to Adam and the working group on getting this spec out the door > -- it's a super contribution to our collective gradual chipping away at > and documenting web folklore. Hear, hear! From ynir@checkpoint.com Mon Dec 12 11:23:24 2011 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 9BF6921F8AFC for ; Mon, 12 Dec 2011 11:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzsyCuXJF8j8 for ; Mon, 12 Dec 2011 11:23:24 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8A57221F8AFD for ; Mon, 12 Dec 2011 11:23:23 -0800 (PST) X-CheckPoint: {4EE65352-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBCJNKvB023179; Mon, 12 Dec 2011 21:23:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 12 Dec 2011 21:23:20 +0200 From: Yoav Nir To: Tony Hansen Date: Mon, 12 Dec 2011 21:23:18 +0200 Thread-Topic: [websec] A few comments on draft-ietf-websec-key-pinning Thread-Index: Acy5A4ES6wIWN6dYQROJTILXRvnbZw== Message-ID: <08236326-850C-4C58-B506-EBB53AC6FCB5@checkpoint.com> References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> <4EE62342.9030303@extendedsubset.com> <601A5BD0-2ED5-4F97-9B1E-EF355D95B63E@checkpoint.com> <4EE65284.2060807@att.com> In-Reply-To: <4EE65284.2060807@att.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 Cc: IETF WebSec WG Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 19:23:24 -0000 On Dec 12, 2011, at 9:14 PM, Tony Hansen wrote: > On 12/12/2011 1:55 PM, Yoav Nir wrote: >> On Dec 12, 2011, at 5:52 PM, Marsh Ray wrote: >>=20 >>> It's already somewhat ambiguous now that NIST has >>> defined SHA[-2]-512/256. >>>=20 >>> http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 >> Then that is what it must be called: "sha2-512/256". I think that's a le= gal string in HTTP headers. >>=20 >> Supposedly this is faster on 64-bit applications. I wonder if that is tr= ue in practice. So far, I have seen no implementations of this hash functio= n. >=20 > I've done a complete bit-level implementation. It's a straight-forward=20 > modification to RFC 6234. Yeah, me too. But I haven't seen it used in certificates or anything else. = I also never measured the performance with either 32- or 64-bit code, and I= don't see people rushing to write "HMAC-SHA2-512/256 and its use in IPsec/= TLS/SSH/whatever". Last time I checked, it wasn't in OpenSSL either.= From ynir@checkpoint.com Mon Dec 12 11:25:26 2011 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 959CD21F8AFC for ; Mon, 12 Dec 2011 11:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxF8KgH2oG3y for ; Mon, 12 Dec 2011 11:25:26 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A5AC021F8500 for ; Mon, 12 Dec 2011 11:25:25 -0800 (PST) X-CheckPoint: {4EE653CC-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBCJPL2B023522; Mon, 12 Dec 2011 21:25:21 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 12 Dec 2011 21:25:21 +0200 From: Yoav Nir To: "Murray S. Kucherawy" Date: Mon, 12 Dec 2011 21:25:20 +0200 Thread-Topic: [websec] Same Origins and email Thread-Index: Acy5A8mOrfidyAe0QtSJZDfIz5NWZQ== Message-ID: <215EC5C2-A72E-461E-BF9E-1E291CDBD439@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 Cc: "websec@ietf.org" Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 19:25:26 -0000 On Dec 12, 2011, at 9:13 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Adam Barth [mailto:ietf@adambarth.com] >> Sent: Monday, December 12, 2011 11:09 AM >> To: Murray S. Kucherawy >> Cc: websec@ietf.org >> Subject: Re: [websec] Same Origins and email >>=20 >> That depends on the MUA. In Gmail, for example, the origin is >> https://mail.google.com. It depends on the URL the MUA assigns to the >> HTML document contained in the email. >=20 > What about something like Outlook or alpine, where we're not talking abou= t a web-based MUA but one that pulls from a local store? file://localhost ? Although I think HTML you get through the mail should not be scripted by fi= les on your computer, so maybe each mail item should have its own origin.= From tlr@w3.org Mon Dec 12 11:25:39 2011 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 846D721F8B04 for ; Mon, 12 Dec 2011 11:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiQI6eeC3OWH for ; Mon, 12 Dec 2011 11:25:39 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8921F8500 for ; Mon, 12 Dec 2011 11:25:38 -0800 (PST) Received: from [88.207.166.28] (helo=[192.168.2.107]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RaBVI-0004KA-60; Mon, 12 Dec 2011 14:25:36 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Thomas Roessler In-Reply-To: <4EE65331.8070201@KingsMountain.com> Date: Mon, 12 Dec 2011 20:25:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76183644-A142-4D66-8B25-6DFA7BBE2264@w3.org> References: <4EE65331.8070201@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1251.1) Cc: IETF WebSec WG Subject: Re: [websec] RFC 6454 on The Web Origin Concept 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, 12 Dec 2011 19:25:39 -0000 On 2011-12-12, at 20:17 +0100, =3DJeffH wrote: > Congrats to Adam and the working group on getting this spec out the = door -- it's a super contribution to our collective gradual chipping = away at and documenting web folklore. +100 Thanks, Adam! From ietf@adambarth.com Mon Dec 12 11:35:45 2011 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 89DAF21F8B00 for ; Mon, 12 Dec 2011 11:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am68AY8nVh2L for ; Mon, 12 Dec 2011 11:35:45 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1072D21F8AFF for ; Mon, 12 Dec 2011 11:35:44 -0800 (PST) Received: by qadb15 with SMTP id b15so3247757qad.10 for ; Mon, 12 Dec 2011 11:35:44 -0800 (PST) Received: by 10.50.184.168 with SMTP id ev8mr16683282igc.62.1323718544278; Mon, 12 Dec 2011 11:35:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id j3sm54463914ibj.1.2011.12.12.11.35.43 (version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 11:35:43 -0800 (PST) Received: by iaek3 with SMTP id k3so10783299iae.31 for ; Mon, 12 Dec 2011 11:35:43 -0800 (PST) Received: by 10.42.156.195 with SMTP id a3mr12927882icx.25.1323718543002; Mon, 12 Dec 2011 11:35:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.159.138 with HTTP; Mon, 12 Dec 2011 11:35:11 -0800 (PST) In-Reply-To: <215EC5C2-A72E-461E-BF9E-1E291CDBD439@checkpoint.com> References: <215EC5C2-A72E-461E-BF9E-1E291CDBD439@checkpoint.com> From: Adam Barth Date: Mon, 12 Dec 2011 11:35:11 -0800 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 19:35:45 -0000 On Mon, Dec 12, 2011 at 11:25 AM, Yoav Nir wrote: > On Dec 12, 2011, at 9:13 PM, Murray S. Kucherawy wrote: >>> -----Original Message----- >>> From: Adam Barth [mailto:ietf@adambarth.com] >>> Sent: Monday, December 12, 2011 11:09 AM >>> To: Murray S. Kucherawy >>> Cc: websec@ietf.org >>> Subject: Re: [websec] Same Origins and email >>> >>> That depends on the MUA. =A0In Gmail, for example, the origin is >>> https://mail.google.com. =A0It depends on the URL the MUA assigns to th= e >>> HTML document contained in the email. >> >> What about something like Outlook or alpine, where we're not talking abo= ut a web-based MUA but one that pulls from a local store? > > file://localhost ? > > Although I think HTML you get through the mail should not be scripted by = files on your computer, so maybe each mail item should have its own origin. The questions you're asking don't really have universal answers. These behaviors aren't standardized and so are likely to vary from MUA to MUA. Adam From msk@cloudmark.com Mon Dec 12 11:38:30 2011 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 8112D21F84FA for ; Mon, 12 Dec 2011 11:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMLm1cXRHEGv for ; Mon, 12 Dec 2011 11:38:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 18A7321F84B1 for ; Mon, 12 Dec 2011 11:38:30 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Dec 2011 11:38:29 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 12 Dec 2011 11:38:29 -0800 From: "Murray S. Kucherawy" To: "websec@ietf.org" Date: Mon, 12 Dec 2011 11:38:28 -0800 Thread-Topic: [websec] Same Origins and email Thread-Index: Acy5BT6afa831L/ZSsGYpcdYPbeTIQAAA67g Message-ID: References: <215EC5C2-A72E-461E-BF9E-1E291CDBD439@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 19:38:30 -0000 > -----Original Message----- > From: Adam Barth [mailto:ietf@adambarth.com] > Sent: Monday, December 12, 2011 11:35 AM > To: Yoav Nir > Cc: Murray S. Kucherawy; websec@ietf.org > Subject: Re: [websec] Same Origins and email >=20 > The questions you're asking don't really have universal answers. > These behaviors aren't standardized and so are likely to vary from MUA > to MUA. I think that's why I'm asking the question. I wonder if it would be a useful area to explore in terms of standardizatio= n since MUA-based HTML pages suffer many of the same attacks as regular bro= wsers do. That seems to be an attack surface that's largely unaddressed he= re. From palmer@google.com Mon Dec 12 11:38:45 2011 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 05F5F21F84DD for ; Mon, 12 Dec 2011 11:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmAAS+OePW6R for ; Mon, 12 Dec 2011 11:38:44 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEF021F84B1 for ; Mon, 12 Dec 2011 11:38:44 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so9080855wgb.13 for ; Mon, 12 Dec 2011 11:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=FJ+ozVHuEOXRQf5dPnVfq+gfmKAx5ddMdMujq9k/Rrg=; b=Au9H/796M92HNXaW2TV7EbNS8iR4Cqglqc1g7S7C5eBpZNjb8HTWfBZPZ+5s/49iUv ZYqsp4Lnd4w0KL2kWnSQ== Received: by 10.227.60.4 with SMTP id n4mr15224451wbh.9.1323718722062; Mon, 12 Dec 2011 11:38:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.60.4 with SMTP id n4mr15224440wbh.9.1323718721907; Mon, 12 Dec 2011 11:38:41 -0800 (PST) Received: by 10.216.201.217 with HTTP; Mon, 12 Dec 2011 11:38:41 -0800 (PST) In-Reply-To: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> Date: Mon, 12 Dec 2011 11:38:41 -0800 Message-ID: From: Chris Palmer To: davidillsley@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] Feedback on draft-ietf-websec-key-pinning-01 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, 12 Dec 2011 19:38:45 -0000 On Sun, Dec 11, 2011 at 5:03 AM, wrote: > With pinning, if they lose control of their DNS*, visitors during that pe= riod can be HSTS+pinned to a certificate which the domain owner has no acce= ss to, leading them open to long-term denial of service (beyond reclamation= of DNS) or extortion. How do DNS registrars handle theft and extortion now? Does pinning significantly change the dynamic of the scam? It seems to me like pinning somewhat increases the visibility and detection risk of theft/extortion, but I admit I don't know much about this scam phenomenon. The victim must do more than just get the registrar to fix the DNS, they must also get the private keys for the falsely-pinned public keys. But the attacker has to get a certificate, which involves tricking both a registrar and a CA, and paying the latter. (Since UAs MUST only note pins received over an error-free TLS connection, the attacker must have received a certificate for the domain name they stole, signed by a trusted certification authority. Obviously, that is not impossible (or even difficult, as you note). Importantly, due to the need for a CA-signed cert, the attack creates a "paper" and money trail. If it happens often, the internet community will come to know which CAs are not checking for domain theft, and we can start to un-trust those CAs. And we can ask them to tell us what they know about the attackers who bought the certs.) This puts a bit of upward quality pressure on CAs. For example, maybe DV issuers could look more closely into the history of the domain's ownership before issuing the certificate: Has the new owner owned the domain for one day? Maybe we should call the technical contact who previously owned it for three years up until yesterday? Has the registrar had a rash of domain theft lately? This is good for everyone: internet users, internet site operators, and the CAs and registrars who work hard to be trustworthy. Pinning makes your choice of CA matter again. > There are a few responses to this I can think of: > > 1. It's 2011/2012... everyone should be using TLS+HSTS+Pinning > 2. It's fine - important sites will have decent pull with browser vendors= to ship unlock pins... > 3. Modify the spec to make the vulnerability smaller Yes to (1) and (3), and like you I don't like (2). As a browser engineer, I don't want to be handling support emails from people who've had their domains hijacked =E2=80=94 that won't scale =E2=80=94 and = internet security must be available to everyone. > 1 may be a valid response, but in that case, I think the spec should call= out this potential vulnerability in section 3 and highlight that the only = complete mitigation is to go to TLS+HSTS+Pinning. I think it's important to= call out to implementors this possibility, and that they might have to dea= l with something like (2). Ok, I'll come up with some text. > My only thought for 3 is to narrow the vulnerability by softening/not enf= orcing the pin until it's seen multiple times over at least some minimum pe= riod of time in which a DNS etc problem is likely to be rectified. There's = already a bootstrapping hole, and I don't know that widening it by a small = time period is a huge deal. Because the bootstrapping hole is so much smaller with pinning than without, I agree that we have some headroom to play with. Requiring a minimum time period might not be a bad idea. What would it look like? "UAs MUST note the same set of pinned public keys for 168 hours (7 days) before treating the host as a Known Pinned Host and requiring Pin Validation." ? Does anyone have any data on domain theft and extortion? How often does it happen, how long does it last, how much is the ransom, et c.? From msk@cloudmark.com Mon Dec 12 11:42:42 2011 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 8F26921F84FB for ; Mon, 12 Dec 2011 11:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWL3JyMA7T9i for ; Mon, 12 Dec 2011 11:42:42 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1930C21F8AFC for ; Mon, 12 Dec 2011 11:42:42 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Dec 2011 11:42:41 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 12 Dec 2011 11:42:41 -0800 From: "Murray S. Kucherawy" To: "websec@ietf.org" Date: Mon, 12 Dec 2011 11:42:40 -0800 Thread-Topic: [websec] Same Origins and email Thread-Index: Acy5A8mOrfidyAe0QtSJZDfIz5NWZQAAOLAg Message-ID: References: <215EC5C2-A72E-461E-BF9E-1E291CDBD439@checkpoint.com> In-Reply-To: <215EC5C2-A72E-461E-BF9E-1E291CDBD439@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 19:42:42 -0000 > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com] > Sent: Monday, December 12, 2011 11:25 AM > To: Murray S. Kucherawy > Cc: websec@ietf.org > Subject: Re: [websec] Same Origins and email >=20 > > What about something like Outlook or alpine, where we're not talking > > about a web-based MUA but one that pulls from a local store? >=20 > file://localhost ? >=20 > Although I think HTML you get through the mail should not be scripted > by files on your computer, so maybe each mail item should have its own > origin. I was thinking maybe "mailto:" followed by whatever address is parsed from = the From: field. The problem, of course, is that it's trivially forged. Given that I come from the messaging side and not from the browser side, I'= m trying to ensure I've got the idea here: Is the idea of web origins to in= form the target server of URIs in the HTML document about where the request= came from, a little more generally than what Referer does, and allowing ch= aining, thus permitting the server servicing that URI the choice to refuse = or substitute the content where it determines the referral was likely fraud= ulent? Or does it allow the user agent to make more informed choices about= which URIs it is willing to dereference? Or both? Is it possible for a server to use web origins to list other web origins al= lowed to reference it? Say, could a bank's reply to an tag inclu= de a list of authorized origins? (That might be hard to secure, but I'm ta= lking generally here.) Basically, if there's a way to use this stuff to help reduce the attack sur= face in HTML email, I'd love to put it to use, and that's what I'm (pardon = the pun) fishing around for here. Thanks, -MSK From ietf@adambarth.com Mon Dec 12 11:53:25 2011 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 046E521F85F1 for ; Mon, 12 Dec 2011 11:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95p9xeLNRjcZ for ; Mon, 12 Dec 2011 11:53:24 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8658621F8551 for ; Mon, 12 Dec 2011 11:53:24 -0800 (PST) Received: by yenm7 with SMTP id m7so5026701yen.31 for ; Mon, 12 Dec 2011 11:53:23 -0800 (PST) Received: by 10.236.79.38 with SMTP id h26mr28536867yhe.39.1323719603158; Mon, 12 Dec 2011 11:53:23 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mx.google.com with ESMTPS id o50sm32332981yhl.9.2011.12.12.11.53.20 (version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 11:53:20 -0800 (PST) Received: by qcsf15 with SMTP id f15so4600624qcs.31 for ; Mon, 12 Dec 2011 11:53:19 -0800 (PST) Received: by 10.50.196.196 with SMTP id io4mr16343062igc.55.1323719599409; Mon, 12 Dec 2011 11:53:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.159.138 with HTTP; Mon, 12 Dec 2011 11:52:47 -0800 (PST) In-Reply-To: References: <215EC5C2-A72E-461E-BF9E-1E291CDBD439@checkpoint.com> From: Adam Barth Date: Mon, 12 Dec 2011 11:52:47 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 19:53:25 -0000 On Mon, Dec 12, 2011 at 11:38 AM, Murray S. Kucherawy w= rote: >> -----Original Message----- >> From: Adam Barth [mailto:ietf@adambarth.com] >> Sent: Monday, December 12, 2011 11:35 AM >> To: Yoav Nir >> Cc: Murray S. Kucherawy; websec@ietf.org >> Subject: Re: [websec] Same Origins and email >> >> The questions you're asking don't really have universal answers. >> These behaviors aren't standardized and so are likely to vary from MUA >> to MUA. > > I think that's why I'm asking the question. > > I wonder if it would be a useful area to explore in terms of standardizat= ion since MUA-based HTML pages suffer many of the same attacks as regular b= rowsers do. =A0That seems to be an attack surface that's largely unaddresse= d here. I really have an opinion on that topic. If you'd like to move in that direction, I'd recommend talking with implementors of MUAs to see if they'd be interested in implementing such a standard. Adam From rbarnes@bbn.com Mon Dec 12 12:01:44 2011 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 B103621F8B04 for ; Mon, 12 Dec 2011 12:01:44 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, MIME error: error: part did not end with expected boundary X-Spam-Flag: NO X-Spam-Score: -104.044 X-Spam-Level: X-Spam-Status: No, score=-104.044 tagged_above=-999 required=5 tests=[AWL=-2.555, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.56, MIME_QP_LONG_LINE=1.396, MPART_ALT_DIFF=0.739, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcaGYkjkNfok for ; Mon, 12 Dec 2011 12:01:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4331F21F8AF7 for ; Mon, 12 Dec 2011 12:01:43 -0800 (PST) Received: from ros-dhcp192-1-51-99.bbn.com ([192.1.51.99]:62680 helo=bbn.com) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RaC4C-000OK3-N4 for websec@ietf.org; Mon, 12 Dec 2011 15:01:42 -0500 From: "Richard Barnes" To: "WEBSEC Mailing List" Content-Type: multipart/alternative; boundary="1260560318.3FEb2Dc3.23682" Message-Id: Date: Mon, 12 Dec 2011 15:01:41 -0500 Subject: [websec] Test of XHR in HTML mail 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, 12 Dec 2011 20:01:44 -0000 --1260560318.3FEb2Dc3.23682 Date: Fri, 11 Dec 2009 14:38:38 -0500 MIME-Version: 1.0 Content-Type: text/plain The plain text form of this message isn't very interesting. --1260560318.3FEb2Dc3.23682 Date: Fri, 11 Dec 2009 14:38:38 -0500 MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-Disposition: inline XHR Tester web
--1260560318.3FEb2Dc3.23682-- From rbarnes@bbn.com Mon Dec 12 12:04:31 2011 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 AA81921F8B04 for ; Mon, 12 Dec 2011 12:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.28 X-Spam-Level: X-Spam-Status: No, score=-106.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdacyydi+MC6 for ; Mon, 12 Dec 2011 12:04:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4100321F8AFD for ; Mon, 12 Dec 2011 12:04:31 -0800 (PST) Received: from ros-dhcp192-1-51-99.bbn.com ([192.1.51.99]:62745) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RaC6w-000OYS-Sm; Mon, 12 Dec 2011 15:04:30 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 12 Dec 2011 15:04:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7B56D5AA-5052-4898-A73A-AED1F958019C@bbn.com> References: To: "Richard Barnes" X-Mailer: Apple Mail (2.1084) Cc: WEBSEC Mailing List Subject: Re: [websec] Test of XHR in HTML mail 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, 12 Dec 2011 20:04:31 -0000 Figured it might be interesting to have an empirical test of how MUAs = handle origin-bound things like XHRs. =20 In my tests (Mail.app, Thunderbird, Gmail), none of the MUAs seemed to = do anything; they didn't even display the failure message. My guess is = that they just don't support XHR, but I haven't looked into it. --Richard On Dec 12, 2011, at 3:01 PM, Richard Barnes wrote: > test web=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From rbarnes@bbn.com Mon Dec 12 12:07:03 2011 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 10C8D21F8B0E for ; Mon, 12 Dec 2011 12:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.315 X-Spam-Level: X-Spam-Status: No, score=-106.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8Mzwdl98bpp for ; Mon, 12 Dec 2011 12:07:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8F94B21F8B0C for ; Mon, 12 Dec 2011 12:07:02 -0800 (PST) Received: from ros-dhcp192-1-51-99.bbn.com ([192.1.51.99]:62768) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RaC9O-000Ob0-6m; Mon, 12 Dec 2011 15:07:02 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <7B56D5AA-5052-4898-A73A-AED1F958019C@bbn.com> Date: Mon, 12 Dec 2011 15:07:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9D762009-DF92-4B54-8B21-9767AC099C34@bbn.com> References: <7B56D5AA-5052-4898-A73A-AED1F958019C@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1084) Cc: WEBSEC Mailing List Subject: Re: [websec] Test of XHR in HTML mail 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, 12 Dec 2011 20:07:03 -0000 In fact, it doesn't look like they're even processing the onload handler = for the element (except for Gmail). That black line you see is a = collapsed
, and it should be hidden on load. Maybe MUAs just = aren't supporting Javascript? --Richard=20 On Dec 12, 2011, at 3:04 PM, Richard L. Barnes wrote: > Figured it might be interesting to have an empirical test of how MUAs = handle origin-bound things like XHRs. =20 >=20 > In my tests (Mail.app, Thunderbird, Gmail), none of the MUAs seemed to = do anything; they didn't even display the failure message. My guess is = that they just don't support XHR, but I haven't looked into it. >=20 > --Richard >=20 >=20 >=20 > On Dec 12, 2011, at 3:01 PM, Richard Barnes wrote: >=20 >> test web=20 >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >=20 From marsh@extendedsubset.com Mon Dec 12 12:29:58 2011 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 B0FB321F86EE for ; Mon, 12 Dec 2011 12:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edJdNoWtyUs0 for ; Mon, 12 Dec 2011 12:29:58 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0F79221F86B3 for ; Mon, 12 Dec 2011 12:29:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RaCVY-000NAe-6V; Mon, 12 Dec 2011 20:29:56 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AFA6863C4; Mon, 12 Dec 2011 20:29:54 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19otFCE1i7hYVdYyN+zJbyfuGMp5jvTkaM= Message-ID: <4EE66440.3080501@extendedsubset.com> Date: Mon, 12 Dec 2011 14:29:52 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Yoav Nir References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> <4EE62342.9030303@extendedsubset.com> <601A5BD0-2ED5-4F97-9B1E-EF355D95B63E@checkpoint.com> In-Reply-To: <601A5BD0-2ED5-4F97-9B1E-EF355D95B63E@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG , Paul Hoffman Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 20:29:58 -0000 On 12/12/2011 12:55 PM, Yoav Nir wrote: > > On Dec 12, 2011, at 5:52 PM, Marsh Ray wrote: >> >> It's already somewhat ambiguous now that NIST has >> defined SHA[-2]-512/256. >> >> http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 > > Then that is what it must be called: "sha2-512/256". I think that's a legal string in HTTP headers. > > Supposedly this is faster on 64-bit applications. I wonder if that is true in practice. SHA-2-512/256 should perform identically to plain SHA-2-512. It's the same function only with a different IV. This site is dedicated to benchmarking hash functions: http://bench.cr.yp.to/results-hash.html It doesn't appear to be faster than, say, SHA-1, SHA-2-512 but does not appear to be subject to the same attacks either. > So far, I have seen no implementations of this hash function. I made one for use at work, but it's only a minor adjustment to the RFC 6234 SHA-2-512 reference code. - Marsh From ynir@checkpoint.com Mon Dec 12 12:52:28 2011 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 2A9D421F8AEA for ; Mon, 12 Dec 2011 12:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1fsU5ssc1Nj for ; Mon, 12 Dec 2011 12:52:27 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 13A2B21F861E for ; Mon, 12 Dec 2011 12:52:26 -0800 (PST) X-CheckPoint: {4EE66831-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBCKqMW0008376; Mon, 12 Dec 2011 22:52:22 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 12 Dec 2011 22:52:22 +0200 From: Yoav Nir To: Marsh Ray Date: Mon, 12 Dec 2011 22:52:21 +0200 Thread-Topic: [websec] A few comments on draft-ietf-websec-key-pinning Thread-Index: Acy5D/F5yaOc3sLfT52pGiYaNWDrlw== Message-ID: <91F65EF4-B7FB-43C7-8C21-9C2799BC9AC3@checkpoint.com> References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <32ED4792-4720-471A-A074-ECDAA172CC47@vpnc.org> <39133E20-4136-4AA4-B7C6-48DC1299109E@checkpoint.com> <430F2576-C8CB-4F2C-A3A3-BADDE4600A06@vpnc.org> <4EE62342.9030303@extendedsubset.com> <601A5BD0-2ED5-4F97-9B1E-EF355D95B63E@checkpoint.com> <4EE66440.3080501@extendedsubset.com> In-Reply-To: <4EE66440.3080501@extendedsubset.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 Cc: IETF WebSec WG , Paul Hoffman Subject: Re: [websec] A few comments on draft-ietf-websec-key-pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 20:52:28 -0000 On Dec 12, 2011, at 10:29 PM, Marsh Ray wrote: > On 12/12/2011 12:55 PM, Yoav Nir wrote: >>=20 >> On Dec 12, 2011, at 5:52 PM, Marsh Ray wrote: >>>=20 >>> It's already somewhat ambiguous now that NIST has >>> defined SHA[-2]-512/256. >>>=20 >>> http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4 >>=20 >> Then that is what it must be called: "sha2-512/256". I think that's a le= gal string in HTTP headers. >>=20 >> Supposedly this is faster on 64-bit applications. I wonder if that is tr= ue in practice. >=20 > SHA-2-512/256 should perform identically to plain SHA-2-512. It's the=20 > same function only with a different IV. Yes, and the claim in the original paper was that SHA2-512 was faster on 64= -bit systems than SHA2-256. I haven't verified this. > This site is dedicated to benchmarking hash functions: > http://bench.cr.yp.to/results-hash.html >=20 > It doesn't appear to be faster than, say, SHA-1, SHA-2-512 but does not=20 > appear to be subject to the same attacks either. >=20 >> So far, I have seen no implementations of this hash function. >=20 > I made one for use at work, but it's only a minor adjustment to the RFC=20 > 6234 SHA-2-512 reference code. I did that as well. From Jeff.Hodges@KingsMountain.com Mon Dec 12 12:57:12 2011 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 5EC1D21F8A57 for ; Mon, 12 Dec 2011 12:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.316 X-Spam-Level: X-Spam-Status: No, score=-99.316 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5+xylFdKnem for ; Mon, 12 Dec 2011 12:57:11 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by ietfa.amsl.com (Postfix) with SMTP id C112421F8A4B for ; Mon, 12 Dec 2011 12:57:11 -0800 (PST) Received: (qmail 26569 invoked by uid 0); 12 Dec 2011 20:56:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 12 Dec 2011 20:56:50 -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=pmFeC4DJZhfEYgkjSID+PrIh9KGQIMBO4EMPhEMAMes=; b=bua1nCLYBx6S8XDjsuGd1Ch2nAus9wdyrzWMdnLKUgH/hGDsv4gJD5YhDd18/cTFXf4AmAqBjty/lcLkiTzCeO60kMq17WZeqWtZ/5MxD3ev3SNMJHNhaDPjT5L714QC; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.187]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RaCvZ-0004Nz-Va for websec@ietf.org; Mon, 12 Dec 2011 13:56:50 -0700 Message-ID: <4EE66A90.2020205@KingsMountain.com> Date: Mon, 12 Dec 2011 12:56:48 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 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] Same Origins and email 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, 12 Dec 2011 20:57:12 -0000 > I really have an opinion on that topic. is "I don't really.." what you actually meant ? =JeffH From ietf@adambarth.com Mon Dec 12 13:06:18 2011 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 86C0021F867F for ; Mon, 12 Dec 2011 13:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYVDHD9lvzEr for ; Mon, 12 Dec 2011 13:06:17 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67BEF21F86A4 for ; Mon, 12 Dec 2011 13:06:17 -0800 (PST) Received: by vbbez10 with SMTP id ez10so4553754vbb.31 for ; Mon, 12 Dec 2011 13:06:16 -0800 (PST) Received: by 10.182.222.106 with SMTP id ql10mr3404534obc.53.1323723976790; Mon, 12 Dec 2011 13:06:16 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id l1sm21173391obv.1.2011.12.12.13.06.15 (version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 13:06:16 -0800 (PST) Received: by dajz8 with SMTP id z8so7242442daj.31 for ; Mon, 12 Dec 2011 13:06:14 -0800 (PST) Received: by 10.50.156.133 with SMTP id we5mr16397003igb.74.1323723974529; Mon, 12 Dec 2011 13:06:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.160.165 with HTTP; Mon, 12 Dec 2011 13:05:43 -0800 (PST) In-Reply-To: <4EE66A90.2020205@KingsMountain.com> References: <4EE66A90.2020205@KingsMountain.com> From: Adam Barth Date: Mon, 12 Dec 2011 13:05:43 -0800 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 21:06:18 -0000 On Mon, Dec 12, 2011 at 12:56 PM, =3DJeffH = wrote: >> I really have an opinion on that topic. > > is "I don't really.." =A0what you actually meant ? Yes! From ietf@adambarth.com Mon Dec 12 13:06:46 2011 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 AD94F21F867F for ; Mon, 12 Dec 2011 13:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QrlJ8YvvXhG for ; Mon, 12 Dec 2011 13:06:46 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 289BA21F8678 for ; Mon, 12 Dec 2011 13:06:46 -0800 (PST) Received: by qcsf15 with SMTP id f15so4679050qcs.31 for ; Mon, 12 Dec 2011 13:06:44 -0800 (PST) Received: by 10.50.87.167 with SMTP id az7mr16932735igb.64.1323724004344; Mon, 12 Dec 2011 13:06:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id l28sm77650841ibc.3.2011.12.12.13.06.42 (version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 13:06:42 -0800 (PST) Received: by iaek3 with SMTP id k3so10893437iae.31 for ; Mon, 12 Dec 2011 13:06:42 -0800 (PST) Received: by 10.42.136.137 with SMTP id u9mr10409710ict.50.1323724002289; Mon, 12 Dec 2011 13:06:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.160.165 with HTTP; Mon, 12 Dec 2011 13:06:10 -0800 (PST) In-Reply-To: References: <215EC5C2-A72E-461E-BF9E-1E291CDBD439@checkpoint.com> From: Adam Barth Date: Mon, 12 Dec 2011 13:06:10 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Same Origins and email 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, 12 Dec 2011 21:06:46 -0000 On Mon, Dec 12, 2011 at 11:52 AM, Adam Barth wrote: > On Mon, Dec 12, 2011 at 11:38 AM, Murray S. Kucherawy = wrote: >>> -----Original Message----- >>> From: Adam Barth [mailto:ietf@adambarth.com] >>> Sent: Monday, December 12, 2011 11:35 AM >>> To: Yoav Nir >>> Cc: Murray S. Kucherawy; websec@ietf.org >>> Subject: Re: [websec] Same Origins and email >>> >>> The questions you're asking don't really have universal answers. >>> These behaviors aren't standardized and so are likely to vary from MUA >>> to MUA. >> >> I think that's why I'm asking the question. >> >> I wonder if it would be a useful area to explore in terms of standardiza= tion since MUA-based HTML pages suffer many of the same attacks as regular = browsers do. =A0That seems to be an attack surface that's largely unaddress= ed here. > > I ^^ don't :) > really have an opinion on that topic. =A0If you'd like to move in that > direction, I'd recommend talking with implementors of MUAs to see if > they'd be interested in implementing such a standard. > > Adam From davidillsley@gmail.com Mon Dec 12 13:09:29 2011 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 7BF6D21F84AA for ; Mon, 12 Dec 2011 13:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6gVK6n412eF for ; Mon, 12 Dec 2011 13:09:28 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B621F8496 for ; Mon, 12 Dec 2011 13:09:28 -0800 (PST) Received: by pbbb4 with SMTP id b4so1754522pbb.31 for ; Mon, 12 Dec 2011 13:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+MtjyEg+GpOswk1n6DiNVH7kaP9lzIzGTxd4aaTWQB8=; b=LSnALyPlA7xvXct1six1WK9o8Eirkwf9MGeHmnN7+BvJtqmlfvrfzQtN7KfE06PP5p UI+hX3q8KEEbEVpiByo7VLHFVVbN6ZeLIep5GMZuYbpj6ny3eugPUqNAATgaBBdqyTid BbRPxpTaXgqg9q/7EViuMbVkax6w68DTQ1Kas= MIME-Version: 1.0 Received: by 10.68.191.106 with SMTP id gx10mr36654192pbc.60.1323724168366; Mon, 12 Dec 2011 13:09:28 -0800 (PST) Received: by 10.68.49.166 with HTTP; Mon, 12 Dec 2011 13:09:28 -0800 (PST) In-Reply-To: References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> Date: Mon, 12 Dec 2011 21:09:28 +0000 Message-ID: From: David Illsley To: Chris Palmer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] Feedback on draft-ietf-websec-key-pinning-01 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, 12 Dec 2011 21:09:29 -0000 On Mon, Dec 12, 2011 at 7:38 PM, Chris Palmer wrote: > On Sun, Dec 11, 2011 at 5:03 AM, =A0 wrote: > >> With pinning, if they lose control of their DNS*, visitors during that p= eriod can be HSTS+pinned to a certificate which the domain owner has no acc= ess to, leading them open to long-term denial of service (beyond reclamatio= n of DNS) or extortion. > > How do DNS registrars handle theft and extortion now? Does pinning > significantly change the dynamic of the scam? It seems to me like > pinning somewhat increases the visibility and detection risk of > theft/extortion, but I admit I don't know much about this scam > phenomenon. The victim must do more than just get the registrar to fix > the DNS, they must also get the private keys for the falsely-pinned > public keys. But the attacker has to get a certificate, which involves > tricking both a registrar and a CA, and paying the latter. I think the dynamic is changed because at the moment, you have a registrar which you have a contractual relationship to fall back on when something goes wrong, and things are likely resolved in a short period of time. Once the registrar has straightened things out, you've just got to wait for DNS TTLs to expire and you're good to go. With pinning, your registrar can still straighten DNS out, but any visitors who accessed the site in the affected period (hours-tens of hours at a guess) are pinned to a private key you have no access to. > > (Since UAs MUST only note pins received over an error-free TLS > connection, the attacker must have received a certificate for the > domain name they stole, signed by a trusted certification authority. > Obviously, that is not impossible (or even difficult, as you note). > Importantly, due to the need for a CA-signed cert, the attack creates > a "paper" and money trail. If it happens often, the internet community > will come to know which CAs are not checking for domain theft, and we > can start to un-trust those CAs. And we can ask them to tell us what > they know about the attackers who bought the certs.) Yeah, it's definitely useful to have more data points, but I'll put my hands up to being pessimistic about the CA model. The paper trail might be useful, but a stolen credit card from country A being used in with a CA in country B when you're in country C might be hard to really make anything of. > > This puts a bit of upward quality pressure on CAs. For example, maybe > DV issuers could look more closely into the history of the domain's > ownership before issuing the certificate: Has the new owner owned the > domain for one day? Maybe we should call the technical contact who > previously owned it for three years up until yesterday? Has the > registrar had a rash of domain theft lately? This is good for > everyone: internet users, internet site operators, and the CAs and > registrars who work hard to be trustworthy. Pinning makes your choice > of CA matter again. We can wish... I'm still hoping we actually get CAs special-case-checking DV certs for domains which have a publicly facing EV cert... > >> There are a few responses to this I can think of: >> >> 1. It's 2011/2012... everyone should be using TLS+HSTS+Pinning >> 2. It's fine - important sites will have decent pull with browser vendor= s to ship unlock pins... >> 3. Modify the spec to make the vulnerability smaller > > Yes to (1) and (3), and like you I don't like (2). As a browser > engineer, I don't want to be handling support emails from people > who've had their domains hijacked =97 that won't scale =97 and internet > security must be available to everyone. > >> 1 may be a valid response, but in that case, I think the spec should cal= l out this potential vulnerability in section 3 and highlight that the only= complete mitigation is to go to TLS+HSTS+Pinning. I think it's important t= o call out to implementors this possibility, and that they might have to de= al with something like (2). > > Ok, I'll come up with some text. Great. Thanks. > >> My only thought for 3 is to narrow the vulnerability by softening/not en= forcing the pin until it's seen multiple times over at least some minimum p= eriod of time in which a DNS etc problem is likely to be rectified. There's= already a bootstrapping hole, and I don't know that widening it by a small= time period is a huge deal. > > Because the bootstrapping hole is so much smaller with pinning than > without, I agree that we have some headroom to play with. Requiring a > minimum time period might not be a bad idea. What would it look like? > "UAs MUST note the same set of pinned public keys for 168 hours (7 > days) before treating the host as a Known Pinned Host and requiring > Pin Validation." ? > > Does anyone have any data on domain theft and extortion? How often > does it happen, how long does it last, how much is the ransom, et c.? Unfortunately I don't, and I do think pinning does change things anyway. FWIW, the event that made me think of this was apparently 'for fun' [1]. Such people might also consider a long-term denial of service 'fun' :-( David [1] http://www.guardian.co.uk/technology/2011/sep/05/turkish-hacker-group-d= iverts-users From palmer@google.com Mon Dec 12 16:37:55 2011 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 B98D911E8080 for ; Mon, 12 Dec 2011 16:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezsn0myUYGJ3 for ; Mon, 12 Dec 2011 16:37:55 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABAC11E8073 for ; Mon, 12 Dec 2011 16:37:53 -0800 (PST) Received: by bkbzs8 with SMTP id zs8so6828028bkb.31 for ; Mon, 12 Dec 2011 16:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=Iw4/B7y/bJV/XKrpi9H8z9BOiWKXBW6v15lgsOpBUdo=; b=jLhCshFoNQrecmkFBUkc3JbJEyAqKFA1Cs2MOEss6e9dKjMSdYmuCQ423Kyjz3KI5k tMjvT4y3bYJYZMxBG8Lg== Received: by 10.180.90.234 with SMTP id bz10mr18818401wib.46.1323736672388; Mon, 12 Dec 2011 16:37:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.90.234 with SMTP id bz10mr18818391wib.46.1323736672279; Mon, 12 Dec 2011 16:37:52 -0800 (PST) Received: by 10.216.227.94 with HTTP; Mon, 12 Dec 2011 16:37:52 -0800 (PST) In-Reply-To: References: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.com> Date: Mon, 12 Dec 2011 16:37:52 -0800 Message-ID: From: Chris Palmer To: Adam Langley Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "websec@ietf.org" Subject: Re: [websec] Key pinning for DSA keys with inherited domain params 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, 13 Dec 2011 00:37:55 -0000 Also, FWIW, from the EFF SSL Observatory: mysql> select distinct `Subject Public Key Info:Public Key Algorithm` from valid_certs; +----------------------------------------------+ | Subject Public Key Info:Public Key Algorithm | +----------------------------------------------+ | rsaEncryption | | dsaEncryption | +----------------------------------------------+ 2 rows in set (4.09 sec) mysql> select count(*) from valid_certs where `Subject Public Key Info:Public Key Algorithm` like '%dsa%'; +----------+ | count(*) | +----------+ | 25 | +----------+ 1 row in set (3.26 sec) From palmer@google.com Mon Dec 12 16:55:32 2011 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 3363411E8082 for ; Mon, 12 Dec 2011 16:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzNn03+k5ZTI for ; Mon, 12 Dec 2011 16:55:31 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 897FC11E807F for ; Mon, 12 Dec 2011 16:55:31 -0800 (PST) Received: by wgbds13 with SMTP id ds13so9307432wgb.1 for ; Mon, 12 Dec 2011 16:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=BGxnlxtg0DcfEXMhR5wksaYxgbVxs49GjY+w065Q/zQ=; b=T2UaS4VDNPimUNs95hLn5feZTX99exIYtWBdatgeE772Vgy4pLO5wyJmmbT9AEuj53 zQglMqWFgvkctjQZX/0w== Received: by 10.180.84.71 with SMTP id w7mr24489055wiy.37.1323737730772; Mon, 12 Dec 2011 16:55:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.84.71 with SMTP id w7mr24489048wiy.37.1323737730703; Mon, 12 Dec 2011 16:55:30 -0800 (PST) Received: by 10.216.227.94 with HTTP; Mon, 12 Dec 2011 16:55:30 -0800 (PST) In-Reply-To: References: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.com> Date: Mon, 12 Dec 2011 16:55:30 -0800 Message-ID: From: Chris Palmer To: Adam Langley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "websec@ietf.org" Subject: Re: [websec] Key pinning for DSA keys with inherited domain params 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, 13 Dec 2011 00:55:32 -0000 Of these, the handful that I spot-checked are all either down, expired, or have been replaced with certificates for RSA keys. On Mon, Dec 12, 2011 at 4:37 PM, Chris Palmer wrote: > Also, FWIW, from the EFF SSL Observatory: > > mysql> select distinct `Subject Public Key Info:Public Key Algorithm` > from valid_certs; > +----------------------------------------------+ > | Subject Public Key Info:Public Key Algorithm | > +----------------------------------------------+ > | =C2=A0rsaEncryption =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | > | =C2=A0dsaEncryption =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | > +----------------------------------------------+ > 2 rows in set (4.09 sec) > > mysql> select count(*) from valid_certs where `Subject Public Key > Info:Public Key Algorithm` like '%dsa%'; > +----------+ > | count(*) | > +----------+ > | =C2=A0 =C2=A0 =C2=A0 25 | > +----------+ > 1 row in set (3.26 sec) From ynir@checkpoint.com Mon Dec 12 22:11:55 2011 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 2AC0921F8538 for ; Mon, 12 Dec 2011 22:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.28 X-Spam-Level: X-Spam-Status: No, score=-10.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odtvCm43TahE for ; Mon, 12 Dec 2011 22:11:53 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 46C5321F84D2 for ; Mon, 12 Dec 2011 22:11:53 -0800 (PST) X-CheckPoint: {4EE6EB4B-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBD6BnX1030055; Tue, 13 Dec 2011 08:11:49 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 13 Dec 2011 08:11:49 +0200 From: Yoav Nir To: Chris Palmer Date: Tue, 13 Dec 2011 08:11:39 +0200 Thread-Topic: [websec] Key pinning for DSA keys with inherited domain params Thread-Index: Acy5Xhld5Y+196YyRvKZnr+G5tKZKg== Message-ID: References: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Key pinning for DSA keys with inherited domain params 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, 13 Dec 2011 06:11:55 -0000 True. I don't expect DSA to ever become viable enough to worry about. I th= ink if you ran the same select for ECDSA, you would come up with zero, but = there is some expectation of that changing in the long run.=20 By now all the major browsers except Opera support ECDSA, so we might be se= eing some of those when websites feel it's safe to abandon the IE6-on-Windo= ws-XP and old Macs. On Dec 13, 2011, at 2:55 AM, Chris Palmer wrote: > Of these, the handful that I spot-checked are all either down, > expired, or have been replaced with certificates for RSA keys. >=20 > On Mon, Dec 12, 2011 at 4:37 PM, Chris Palmer wrote: >> Also, FWIW, from the EFF SSL Observatory: >>=20 >> mysql> select distinct `Subject Public Key Info:Public Key Algorithm` >> from valid_certs; >> +----------------------------------------------+ >> | Subject Public Key Info:Public Key Algorithm | >> +----------------------------------------------+ >> | rsaEncryption | >> | dsaEncryption | >> +----------------------------------------------+ >> 2 rows in set (4.09 sec) >>=20 >> mysql> select count(*) from valid_certs where `Subject Public Key >> Info:Public Key Algorithm` like '%dsa%'; >> +----------+ >> | count(*) | >> +----------+ >> | 25 | >> +----------+ >> 1 row in set (3.26 sec) From gerv@mozilla.org Tue Dec 13 02:12:41 2011 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 34A7221F86A4 for ; Tue, 13 Dec 2011 02:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNEwsQFWJvSg for ; Tue, 13 Dec 2011 02:12:40 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id B095B21F86A0 for ; Tue, 13 Dec 2011 02:12:40 -0800 (PST) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by dm-mail03.mozilla.org (Postfix) with ESMTP id B48274AED58; Tue, 13 Dec 2011 02:12:39 -0800 (PST) Message-ID: <4EE72516.1080201@mozilla.org> Date: Tue, 13 Dec 2011 10:12:38 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111103 Thunderbird/8.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <7B56D5AA-5052-4898-A73A-AED1F958019C@bbn.com> <9D762009-DF92-4B54-8B21-9767AC099C34@bbn.com> In-Reply-To: <9D762009-DF92-4B54-8B21-9767AC099C34@bbn.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: WEBSEC Mailing List Subject: Re: [websec] Test of XHR in HTML mail 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, 13 Dec 2011 10:12:41 -0000 On 12/12/11 20:07, Richard L. Barnes wrote: > In fact, it doesn't look like they're even processing the onload > handler for the element (except for Gmail). That black line > you see is a collapsed
, and it should be hidden on load. Maybe > MUAs just aren't supporting Javascript? --Richard It's not that they don't support it (Thunderbird is half-written in JavaScript!), it's that they turn it off. It's been disabled by default since at least Thunderbird 2. Doing so leads to a large reduction in attack surface. Gerv From julian.reschke@gmx.de Tue Dec 13 02:24:10 2011 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 574FE21F84A7 for ; Tue, 13 Dec 2011 02:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRnJu5R1EYbK for ; Tue, 13 Dec 2011 02:24:09 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 83DFE21F84A6 for ; Tue, 13 Dec 2011 02:24:09 -0800 (PST) Received: (qmail invoked by alias); 13 Dec 2011 10:24:07 -0000 Received: from p3EE27C0A.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.124.10] by mail.gmx.net (mp044) with SMTP; 13 Dec 2011 11:24:07 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/UHUIXkmvUHWOK/AMDPCEiYwfW9c0aLIFsrhf/L4 7NRVTWYF1F0k12 Message-ID: <4EE727C4.3020606@gmx.de> Date: Tue, 13 Dec 2011 11:24:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "websec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [websec] X-Requested-With header field 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, 13 Dec 2011 10:24:10 -0000 Hi, it seems this header field is widely implemented. Is it here to stay? If so, shouldn't it be documented somewhere? Best regards, Julian From hallam@gmail.com Tue Dec 13 04:56:32 2011 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 0D9DC21F8ABD for ; Tue, 13 Dec 2011 04:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c00s7seUXqQP for ; Tue, 13 Dec 2011 04:56:31 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D490721F854E for ; Tue, 13 Dec 2011 04:56:30 -0800 (PST) Received: by ggnk5 with SMTP id k5so7645626ggn.31 for ; Tue, 13 Dec 2011 04:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gfLdsD6HWnB0ThUuCWoe3FltZrIUdorE/PD79lTo920=; b=Et75mVeemrwBLWaP0nm59Gz+YTxxTAFIMv3RBU+3EO6Aw794/K66KT9Kojc6QQVz5C i7mSoOJS3MaQ/ePumONIdpccVbuzc9BcgmjbscvSfB+PNaNl7xJvOpw5i/tgYcKr4Dm9 9b9dixeTKjlBkyC2OW66YDaem+rzLB12rRMss= MIME-Version: 1.0 Received: by 10.182.41.98 with SMTP id e2mr132714obl.77.1323780989395; Tue, 13 Dec 2011 04:56:29 -0800 (PST) Received: by 10.182.160.72 with HTTP; Tue, 13 Dec 2011 04:56:29 -0800 (PST) In-Reply-To: References: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.com> Date: Tue, 13 Dec 2011 07:56:29 -0500 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d0444eccda221d204b3f8c730 Cc: "websec@ietf.org" Subject: Re: [websec] Key pinning for DSA keys with inherited domain params 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, 13 Dec 2011 12:56:32 -0000 --f46d0444eccda221d204b3f8c730 Content-Type: text/plain; charset=ISO-8859-1 DSA is unlikely to be widespread enough to cause problems. But I cannot be confident that the same problem is not going to appear with ECC parameters. (sorry for the double negative). I don't like a solution for pinning that depends on the CA delivering the 'right' sort of cert. I would prefer to add in a second hash over the parameter values or specify them explicitly in the pin or to have the hash be over what the values would be if completely specified in the Key Info. On Tue, Dec 13, 2011 at 1:11 AM, Yoav Nir wrote: > True. I don't expect DSA to ever become viable enough to worry about. I > think if you ran the same select for ECDSA, you would come up with zero, > but there is some expectation of that changing in the long run. > > By now all the major browsers except Opera support ECDSA, so we might be > seeing some of those when websites feel it's safe to abandon the > IE6-on-Windows-XP and old Macs. > > On Dec 13, 2011, at 2:55 AM, Chris Palmer wrote: > > > Of these, the handful that I spot-checked are all either down, > > expired, or have been replaced with certificates for RSA keys. > > > > On Mon, Dec 12, 2011 at 4:37 PM, Chris Palmer wrote: > >> Also, FWIW, from the EFF SSL Observatory: > >> > >> mysql> select distinct `Subject Public Key Info:Public Key Algorithm` > >> from valid_certs; > >> +----------------------------------------------+ > >> | Subject Public Key Info:Public Key Algorithm | > >> +----------------------------------------------+ > >> | rsaEncryption | > >> | dsaEncryption | > >> +----------------------------------------------+ > >> 2 rows in set (4.09 sec) > >> > >> mysql> select count(*) from valid_certs where `Subject Public Key > >> Info:Public Key Algorithm` like '%dsa%'; > >> +----------+ > >> | count(*) | > >> +----------+ > >> | 25 | > >> +----------+ > >> 1 row in set (3.26 sec) > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --f46d0444eccda221d204b3f8c730 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable DSA is unlikely to be widespread enough to cause problems.

But I cannot be confident that the same problem is not going to appear w= ith ECC parameters. (sorry for the double negative).


I don't like a solution for pinning that depends on= the CA delivering the 'right' sort of cert. I would prefer to add = in a second hash over the parameter values or specify them explicitly in th= e pin or to have the hash be over what the values would be if completely sp= ecified in the Key Info.


On Tue, Dec 13, 2011 at = 1:11 AM, Yoav Nir <ynir@checkpoint.com> wrote:
True. I don't expect DSA to ever become viable enough to worry about. = =A0I think if you ran the same select for ECDSA, you would come up with zer= o, but there is some expectation of that changing in the long run.

By now all the major browsers except Opera support ECDSA, so we might be se= eing some of those when websites feel it's safe to abandon the IE6-on-W= indows-XP and old Macs.

On Dec 13, 2011, at 2:55 AM, Chris Palmer wrote:

> Of these, the handful that I spot-checked are all either down,
> expired, or have been replaced with certificates for RSA keys.
>
> On Mon, Dec 12, 2011 at 4:37 PM, Chris Palmer <palmer@google.com> wrote:
>> Also, FWIW, from the EFF SSL Observatory:
>>
>> mysql> select distinct `Subject Public Key Info:Public Key Algo= rithm`
>> from valid_certs;
>> +----------------------------------------------+
>> | Subject Public Key Info:Public Key Algorithm |
>> +----------------------------------------------+
>> | =A0rsaEncryption =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 |
>> | =A0dsaEncryption =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 |
>> +----------------------------------------------+
>> 2 rows in set (4.09 sec)
>>
>> mysql> select count(*) from valid_certs where `Subject Public K= ey
>> Info:Public Key Algorithm` like '%dsa%';
>> +----------+
>> | count(*) |
>> +----------+
>> | =A0 =A0 =A0 25 |
>> +----------+
>> 1 row in set (3.26 sec)

_______________________________________________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec



--
= Website: http://hallambaker.com/
--f46d0444eccda221d204b3f8c730-- From agl@google.com Tue Dec 13 07:20:25 2011 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 0FF9721F85C7 for ; Tue, 13 Dec 2011 07:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Wu9rcXZLHdg for ; Tue, 13 Dec 2011 07:20:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3F821F84CE for ; Tue, 13 Dec 2011 07:20:24 -0800 (PST) Received: by iaek3 with SMTP id k3so12386480iae.31 for ; Tue, 13 Dec 2011 07:20:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=tlYHsJboqbtny7CTckoUaL860K8uxjngPEcEP2s/36c=; b=rdNIk+0gWTtN2jaqJC6TzaHekHOI8CGwMpoJvGXqMMk52F2P0+Ln3oo6Ppld5eGz9B 9p1h0uwRaQAcoyXnBxPw== Received: by 10.42.19.195 with SMTP id d3mr15750436icb.21.1323789624116; Tue, 13 Dec 2011 07:20:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.19.195 with SMTP id d3mr15750422icb.21.1323789624006; Tue, 13 Dec 2011 07:20:24 -0800 (PST) Received: by 10.231.122.69 with HTTP; Tue, 13 Dec 2011 07:20:23 -0800 (PST) In-Reply-To: References: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.com> Date: Tue, 13 Dec 2011 10:20:23 -0500 Message-ID: From: Adam Langley To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "websec@ietf.org" Subject: Re: [websec] Key pinning for DSA keys with inherited domain params 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, 13 Dec 2011 15:20:25 -0000 On Tue, Dec 13, 2011 at 7:56 AM, Phillip Hallam-Baker wrote: > I don't like a solution for pinning that depends on the CA delivering the > 'right' sort of cert. I would prefer to add in a second hash over the > parameter values or specify them explicitly in the pin or to have the hash > be over what the values would be if completely specified in the Key Info. In the case of ECDSA, it'll be very rare for the parameters to be omitted since they can be compactly represented by a named curve. In fact, I've not seen code in SSL libraries that'll go hunting for EC parameters in a CA key - I strongly suspect that support for this is minimal at best. Therefore I'm happy to simply exclude the possibility in the spec and save the complexity. Cheers AGL From stpeter@stpeter.im Tue Dec 13 08:02:57 2011 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 35B6121F8B13 for ; Tue, 13 Dec 2011 08:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.271 X-Spam-Level: X-Spam-Status: No, score=-103.271 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XELqWQnon7XT for ; Tue, 13 Dec 2011 08:02:54 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BF88421F8B17 for ; Tue, 13 Dec 2011 08:02:54 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0C637423AD; Tue, 13 Dec 2011 09:10:28 -0700 (MST) Message-ID: <4EE771DC.7050600@stpeter.im> Date: Tue, 13 Dec 2011 08:40:12 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Julian Reschke References: <4EE727C4.3020606@gmx.de> In-Reply-To: <4EE727C4.3020606@gmx.de> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] X-Requested-With header field 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, 13 Dec 2011 16:02:57 -0000 On 12/13/11 3:24 AM, Julian Reschke wrote: > it seems this header field is widely implemented. Is it here to stay? If > so, shouldn't it be documented somewhere? +1, even if it does start with that ugly "X-" string. :) From tobias.gondrom@gondrom.org Tue Dec 13 20:58:16 2011 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 4A50411E8080 for ; Tue, 13 Dec 2011 20:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.003 X-Spam-Level: X-Spam-Status: No, score=-96.003 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6YgchaflNcc for ; Tue, 13 Dec 2011 20:58:15 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC9121F84F5 for ; Tue, 13 Dec 2011 20:58:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=s+hv1sNiHRWxXbfCq99KlPyk5FUVVde2fYME/9Ik1nLglmJa1tmy1wz1rfcT2vRF8DJqNV+WuRpKpWFev9W9pKQnPSk/iij2iv3v7N5qb92xNQ5cft6JVRZyij1Yf3l4; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 1828 invoked from network); 14 Dec 2011 05:57:54 +0100 Received: from unknown (HELO ?10.5.8.213?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Dec 2011 05:57:54 +0100 Message-ID: <4EE82CCF.1090606@gondrom.org> Date: Wed, 14 Dec 2011 04:57:51 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: websec@ietf.org References: <4EE727C4.3020606@gmx.de> <4EE771DC.7050600@stpeter.im> In-Reply-To: <4EE771DC.7050600@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] X-Requested-With header field 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, 14 Dec 2011 04:58:16 -0000 Maybe two questions: 1. any volunteers to write this up? 2. is there a coherent documentation of expected use of the header? I looked a bit, but didn't find a good one. Best regards, Tobias On 13/12/11 15:40, Peter Saint-Andre wrote: > On 12/13/11 3:24 AM, Julian Reschke wrote: > >> it seems this header field is widely implemented. Is it here to stay? If >> so, shouldn't it be documented somewhere? > +1, even if it does start with that ugly "X-" string. :) > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Wed Dec 14 21:48:18 2011 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 1CED221F8419 for ; Wed, 14 Dec 2011 21:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.261 X-Spam-Level: X-Spam-Status: No, score=-96.261 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMhZRL4U3qvY for ; Wed, 14 Dec 2011 21:48:17 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id E33C721F8319 for ; Wed, 14 Dec 2011 21:48:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=KZfSYOAxSvNasmNiqENlwOBrbTFmKNikSNiTHHHe62sGVYMnCVQBVgN707ud/9mOK3Cl0v5o5TbJkqy/KSDhcj9PcXvn+mjcIhwTKax2uml0CJh+CMFd1dch0hi6s1Kn; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:Content-Type:Content-Transfer-Encoding; Received: (qmail 13971 invoked from network); 15 Dec 2011 06:48:12 +0100 Received: from unknown (HELO ?10.5.8.213?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Dec 2011 06:48:11 +0100 Message-ID: <4EE98A18.3010101@gondrom.org> Date: Thu, 15 Dec 2011 05:48:08 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] FYI: related drafts on securing TSL and certificates 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, 15 Dec 2011 05:48:18 -0000 Hello, this is only fyi, but possibly noteworthy: recently I came across two other articles aiming at making TLS/SSL more secure: 1. a draft from Ben Laurie and Adam Langley "Certificate Authority Transparency and Auditability" www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf 2. and another proposal from EFF on "Sovereign Keys: A Proposal to Make HTTPS and Email More Secure" https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure To oversimplify, both add some kind of certificate log stored at other sources - though differently. From my perspective this does not conflict with but could complement the current pinning and HSTS approach. Best regards, Tobias From palmer@google.com Thu Dec 15 12:03:38 2011 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 8D1ED21F84F9 for ; Thu, 15 Dec 2011 12:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNiuv9q-s4pb for ; Thu, 15 Dec 2011 12:03:37 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8421221F8557 for ; Thu, 15 Dec 2011 12:03:37 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so3592255wgb.13 for ; Thu, 15 Dec 2011 12:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=J34eZ6jJ4Bp3scr5QUIzdPN79GHKAL5rvAiM9/r/dD4=; b=hqhPezuwXzLHYDAsOSGPtVHVbD6i1D7wujNL510u7pyjw2AT9wE/etBtNRhgI6birX +kXWsKxJQSbuT+T+Pcyg== Received: by 10.227.208.13 with SMTP id ga13mr4434966wbb.4.1323979416611; Thu, 15 Dec 2011 12:03:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.208.13 with SMTP id ga13mr4434946wbb.4.1323979416464; Thu, 15 Dec 2011 12:03:36 -0800 (PST) Received: by 10.216.227.94 with HTTP; Thu, 15 Dec 2011 12:03:36 -0800 (PST) In-Reply-To: <4EE98A18.3010101@gondrom.org> References: <4EE98A18.3010101@gondrom.org> Date: Thu, 15 Dec 2011 12:03:36 -0800 Message-ID: From: Chris Palmer To: Tobias Gondrom X-System-Of-Record: true Content-Type: text/plain; charset=UTF-8 Cc: websec@ietf.org Subject: Re: [websec] FYI: related drafts on securing TSL and certificates 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, 15 Dec 2011 20:03:38 -0000 On Wed, Dec 14, 2011 at 9:48 PM, Tobias Gondrom wrote: > www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf > > https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure > > From my perspective this does not conflict with but could complement the > current pinning and HSTS approach. I have been tangentially involved in the SK proposal (I worked with Peter at EFF), and CT is partly motivated by SK. I *think* I speak for all of us when I say that we regard public key pinning as a useful short-term mitigation, but that some kind of public log system is The Real Solution. I agree there is no conflict, and that the approaches are complementary. Once The Real Solution is in place, we should be able to let go of short-term mitigations like pinning. Whether or not HSTS is "merely" a short-term mitigation that would be superceded by The Real Solution, I don't know. It might well turn out that we will always need to distinguish between "HTTPS is available, and make sure you use the right public keys" and "HTTPS is mandatory, and make sure you use the right public keys". Obviously, HTTPS should be universal, making the available/mandatory distinction meaningless. But until then... From agl@google.com Thu Dec 15 12:13:36 2011 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 5819821F8483 for ; Thu, 15 Dec 2011 12:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7j86HdKIjNm for ; Thu, 15 Dec 2011 12:13:35 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF02521F8481 for ; Thu, 15 Dec 2011 12:13:35 -0800 (PST) Received: by ghrr16 with SMTP id r16so2162473ghr.31 for ; Thu, 15 Dec 2011 12:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=ZTd4yf0vmBuH+WVsh6cZkstsqQM2R7KtlbBz2Gf4fRQ=; b=PU0aGWRt0BmWxblQzw0uuFURKtHdk1X4KuO5Yg8AB7kd9waK2kfjbb+bQprOEeK7HI yT5K0RpG3KxiL/zstKOA== Received: by 10.50.208.72 with SMTP id mc8mr4169626igc.19.1323980013535; Thu, 15 Dec 2011 12:13:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.208.72 with SMTP id mc8mr4169621igc.19.1323980013448; Thu, 15 Dec 2011 12:13:33 -0800 (PST) Received: by 10.231.122.69 with HTTP; Thu, 15 Dec 2011 12:13:33 -0800 (PST) In-Reply-To: References: <4EE98A18.3010101@gondrom.org> Date: Thu, 15 Dec 2011 15:13:33 -0500 Message-ID: From: Adam Langley To: Chris Palmer X-System-Of-Record: true Content-Type: text/plain; charset=UTF-8 Cc: websec@ietf.org Subject: Re: [websec] FYI: related drafts on securing TSL and certificates 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, 15 Dec 2011 20:13:36 -0000 On Thu, Dec 15, 2011 at 3:03 PM, Chris Palmer wrote: > I *think* I speak for > all of us when I say that we regard public key pinning as a useful > short-term mitigation, but that some kind of public log system is The > Real Solution. I don't believe that there is any conflict between HSTS, pinning and Certificate Transparency. Cheers AGL From hallam@gmail.com Fri Dec 16 05:22:19 2011 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 E9D0D21F8B43 for ; Fri, 16 Dec 2011 05:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nFwbcedqSwJ for ; Fri, 16 Dec 2011 05:22:19 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00E1D21F8B76 for ; Fri, 16 Dec 2011 05:22:18 -0800 (PST) Received: by ggnk5 with SMTP id k5so3093577ggn.31 for ; Fri, 16 Dec 2011 05:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wfbp8SgcQYxnEYPSRGgcRWPE68RHmVbvxVoG8ln90c0=; b=r6GkL0myuW3VktD7o4F2NEhZNiiRKGMH/tGAIlr1EzelpJ0+OFVop8uNAsR6MZKCQl gtHfQU5U7XuT/b20S5KnObTlUqJCcBzk6e9v3iMzFkv6NPeqjBZiJUBti4f5eehHhDf2 KLntQ0SfGE3M2tMCYCvG350L+Efs0PtJkvouc= MIME-Version: 1.0 Received: by 10.182.144.69 with SMTP id sk5mr3461608obb.27.1324041738546; Fri, 16 Dec 2011 05:22:18 -0800 (PST) Received: by 10.182.160.72 with HTTP; Fri, 16 Dec 2011 05:22:18 -0800 (PST) In-Reply-To: References: <76E2AAC7-2070-4C98-B0EE-08BE5D2B0CB9@team.telstra.com> Date: Fri, 16 Dec 2011 08:22:18 -0500 Message-ID: From: Phillip Hallam-Baker To: Adam Langley Content-Type: multipart/alternative; boundary=14dae93996717e6c3e04b4357d09 Cc: "websec@ietf.org" Subject: Re: [websec] Key pinning for DSA keys with inherited domain params 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, 16 Dec 2011 13:22:20 -0000 --14dae93996717e6c3e04b4357d09 Content-Type: text/plain; charset=ISO-8859-1 Actually, the inheritance mechanism should probably be prohibited altogether. As things stand it allows a CA to poison a cert issued by another CA! Let us imagine CA X issues a cert for Alice, the chain is X -> XI -> A. Now imagine that CA Y issues a cross cert for XI, we now have a chain Y-> XI -> A The parameters for the key now depend on the path! Yuk! I don't know if there is a practical attack possible , this just occurred to me. But even if there is no attack there is potential for error. [The sort of attack I am thinking of is a kleptography like attack when country A sells sabotaged crypto equipment to country B. Country B may verify that only certs issued through the sub CA XI they control are used but this gives a way to defeat that control.] On Tue, Dec 13, 2011 at 10:20 AM, Adam Langley wrote: > On Tue, Dec 13, 2011 at 7:56 AM, Phillip Hallam-Baker > wrote: > > I don't like a solution for pinning that depends on the CA delivering the > > 'right' sort of cert. I would prefer to add in a second hash over the > > parameter values or specify them explicitly in the pin or to have the > hash > > be over what the values would be if completely specified in the Key Info. > > In the case of ECDSA, it'll be very rare for the parameters to be > omitted since they can be compactly represented by a named curve. In > fact, I've not seen code in SSL libraries that'll go hunting for EC > parameters in a CA key - I strongly suspect that support for this is > minimal at best. > > Therefore I'm happy to simply exclude the possibility in the spec and > save the complexity. > > > Cheers > > AGL > -- Website: http://hallambaker.com/ --14dae93996717e6c3e04b4357d09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually, the inheritance mechanism should probably be prohibited altogethe= r.

As things stand it allows a CA to poison a cert issue= d by another CA!

Let us imagine CA X issues a cert= for Alice, the chain is X -> XI -> A. Now imagine that CA Y issues a= cross cert for XI, we now have a chain Y-> XI -> A

The parameters for the key now depend on the path! Yuk!=


I don't know if there is a pra= ctical attack possible , this just occurred to me. But even if there is no = attack there is potential for error.

[The sort of attack I am thinking of is a kleptography like attack when= country A sells sabotaged crypto equipment to country B. Country B may ver= ify that only certs issued through the sub CA XI they control are used but = this gives a way to defeat that control.]
=A0

On Tue, Dec 13, 2011 at 10:20 AM, Ada= m Langley <agl@googl= e.com> wrote:
On Tue, Dec 13, 2011 at 7:56 AM, Phillip Hallam-Baker <= ;hallam@gmail.com> wrote:
> I don't like a solution for pinning that depends on the CA deliver= ing the
> 'right' sort of cert. I would prefer to add in a second hash o= ver the
> parameter values or specify them explicitly in the pin or to have the = hash
> be over what the values would be if completely specified in the Key In= fo.

In the case of ECDSA, it'll be very rare for the parameters to be=
omitted since they can be compactly represented by a named curve. In
fact, I've not seen code in SSL libraries that'll go hunting for EC=
parameters in a CA key - I strongly suspect that support for this is
minimal at best.

Therefore I'm happy to simply exclude the possibility in the spec and save the complexity.


Cheers

AGL



--
Website: http://hallambaker.com/

--14dae93996717e6c3e04b4357d09-- From alexey.melnikov@isode.com Sat Dec 17 11:57:50 2011 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 47FA421F8B20 for ; Sat, 17 Dec 2011 11:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB6qXVXCQ6hr for ; Sat, 17 Dec 2011 11:57:49 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 60BF821F8B1E for ; Sat, 17 Dec 2011 11:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1324151862; d=isode.com; s=selector; i=@isode.com; bh=T1/ULeXylrn9I4p+coOCzlMSMuWWz2dJLwQAf6qCyhM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OHUgRmYkRtH5ySvqKb+Z/idbwAPlCnLWbRe8Bc3bDq1Zeue4BYOChEK2GATWC6lsRreXNN WF/5TexXjxSo8/nfP0+LY7wUpDpLKC7JI2PzstNi6drodzGGfWhEzN96B0ZwZmpEZoetkK Dw7VALmYTXDZ69/E1U3vF1Yp5+FylEo=; Received: from [188.28.202.132] (188.28.202.132.threembb.co.uk [188.28.202.132]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 17 Dec 2011 19:57:42 +0000 Message-ID: <4EECF43E.6000105@isode.com> Date: Sat, 17 Dec 2011 19:57:50 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: websec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Minutes for the WebSec meeting in Taipei 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, 17 Dec 2011 19:57:50 -0000 Sorry for delay, I now uploaded minutes from Taipei: Big thank you to Klaas Wierenga for being the scribe. Please send your corrections before January 5th to the mailing list (or directly to WG chairs). From Jeff.Hodges@KingsMountain.com Thu Dec 22 22:06:31 2011 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 3876921F8A55 for ; Thu, 22 Dec 2011 22:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAKvdaJqCTz1 for ; Thu, 22 Dec 2011 22:06:30 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id E487E21F8A4E for ; Thu, 22 Dec 2011 22:06:26 -0800 (PST) Received: (qmail 29589 invoked by uid 0); 23 Dec 2011 06:06:05 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 23 Dec 2011 06:06:05 -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=wpf31BD1SO4FZdhXtciQ4ejumiH64jWU1rpLz9gEjpw=; b=p901ojZj3/kQnmuToYEZPNwpdkO0QZYv029n4rFWjvt8U6u/T5wubu8VpAaGlrYJIdPEH1PNoOfz0ExB7IjfQr4vlxLp3eL3SY7S1wU0rNF1Pfdl472x4ELytAuJpxbc; Received: from 168-215-210-150.static.twtelecom.net ([168.215.210.150] helo=[10.0.1.113]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RdyGa-0002d6-FG; Thu, 22 Dec 2011 23:06:04 -0700 Message-ID: <4EF41A5A.2080109@KingsMountain.com> Date: Thu, 22 Dec 2011 22:06:18 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Pete Resnick , Paul Hoffman 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 168.215.210.150 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec 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, 23 Dec 2011 06:06:31 -0000 PaulH and PeteR raised some concerns in Taipei over the IDNA-related language in draft-ietf-websec-strict-transport-sec. This message is a reminder to them and an instigator to others for further review specifically of the IDN aspects of the HSTS spec. My initial request for review and summation of the pertinent language, as sent to the na-update@ list, is here (and attached below).. IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec http://www.alvestrand.no/pipermail/idna-update/2011-September/007140.html The above-cited message presaged the -03 HSTS draft, which is presently (for a little while) current, and is here.. HTTP Strict Transport Security (HSTS) Please review and comment. Thanks, =JeffH ------ From: =JeffH Date: Thu, 29 Sep 2011 20:07:15 -0700 To: IETF IDNA Update WG Cc: Pete Resnick , websec-chairs@tools.ietf.org, Peter Saint-Andre , Adam Barth Hi, In working towards completion of.. HTTP Strict Transport Security (HSTS) ..and.. The Web Origin Concept https://tools.ietf.org/html/draft-ietf-websec-origin ..we are attempting to address the proper way to reference IDNA2008 and IDNA2003 in terms of stipulating comparisons of domain names (that may or may not be IDNs). In discussions with our ADs and a few IDNA-literate folks, we've been informed that the IDNA-specific language in the recently-released RFC6265 HTTP State Management spec isn't quite up to the standards they would like to see at this time. Thus I've performed some surgery on draft-ietf-websec-strict-transport-sec and have included below the specific section portions that are IDNA specific (this is from my working copy which isn't quite yet overall ready tonight to submit as -03). The key context to keep in mind when reviewing the below is that the key "processing" -- essentially a domain name comparison -- will occur deep within the bowels of HTTP clients, well along the processing pipeline for URIs, and presumably after IDNA-canonicalization and requisite validation/testing has occurred. However, the guidance we've received is that given the complexities and subtleties of IDNA processing and considerations, our specs really should be more explicit about the foregoing assumption(s) and the downside risks if the requisite validation/testing is not performed. With that context in mind, thoughts on the below are solicited. Apologies for just having these excerpts at this time, but I ought to have -websec-strict-transport-sec-03 submitted in the next few days at most. thanks, =JeffH . . . 7. User Agent Processing Model This section describes the HTTP Strict Transport Security processing model for UAs. There are several facets to the model, enumerated by the following subsections. This processing model assumes that the UA implements IDNA2008 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 11 "Internationalized Domain Names for Applications (IDNA): Dependency and Migration". It also assumes that all domain names manipulated in this specification's context are already IDNA-canonicalized as outlined in Section 8 "Domain Name IDNA-Canonicalization" prior to the processing specified in this section. The above assumptions mean that this processing model also specifically assumes that appropriate IDNA and Unicode validations and character list testing have occured on the domain names, in conjunction with their IDNA-canonicalization, prior to the processing specified in this section. See the IDNA-specific security considerations in Section 13.2 "Internationalized Domain Names" for rationale and further details. . . . 8. Domain Name IDNA-Canonicalization An IDNA-canonicalized domain name is the string generated by the following algorithm, whose input must be a valid Unicode-encoded (in NFC form [Unicode6]) string-serialized domain name: 1. Convert the domain name to a sequence of individual domain name label strings. 2. When implementing IDNA2008, convert each label that is not a Non- Reserved LDH (NR-LDH) label, to an A-label. See Section 2.3.2 of [RFC5890] for definitions of the former and latter, refer to Sections 5.3 through 5.5 of [RFC5891] for the conversion algorithm and requisite input validation and character list testing procedures. Otherwise, when implementing IDNA2003, convert each label using the "ToASCII" conversion in Section 4 of [RFC3490] (see also the definition of "equivalence of labels" in Section 2 of the latter specification). 3. Concatenate the resulting labels, separating each label from the next with (".") a %x2E character. See also Section 11 "Internationalized Domain Names for Applications (IDNA): Dependency and Migration" and Section 13.2 "Internationalized Domain Names" of this specification for further details and considerations. . . . 11. Internationalized Domain Names for Applications (IDNA): Dependency and Migration Textual domain names on the modern Internet may contain one or more "internationalized" domain name labels. Such domain names are referred to as "internationalized domain names" (IDNs). The specification suites defining IDNs and the protocols for their use are named "Internationalized Domain Names for Applications (IDNA)". At this time, there are two such specification suites: IDNA2008 [RFC5890] and its predecessor IDNA2003 [RFC3490]. IDNA2008 obsoletes IDNA2003, but there are differences between the two specifications, and thus there can be differences in processing (e.g. converting) domain name labels that have been registered under one from those registered under the other. There will be a transition period of some time during which IDNA2003-based domain name labels will exist in the wild. User agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003. . . . 13. Security Considerations . . . 13.2. Internationalized Domain Names Internet security relies in part on the DNS and the domain names it hosts. Domain names are used by users to identify and connect to Internet hosts and other network resources. For example, Internet security is compromised if a user entering an internationalized domain name (IDN) is connected to different hosts based on different interpretations of the IDN. The processing models specified in this specification assume that the domain names they manipulate are IDNA-canonicalized, and that the canonicalization process correctly performed all appropriate IDNA and Unicode validations and character list testing per the requisite specifications (e.g., as noted in Section 8 "Domain Name IDNA- Canonicalization"). These steps are necessary in order to avoid various potentially compromising situations. In brief, some examples of issues that could stem from lack of careful and consistent Unicode and IDNA validations are things such as unexpected processing exceptions, truncation errors, and buffer overflows, as well as false-positive and/or false-negative domain name matching results. Any of the foregoing issues could possibly be leveraged by attackers in various ways. Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in terms of disallowed characters and character mapping conventions. This situation can also lead to false-positive and/or false-negative domain name matching results, resulting in, for example, users possibly communicating with unintended hosts, or not being able to reach intended hosts. For details, refer to the Security Considerations sections of [RFC5890], [RFC5891], and [RFC3490], as well as the specifications they normatively reference. Additionally, [RFC5894] provides detailed background and rationale for IDNA2008 in particular, as well as IDNA and its issues in general, and should be consulted in conjunction with the former specifications. 13.3. Denial of Service (DoS) . . . --- end From trac+websec@trac.tools.ietf.org Wed Dec 28 14:47:25 2011 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 E6DA221F84B3 for ; Wed, 28 Dec 2011 14:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11B84dznffBS for ; Wed, 28 Dec 2011 14:47:25 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 63FD621F84B2 for ; Wed, 28 Dec 2011 14:47:25 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rg2Gs-0004F1-0l; Wed, 28 Dec 2011 17:46:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Wed, 28 Dec 2011 22:46:53 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/32 Message-ID: <070.b5e0cfa5b3a6fe7add2652f951e3143f@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111228224725.63FD621F84B2@ietfa.amsl.com> Resent-Date: Wed, 28 Dec 2011 14:47:25 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #32: HSTS: explain some practical implications of includeSubDomains directive 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: Wed, 28 Dec 2011 22:47:26 -0000 #32: HSTS: explain some practical implications of includeSubDomains directive the includeSubDomains directive has some practical implications -- for example, if a HSTS host offers http-based services on various ports, then they will all have to be TLS/SSL-based in order to work properly. For example, certification authorities often offer their CRL distribution and OCSP services over plain HTTP, and sometimes at a subdomain of a publicly-available web application which may be secured by TLS/SSL. E.g. https://example-ca.com/ is a publicly-available web application for "Example CA", a certification authority. Customers use this web application to register their public keys and obtain certificates. Example CA generates certificates for customers containing as the value for the "CRL Distribution Points" and "Authority Information Access:OCSP" certificate fields. If example-ca.com were to issue an HSTS Policy with the includeSubDomains directive, then HTTP-based user agents implementing HSTS, and that have interacted with the example-ca.com web application, would fail to retrieve CRLs and fail to check OCSP for certificates because these services are offered over plain HTTP. In this case, Example CA can either.. * not use the includeSubDomains directive, or, * ensure HTTP-based services offered at subdomains of example-ca.com are uniformly offered over TLS/SSL, or, * offer plain HTTP-based services at a different domain name, e.g. example-ca-services.net. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: websec From julian.reschke@gmx.de Thu Dec 29 04:39:34 2011 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 5C46C21F858D for ; Thu, 29 Dec 2011 04:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7RYH60rcwuJ for ; Thu, 29 Dec 2011 04:39:33 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4CC3321F84A6 for ; Thu, 29 Dec 2011 04:39:33 -0800 (PST) Received: (qmail invoked by alias); 29 Dec 2011 12:39:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 29 Dec 2011 13:39:31 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+O6AYOfuOO+JShqCoZ0doZBJJPNBdm0D67onxtJZ hzVKFK2sishgZY Message-ID: <4EFC5F7B.7050304@gmx.de> Date: Thu, 29 Dec 2011 13:39:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =JeffH References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> In-Reply-To: <4EABB25E.9000900@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 29 Dec 2011 12:39:34 -0000 Hi there, Looking at . I note that the spec doesn't state what ABNF syntax it uses; something like should be added. Now for the actual ABNF (): Strict-Transport-Security = "Strict-Transport-Security" ":" directive *( ";" [ directive ] ) This works for me. directive = max-age | includeSubDomains | STS-d-ext max-age = "max-age" "=" delta-seconds includeSubDomains = "includeSubDomains" STS-d-ext = token [ "=" ( token | quoted-string ) ] I would turn that around; a parser for STS should parse all directives the same way, thus: directive = token [ "=" ( token | quoted-string ) ] And then state that this spec defines two directives, and future specs can define more (maybe you need to state how to do that; "update" this spec? Add registry?) Then, for max-age and includeSubDomains, define their individual syntax separately, and don't forget to describe what to do with things like: includeSubDomains="true" or max-age or max-age="10" Also: The max-age directive MUST appear once in the Strict-Transport- Security header field value. The includeSubDomains directive MAY appear once. The order of appearance of directives in the Strict- Transport-Security header field value is not significant. It would be better to state that *each* directive (including future ones) must appear only once, and that max-age is REQUIRED and includeSubDomains is OPTIONAL. (BTW: wouldn't it make sense to have a default for max-age so it can be made OPTIONAL?) Best regards, Julian From julian.reschke@gmx.de Thu Dec 29 04:58:02 2011 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 E064521F854D for ; Thu, 29 Dec 2011 04:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.832 X-Spam-Level: X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5pKnL3GyFaD for ; Thu, 29 Dec 2011 04:58:02 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5C27321F852E for ; Thu, 29 Dec 2011 04:58:01 -0800 (PST) Received: (qmail invoked by alias); 29 Dec 2011 12:57:59 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp005) with SMTP; 29 Dec 2011 13:57:59 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/D+MVy4qLDGIzrFf0DgdicmvwVWe08IZdYTAbHIV OEcfznVTBZU/TC Message-ID: <4EFC63D3.6000903@gmx.de> Date: Thu, 29 Dec 2011 13:57:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.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] draft-ietf-websec-strict-transport-sec-03 reference nits 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, 29 Dec 2011 12:58:03 -0000 Hi there, checking with : Normative References: RFC1035: [STANDARD] (-> STD0013) ok RFC1594: [INFORMATIONAL] obsoleted by RFC2664 -> Should be updated. RFC1983: [INFORMATIONAL] (-> FYI0018) ok RFC2109: [HISTORIC] obsoleted by RFC2965 -> Should be replaced by RFC 6265 RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok RFC2560: [PROPOSED STANDARD] ok RFC2616: [DRAFT STANDARD] ok RFC2818: [INFORMATIONAL] ok RFC2965: [HISTORIC] obsoleted by RFC6265 -> Should either be removed or moved to Informational References. RFC3454: [PROPOSED STANDARD] ok RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891 RFC3492: [PROPOSED STANDARD] ok RFC3864: [BEST CURRENT PRACTICE] (-> BCP0090) ok RFC3986: [STANDARD] (-> STD0066) ok RFC4346: [PROPOSED STANDARD] obsoleted by RFC5246 -> is the ref to 1.1 intentional? In this case the reference should be annotated, I guess. RFC4949: [INFORMATIONAL] (-> FYI0036) ok RFC5280: [PROPOSED STANDARD] ok RFC5890: [PROPOSED STANDARD] ok RFC5891: [PROPOSED STANDARD] ok RFC5894: [INFORMATIONAL] ok RFC5895: [INFORMATIONAL] ok Unicode6: not checked WD-html5-20100304: document unknown -> Also, not used. Informative References: Aircrack-ng: not checked BeckTews09: not checked Firesheep: not checked ForceHTTPS: not checked GoodDhamijaEtAl05: not checked draft-ietf-tls-ssl-version3: ID does not exist -> please add "-00" to the seriesInfo/@value. JacksonBarth2008: not checked owaspTLSGuide: not checked RFC0793: [STANDARD] (-> STD0007) ok RFC2396: [DRAFT STANDARD] obsoleted by RFC3986 -> not used in the spec SunshineEgelmanEtAl09: not checked UTS46: not checked WD-wsc-ui-20100309: document unknown -> recommended ref: Web Security Context: User Interface Guidelines Latest version available at . WEBSEC: not checked Best regards, Julian From ietf@adambarth.com Thu Dec 29 11:50:57 2011 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 65A7721F8B81 for ; Thu, 29 Dec 2011 11:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOw-eabUT7K2 for ; Thu, 29 Dec 2011 11:50:54 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFF2321F8B80 for ; Thu, 29 Dec 2011 11:50:53 -0800 (PST) Received: by iabz21 with SMTP id z21so2249763iab.31 for ; Thu, 29 Dec 2011 11:50:53 -0800 (PST) Received: by 10.42.155.136 with SMTP id u8mr25734232icw.12.1325188251597; Thu, 29 Dec 2011 11:50:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id gf6sm80922577igb.1.2011.12.29.11.50.49 (version=SSLv3 cipher=OTHER); Thu, 29 Dec 2011 11:50:49 -0800 (PST) Received: by iabz21 with SMTP id z21so2249678iab.31 for ; Thu, 29 Dec 2011 11:50:49 -0800 (PST) Received: by 10.42.148.1 with SMTP id p1mr583633icv.27.1325188249085; Thu, 29 Dec 2011 11:50:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Thu, 29 Dec 2011 11:50:18 -0800 (PST) In-Reply-To: <4EFC5F7B.7050304@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> From: Adam Barth Date: Thu, 29 Dec 2011 11:50:18 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 29 Dec 2011 19:50:57 -0000 On Thu, Dec 29, 2011 at 4:39 AM, Julian Reschke wro= te: > Hi there, > > Looking at > . > > I note that the spec doesn't state what ABNF syntax it uses; something li= ke > should = be > added. > > Now for the actual ABNF > (): > > > =A0 =A0Strict-Transport-Security =3D "Strict-Transport-Security" ":" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0di= rective *( ";" [ directive ] ) > > This works for me. > > > =A0 =A0directive =A0 =A0 =A0 =A0 =3D max-age | includeSubDomains | STS-d-= ext > > =A0 =A0max-age =A0 =A0 =A0 =A0 =A0 =3D "max-age" "=3D" delta-seconds > > =A0 =A0includeSubDomains =3D "includeSubDomains" > > > =A0 =A0STS-d-ext =A0 =A0 =3D token [ "=3D" ( token | quoted-string ) ] > > I would turn that around; a parser for STS should parse all directives th= e > same way, thus: > > =A0 =A0directive =A0 =A0 =A0 =A0 =3D token [ "=3D" ( token | quoted-strin= g ) ] As I wrote before, I don't think we should include quoted-string in the grammar. As far as I know, no one has implemented it and I have no plans to implement quoted-string in Chrome. Having quoted-string in the grammar only leads to pain., Adam > And then state that this spec defines two directives, and future specs ca= n > define more (maybe you need to state how to do that; "update" this spec? = Add > registry?) > > Then, for max-age and includeSubDomains, define their individual syntax > separately, and don't forget to describe what to do with things like: > > =A0includeSubDomains=3D"true" > > or > > =A0max-age > > or > > =A0max-age=3D"10" > > Also: > > =A0 The max-age directive MUST appear once in the Strict-Transport- > =A0 Security header field value. =A0The includeSubDomains directive MAY > > =A0 appear once. =A0The order of appearance of directives in the Strict- > =A0 Transport-Security header field value is not significant. > > It would be better to state that *each* directive (including future ones) > must appear only once, and that max-age is REQUIRED and includeSubDomains= is > OPTIONAL. > > (BTW: wouldn't it make sense to have a default for max-age so it can be m= ade > OPTIONAL?) > > > Best regards, Julian > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From julian.reschke@gmx.de Thu Dec 29 13:13:13 2011 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 ED89921F8B61 for ; Thu, 29 Dec 2011 13:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUhyuaqM3BJf for ; Thu, 29 Dec 2011 13:13:13 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 249E621F8A70 for ; Thu, 29 Dec 2011 13:13:12 -0800 (PST) Received: (qmail invoked by alias); 29 Dec 2011 21:13:12 -0000 Received: from p3EE2751C.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.28] by mail.gmx.net (mp069) with SMTP; 29 Dec 2011 22:13:12 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+fCgEO5y6fmv+DUY7LLV56QKqY+iTQpjll2gLdrg 2JOKmxNzsd2cvR Message-ID: <4EFCD7E4.5060507@gmx.de> Date: Thu, 29 Dec 2011 22:13:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 29 Dec 2011 21:13:14 -0000 On 2011-12-29 20:50, Adam Barth wrote: > ..- > As I wrote before, I don't think we should include quoted-string in > the grammar. As far as I know, no one has implemented it and I have > no plans to implement quoted-string in Chrome. Having quoted-string > in the grammar only leads to pain., It would be helpful if you were more precise on the pain it causes, considering you need to process extension directives anyway... From ietf@adambarth.com Thu Dec 29 13:19:04 2011 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 3040D21F8B8D for ; Thu, 29 Dec 2011 13:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmJ+ToowmK5R for ; Thu, 29 Dec 2011 13:19:03 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C77121F8B87 for ; Thu, 29 Dec 2011 13:19:03 -0800 (PST) Received: by obcuz6 with SMTP id uz6so11107990obc.31 for ; Thu, 29 Dec 2011 13:19:03 -0800 (PST) Received: by 10.50.88.170 with SMTP id bh10mr42865583igb.8.1325193543110; Thu, 29 Dec 2011 13:19:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id l28sm119040450ibc.3.2011.12.29.13.19.01 (version=SSLv3 cipher=OTHER); Thu, 29 Dec 2011 13:19:01 -0800 (PST) Received: by iabz21 with SMTP id z21so2352682iab.31 for ; Thu, 29 Dec 2011 13:19:01 -0800 (PST) Received: by 10.42.148.1 with SMTP id p1mr827749icv.27.1325193541120; Thu, 29 Dec 2011 13:19:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Thu, 29 Dec 2011 13:18:31 -0800 (PST) In-Reply-To: <4EFCD7E4.5060507@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> From: Adam Barth Date: Thu, 29 Dec 2011 13:18:31 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 29 Dec 2011 21:19:04 -0000 On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke wro= te: > On 2011-12-29 20:50, Adam Barth wrote: >> ..- > >> As I wrote before, I don't think we should include quoted-string in >> the grammar. =A0As far as I know, no one has implemented it and I have >> no plans to implement quoted-string in Chrome. =A0Having quoted-string >> in the grammar only leads to pain., > > It would be helpful if you were more precise on the pain it causes, > considering you need to process extension directives anyway... We've been over this several times before. The problem is the requirement to balance DQUOTE and the complexities surrounding the error conditions if the DQUOTEs don't balance properly (including escaping). Adam From julian.reschke@gmx.de Thu Dec 29 13:24:49 2011 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 E5FE521F8B9D for ; Thu, 29 Dec 2011 13:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.908 X-Spam-Level: X-Spam-Status: No, score=-103.908 tagged_above=-999 required=5 tests=[AWL=-1.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9sGi0pqRhsw for ; Thu, 29 Dec 2011 13:24:49 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0D83E21F8B9B for ; Thu, 29 Dec 2011 13:24:48 -0800 (PST) Received: (qmail invoked by alias); 29 Dec 2011 21:24:47 -0000 Received: from p3EE2751C.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.28] by mail.gmx.net (mp011) with SMTP; 29 Dec 2011 22:24:47 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/6z/4jSn76bwJMvbBJWO/hIbTkLuWom5PQpa0n72 ZFaqvsmApu8MIJ Message-ID: <4EFCDA9C.90308@gmx.de> Date: Thu, 29 Dec 2011 22:24:44 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 29 Dec 2011 21:24:50 -0000 On 2011-12-29 22:18, Adam Barth wrote: > On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke wrote: >> On 2011-12-29 20:50, Adam Barth wrote: >>> ..- >> >>> As I wrote before, I don't think we should include quoted-string in >>> the grammar. As far as I know, no one has implemented it and I have >>> no plans to implement quoted-string in Chrome. Having quoted-string >>> in the grammar only leads to pain., >> >> It would be helpful if you were more precise on the pain it causes, >> considering you need to process extension directives anyway... > > We've been over this several times before. The problem is the > requirement to balance DQUOTE and the complexities surrounding the > error conditions if the DQUOTEs don't balance properly (including > escaping). Yes, but you are avoiding the question I asked. Are you implementing quoted-string for extension parameters? From ietf@adambarth.com Thu Dec 29 13:32:41 2011 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 40CCC21F8BA6 for ; Thu, 29 Dec 2011 13:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF+7JZIc7dc2 for ; Thu, 29 Dec 2011 13:32:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC02521F8B79 for ; Thu, 29 Dec 2011 13:32:40 -0800 (PST) Received: by iabz21 with SMTP id z21so2369065iab.31 for ; Thu, 29 Dec 2011 13:32:40 -0800 (PST) Received: by 10.50.190.196 with SMTP id gs4mr43492419igc.14.1325194360348; Thu, 29 Dec 2011 13:32:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id j3sm119179496ibj.1.2011.12.29.13.32.39 (version=SSLv3 cipher=OTHER); Thu, 29 Dec 2011 13:32:39 -0800 (PST) Received: by iabz21 with SMTP id z21so2369049iab.31 for ; Thu, 29 Dec 2011 13:32:39 -0800 (PST) Received: by 10.50.6.233 with SMTP id e9mr43084453iga.17.1325194359103; Thu, 29 Dec 2011 13:32:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Thu, 29 Dec 2011 13:32:09 -0800 (PST) In-Reply-To: <4EFCDA9C.90308@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> From: Adam Barth Date: Thu, 29 Dec 2011 13:32:09 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 29 Dec 2011 21:32:41 -0000 On Thu, Dec 29, 2011 at 1:24 PM, Julian Reschke wro= te: > On 2011-12-29 22:18, Adam Barth wrote: >> On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke >> =A0wrote: >>> On 2011-12-29 20:50, Adam Barth wrote: >>>> As I wrote before, I don't think we should include quoted-string in >>>> the grammar. =A0As far as I know, no one has implemented it and I have >>>> no plans to implement quoted-string in Chrome. =A0Having quoted-string >>>> in the grammar only leads to pain., >>> >>> It would be helpful if you were more precise on the pain it causes, >>> considering you need to process extension directives anyway... >> >> We've been over this several times before. =A0The problem is the >> requirement to balance DQUOTE and the complexities surrounding the >> error conditions if the DQUOTEs don't balance properly (including >> escaping). > > Yes, but you are avoiding the question I asked. Are you implementing > quoted-string for extension parameters? No. Here's the grammar I recommend: Strict-Transport-Security =3D "Strict-Transport-Security" ":" directive *( ";" [ directive ] ) directive =3D max-age | includeSubDomains | STS-d-ext max-age =3D "max-age" "=3D" delta-seconds includeSubDomains =3D "includeSubDomains" STS-d-ext =3D token [ "=3D" token ] I would also define the precise requirements for parsing all possible input sequences, but I understand that's not fashionable. Adam From julian.reschke@gmx.de Thu Dec 29 13:38:35 2011 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 D5A1221F8BB0 for ; Thu, 29 Dec 2011 13:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fJviykxy3SG for ; Thu, 29 Dec 2011 13:38:35 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E43D121F8BA7 for ; Thu, 29 Dec 2011 13:38:34 -0800 (PST) Received: (qmail invoked by alias); 29 Dec 2011 21:38:33 -0000 Received: from p3EE2751C.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.28] by mail.gmx.net (mp021) with SMTP; 29 Dec 2011 22:38:33 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+tZYFBTF6tBWu7bDyt7QwhZdYF7Sr+F+JiOaPP9t gFIjXA4uRnGASF Message-ID: <4EFCDDD5.6040005@gmx.de> Date: Thu, 29 Dec 2011 22:38:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 29 Dec 2011 21:38:36 -0000 On 2011-12-29 22:32, Adam Barth wrote: > On Thu, Dec 29, 2011 at 1:24 PM, Julian Reschke wrote: >> On 2011-12-29 22:18, Adam Barth wrote: >>> On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke >>> wrote: >>>> On 2011-12-29 20:50, Adam Barth wrote: >>>>> As I wrote before, I don't think we should include quoted-string in >>>>> the grammar. As far as I know, no one has implemented it and I have >>>>> no plans to implement quoted-string in Chrome. Having quoted-string >>>>> in the grammar only leads to pain., >>>> >>>> It would be helpful if you were more precise on the pain it causes, >>>> considering you need to process extension directives anyway... >>> >>> We've been over this several times before. The problem is the >>> requirement to balance DQUOTE and the complexities surrounding the >>> error conditions if the DQUOTEs don't balance properly (including >>> escaping). >> >> Yes, but you are avoiding the question I asked. Are you implementing >> quoted-string for extension parameters? > > No. > > Here's the grammar I recommend: > > Strict-Transport-Security = "Strict-Transport-Security" ":" > directive *( ";" [ directive ] ) > > directive = max-age | includeSubDomains | STS-d-ext > max-age = "max-age" "=" delta-seconds > includeSubDomains = "includeSubDomains" > STS-d-ext = token [ "=" token ] > > I would also define the precise requirements for parsing all possible > input sequences, but I understand that's not fashionable. Ack. This is at least consistent. That being said, I disagree. token=quoted-string is widely implemented, and if there are clients not getting it right we should fix them. If you are aware of specific clients having this problem please list them so we can open bug reports. Best regards, Julian From ietf@adambarth.com Thu Dec 29 13:45:36 2011 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 4012721F8BB2 for ; Thu, 29 Dec 2011 13:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lslGrgr3cMVB for ; Thu, 29 Dec 2011 13:45:35 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B521F8BB0 for ; Thu, 29 Dec 2011 13:45:35 -0800 (PST) Received: by ggnk5 with SMTP id k5so9795790ggn.31 for ; Thu, 29 Dec 2011 13:45:35 -0800 (PST) Received: by 10.236.148.235 with SMTP id v71mr50298756yhj.6.1325195135326; Thu, 29 Dec 2011 13:45:35 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id 9sm87304237any.3.2011.12.29.13.45.34 (version=SSLv3 cipher=OTHER); Thu, 29 Dec 2011 13:45:34 -0800 (PST) Received: by obcuz6 with SMTP id uz6so11132088obc.31 for ; Thu, 29 Dec 2011 13:45:34 -0800 (PST) Received: by 10.50.191.225 with SMTP id hb1mr43073763igc.17.1325195134121; Thu, 29 Dec 2011 13:45:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Thu, 29 Dec 2011 13:45:03 -0800 (PST) In-Reply-To: <4EFCDDD5.6040005@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> From: Adam Barth Date: Thu, 29 Dec 2011 13:45:03 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 29 Dec 2011 21:45:36 -0000 On Thu, Dec 29, 2011 at 1:38 PM, Julian Reschke wro= te: > On 2011-12-29 22:32, Adam Barth wrote: >> >> On Thu, Dec 29, 2011 at 1:24 PM, Julian Reschke >> =A0wrote: >>> >>> On 2011-12-29 22:18, Adam Barth wrote: >>>> >>>> On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke >>>> =A0wrote: >>>>> >>>>> On 2011-12-29 20:50, Adam Barth wrote: >>>>>> >>>>>> As I wrote before, I don't think we should include quoted-string in >>>>>> the grammar. =A0As far as I know, no one has implemented it and I ha= ve >>>>>> no plans to implement quoted-string in Chrome. =A0Having quoted-stri= ng >>>>>> in the grammar only leads to pain., >>>>> >>>>> >>>>> It would be helpful if you were more precise on the pain it causes, >>>>> considering you need to process extension directives anyway... >>>> >>>> >>>> We've been over this several times before. =A0The problem is the >>>> requirement to balance DQUOTE and the complexities surrounding the >>>> error conditions if the DQUOTEs don't balance properly (including >>>> escaping). >>> >>> >>> Yes, but you are avoiding the question I asked. Are you implementing >>> quoted-string for extension parameters? >> >> >> No. >> >> Here's the grammar I recommend: >> >> =A0 =A0Strict-Transport-Security =3D "Strict-Transport-Security" ":" >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0d= irective *( ";" [ directive ] ) >> >> =A0 =A0directive =A0 =A0 =A0 =A0 =3D max-age | includeSubDomains | STS-d= -ext >> =A0 =A0max-age =A0 =A0 =A0 =A0 =A0 =3D "max-age" "=3D" delta-seconds >> =A0 =A0includeSubDomains =3D "includeSubDomains" >> =A0 =A0STS-d-ext =A0 =A0 =3D token [ "=3D" token ] >> >> I would also define the precise requirements for parsing all possible >> input sequences, but I understand that's not fashionable. > > Ack. This is at least consistent. > > That being said, I disagree. token=3Dquoted-string is widely implemented,= and > if there are clients not getting it right we should fix them. > > If you are aware of specific clients having this problem please list them= so > we can open bug reports. Chrome does not (and will not) implement quoted-string for the STS header for the reasons I've explained previously. You're welcome to file bugs, but I'm just going to close them WONTFIX. Adam From Jeff.Hodges@KingsMountain.com Thu Dec 29 17:02:13 2011 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 CC1F51F0C4A for ; Thu, 29 Dec 2011 17:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDq4YIkVbzWl for ; Thu, 29 Dec 2011 17:02:13 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 35BBA21F8B44 for ; Thu, 29 Dec 2011 17:02:13 -0800 (PST) Received: (qmail 29048 invoked by uid 0); 30 Dec 2011 01:01:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 30 Dec 2011 01:01:50 -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=ZtkBPy1PwhTZwHOF+lvW0sR4xA7+CLc2rTsVJ5yj5d0=; b=ZRjtwmeM/J9pg7ptTg8IfCswvNvBcI+xQHcCFwCccPncPD2kYWP9GhMDhC2ENr2dhTps+2kAIR1dX3a1dVRBkSy0KMyc30OfCRryj3PCrtSm8oml5vCQbjrptzVgEXm0; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.18]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RgQr0-0000oA-EW; Thu, 29 Dec 2011 18:01:50 -0700 Message-ID: <4EFD0D7D.7040908@KingsMountain.com> Date: Thu, 29 Dec 2011 17:01:49 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Adam Barth , 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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 01:02:13 -0000 Adam Barth noted: > > I would also define the precise requirements for parsing all possible > input sequences, but I understand that's not fashionable. By that, you are suggesting specification of parsing algorithms as done in RFC6265 "HTTP State Management Mechanism", yes? =JeffH From ietf@adambarth.com Thu Dec 29 17:22:46 2011 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 E69341F0C5A for ; Thu, 29 Dec 2011 17:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4-Di9sqgl32 for ; Thu, 29 Dec 2011 17:22:46 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 567341F0C4A for ; Thu, 29 Dec 2011 17:22:46 -0800 (PST) Received: by iabz21 with SMTP id z21so2633842iab.31 for ; Thu, 29 Dec 2011 17:22:46 -0800 (PST) Received: by 10.50.155.195 with SMTP id vy3mr43444615igb.12.1325208165900; Thu, 29 Dec 2011 17:22:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id aq5sm82472839igc.5.2011.12.29.17.22.44 (version=SSLv3 cipher=OTHER); Thu, 29 Dec 2011 17:22:44 -0800 (PST) Received: by iabz21 with SMTP id z21so2633818iab.31 for ; Thu, 29 Dec 2011 17:22:44 -0800 (PST) Received: by 10.42.148.1 with SMTP id p1mr1350881icv.27.1325208164104; Thu, 29 Dec 2011 17:22:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Thu, 29 Dec 2011 17:22:13 -0800 (PST) In-Reply-To: <4EFD0D7D.7040908@KingsMountain.com> References: <4EFD0D7D.7040908@KingsMountain.com> From: Adam Barth Date: Thu, 29 Dec 2011 17:22:13 -0800 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 01:22:47 -0000 On Thu, Dec 29, 2011 at 5:01 PM, =JeffH wrote: > Adam Barth noted: >> I would also define the precise requirements for parsing all possible >> input sequences, but I understand that's not fashionable. > > By that, you are suggesting specification of parsing algorithms as done in > RFC6265 "HTTP State Management Mechanism", yes? I actually think what we're doing for CSP is slightly better: http://www.w3.org/TR/CSP/#policies Adam From fielding@gbiv.com Thu Dec 29 20:11:30 2011 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 79A7421F8467 for ; Thu, 29 Dec 2011 20:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWpDpJ7kp0zG for ; Thu, 29 Dec 2011 20:11:29 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id CAC0D21F8466 for ; Thu, 29 Dec 2011 20:11:29 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 744D6584058; Thu, 29 Dec 2011 20:11:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=KPIiZXJ5iKk/iCqQ 8M8IA6krEQNL1G3HlD0Z8z4mOseqb7MhHTyXwZbs8yH5xwbrmK7P7jNhjX0KtOHr 5xe3i6IM5fvlmsexHoj/xBpWr49xVgE0W0+yVkzJqi2MtwMH+mZZ1i70IAWiaLNs t3vuGgyaFoI0NM+UNXZQ0D++wo4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=GUUJgvDDBuGpLPAkYWUSPkIZ/9I=; b=6GlNx1c1Pm3Y/UuUsl81G8nWuOYf EDreHbFZAVuyRCR6RA2AvFKKkJc051fbtvJ8uaiCFsFo9HpH4BBhru4zTPKEWiaW /gSaVGJ2TJqBwUoEpGgvLCNqGUQzY8Oss3tNhiprAMHS0/0NRyJ77zZZDIATzdgK YgitlsdPiZT8ZuQ= Received: from [10.134.89.89] (unknown [75.103.10.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 4B599584057; Thu, 29 Dec 2011 20:11:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: Date: Thu, 29 Dec 2011 20:11:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <168B10CA-0522-4A60-BAC8-597472B79882@gbiv.com> References: <4EFD0D7D.7040908@KingsMountain.com> To: Adam Barth X-Mailer: Apple Mail (2.1251.1) Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 04:11:30 -0000 On Dec 29, 2011, at 5:22 PM, Adam Barth wrote: > On Thu, Dec 29, 2011 at 5:01 PM, =3DJeffH = wrote: >> Adam Barth noted: >>> I would also define the precise requirements for parsing all = possible >>> input sequences, but I understand that's not fashionable. >>=20 >> By that, you are suggesting specification of parsing algorithms as = done in >> RFC6265 "HTTP State Management Mechanism", yes? >=20 > I actually think what we're doing for CSP is slightly better: >=20 > http://www.w3.org/TR/CSP/#policies Hmm, that algorithm breaks on=20 foo;;bob which is allowed by the associated ABNF. *shrug* I don't think I'll ever understand why you keep promoting Ian's mantra on specs being written as algorithms. The algorithms that you end up placing in the specs have more bugs than the code found in the actual implementations, and they aren't any more formal than the ABNF. ....Roy From ietf@adambarth.com Thu Dec 29 22:09:58 2011 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 DA68C11E807F for ; Thu, 29 Dec 2011 22:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n5n3hjhYUe7 for ; Thu, 29 Dec 2011 22:09:58 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26E7D21F8B6D for ; Thu, 29 Dec 2011 22:09:57 -0800 (PST) Received: by yhjj72 with SMTP id j72so9505130yhj.31 for ; Thu, 29 Dec 2011 22:09:56 -0800 (PST) Received: by 10.236.155.74 with SMTP id i50mr50771046yhk.23.1325225395939; Thu, 29 Dec 2011 22:09:55 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id n64sm53740018yhk.4.2011.12.29.22.09.54 (version=SSLv3 cipher=OTHER); Thu, 29 Dec 2011 22:09:55 -0800 (PST) Received: by obcuz6 with SMTP id uz6so11363097obc.31 for ; Thu, 29 Dec 2011 22:09:54 -0800 (PST) Received: by 10.50.6.233 with SMTP id e9mr44399739iga.17.1325225394101; Thu, 29 Dec 2011 22:09:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Thu, 29 Dec 2011 22:09:23 -0800 (PST) In-Reply-To: <168B10CA-0522-4A60-BAC8-597472B79882@gbiv.com> References: <4EFD0D7D.7040908@KingsMountain.com> <168B10CA-0522-4A60-BAC8-597472B79882@gbiv.com> From: Adam Barth Date: Thu, 29 Dec 2011 22:09:23 -0800 Message-ID: To: "Roy T. Fielding" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 06:09:59 -0000 On Thu, Dec 29, 2011 at 8:11 PM, Roy T. Fielding wrote: > On Dec 29, 2011, at 5:22 PM, Adam Barth wrote: >> On Thu, Dec 29, 2011 at 5:01 PM, =3DJeffH wrote: >>> Adam Barth noted: >>>> I would also define the precise requirements for parsing all possible >>>> input sequences, but I understand that's not fashionable. >>> >>> By that, you are suggesting specification of parsing algorithms as done= in >>> RFC6265 "HTTP State Management Mechanism", yes? >> >> I actually think what we're doing for CSP is slightly better: >> >> http://www.w3.org/TR/CSP/#policies > > Hmm, that algorithm breaks on > > =A0 foo;;bob > > which is allowed by the associated ABNF. =A0*shrug* I'm not sure I understand what you think breaks about the algorithm. I've restricted the loop to non-empty tokens, which hopefully addresses your concern. > I don't think I'll ever understand why you keep promoting Ian's > mantra on specs being written as algorithms. =A0The algorithms that > you end up placing in the specs have more bugs than the code > found in the actual implementations, and they aren't any more > formal than the ABNF. The problem is that the ABNF simply doesn't define how to handle error conditions. At least with algorithms they define the behavior. If the definition is wrong or has bugs, we can fix those bugs. Eventually the process converges to a correct definition of the behavior. Adam From julian.reschke@gmx.de Fri Dec 30 00:18:53 2011 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 2192621F848D for ; Fri, 30 Dec 2011 00:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.707 X-Spam-Level: X-Spam-Status: No, score=-103.707 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK6x8eIeons6 for ; Fri, 30 Dec 2011 00:18:52 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1BA1221F8472 for ; Fri, 30 Dec 2011 00:18:51 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2011 08:18:50 -0000 Received: from p3EE2751C.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.28] by mail.gmx.net (mp019) with SMTP; 30 Dec 2011 09:18:50 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Yfn5DUfSYOkNKOXMuooSvyfIgKiQ/OkuMkesKgd sP+ouZXqJvksWj Message-ID: <4EFD73E6.1060506@gmx.de> Date: Fri, 30 Dec 2011 09:18:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 08:18:53 -0000 On 2011-12-29 22:45, Adam Barth wrote: > ... > Chrome does not (and will not) implement quoted-string for the STS > header for the reasons I've explained previously. You're welcome to > file bugs, but I'm just going to close them WONTFIX. > ... So your code intentionally is non-compliant with STS. I note that you are both a WG member and also listed as one of the authors of the spec. Don't you think that this puts you into a strange position? Best regards, Julian From ietf@adambarth.com Fri Dec 30 00:47:31 2011 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 29AD821F8B2A for ; Fri, 30 Dec 2011 00:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSCv2vmV35BD for ; Fri, 30 Dec 2011 00:47:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB92B21F8B21 for ; Fri, 30 Dec 2011 00:47:30 -0800 (PST) Received: by iabz21 with SMTP id z21so3198879iab.31 for ; Fri, 30 Dec 2011 00:47:30 -0800 (PST) Received: by 10.42.153.6 with SMTP id k6mr40520404icw.30.1325234850265; Fri, 30 Dec 2011 00:47:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id gf6sm84535921igb.1.2011.12.30.00.47.29 (version=SSLv3 cipher=OTHER); Fri, 30 Dec 2011 00:47:29 -0800 (PST) Received: by iabz21 with SMTP id z21so3198847iab.31 for ; Fri, 30 Dec 2011 00:47:29 -0800 (PST) Received: by 10.42.151.195 with SMTP id f3mr40266491icw.19.1325234849116; Fri, 30 Dec 2011 00:47:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Fri, 30 Dec 2011 00:46:58 -0800 (PST) In-Reply-To: <4EFD73E6.1060506@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> From: Adam Barth Date: Fri, 30 Dec 2011 00:46:58 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 08:47:31 -0000 On Fri, Dec 30, 2011 at 12:18 AM, Julian Reschke wr= ote: > On 2011-12-29 22:45, Adam Barth wrote: >> Chrome does not (and will not) implement quoted-string for the STS >> header for the reasons I've explained previously. =A0You're welcome to >> file bugs, but I'm just going to close them WONTFIX. > > So your code intentionally is non-compliant with STS. > > I note that you are both a WG member and also listed as one of the author= s > of the spec. Don't you think that this puts you into a strange position? Not really. IMHO, we should just change the spec. Adam From julian.reschke@gmx.de Fri Dec 30 00:53:35 2011 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 C57D921F8B54 for ; Fri, 30 Dec 2011 00:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.48 X-Spam-Level: X-Spam-Status: No, score=-103.48 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwPkLs+Ha1Ic for ; Fri, 30 Dec 2011 00:53:35 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BFBEB21F8B4F for ; Fri, 30 Dec 2011 00:53:34 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2011 08:53:33 -0000 Received: from p3EE2751C.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.28] by mail.gmx.net (mp032) with SMTP; 30 Dec 2011 09:53:33 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+vtXJMEGmvuZEWz8hOeLT4QG8EpLwfVwMfgeqlfe +LAEakydeskWQo Message-ID: <4EFD7C09.9050702@gmx.de> Date: Fri, 30 Dec 2011 09:53:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 08:53:35 -0000 On 2011-12-30 09:46, Adam Barth wrote: > On Fri, Dec 30, 2011 at 12:18 AM, Julian Reschke wrote: >> On 2011-12-29 22:45, Adam Barth wrote: >>> Chrome does not (and will not) implement quoted-string for the STS >>> header for the reasons I've explained previously. You're welcome to >>> file bugs, but I'm just going to close them WONTFIX. >> >> So your code intentionally is non-compliant with STS. >> >> I note that you are both a WG member and also listed as one of the authors >> of the spec. Don't you think that this puts you into a strange position? > > Not really. IMHO, we should just change the spec. If you believe that support for quoted-string in extension directives is the wrong thing to do, please go ahead and lobby for a change. I happen to agree that parsing should be consistent for all directives, but my preference is to keep quoted-string, both for what you gain (the ability to express certain values that otherwise you can't without introducing yet another new way to encode them), and consistency with other header fields. Best regards, Julian From ietf@adambarth.com Fri Dec 30 01:14:22 2011 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 17E6521F8B5B for ; Fri, 30 Dec 2011 01:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4lgegtChIjw for ; Fri, 30 Dec 2011 01:14:21 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D108F21F8B5A for ; Fri, 30 Dec 2011 01:14:20 -0800 (PST) Received: by iabz21 with SMTP id z21so3236289iab.31 for ; Fri, 30 Dec 2011 01:14:20 -0800 (PST) Received: by 10.50.195.227 with SMTP id ih3mr44922355igc.19.1325236460494; Fri, 30 Dec 2011 01:14:20 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id l35sm125427415ibj.0.2011.12.30.01.14.19 (version=SSLv3 cipher=OTHER); Fri, 30 Dec 2011 01:14:19 -0800 (PST) Received: by iabz21 with SMTP id z21so3236254iab.31 for ; Fri, 30 Dec 2011 01:14:19 -0800 (PST) Received: by 10.42.148.1 with SMTP id p1mr2340048icv.27.1325236459112; Fri, 30 Dec 2011 01:14:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Fri, 30 Dec 2011 01:13:48 -0800 (PST) In-Reply-To: <4EFD7C09.9050702@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> From: Adam Barth Date: Fri, 30 Dec 2011 01:13:48 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 09:14:22 -0000 On Fri, Dec 30, 2011 at 12:53 AM, Julian Reschke wr= ote: > On 2011-12-30 09:46, Adam Barth wrote: >> >> On Fri, Dec 30, 2011 at 12:18 AM, Julian Reschke >> =A0wrote: >>> >>> On 2011-12-29 22:45, Adam Barth wrote: >>>> >>>> Chrome does not (and will not) implement quoted-string for the STS >>>> header for the reasons I've explained previously. =A0You're welcome to >>>> file bugs, but I'm just going to close them WONTFIX. >>> >>> So your code intentionally is non-compliant with STS. >>> >>> I note that you are both a WG member and also listed as one of the >>> authors >>> of the spec. Don't you think that this puts you into a strange position= ? >> >> Not really. =A0IMHO, we should just change the spec. > > If you believe that support for quoted-string in extension directives is = the > wrong thing to do, please go ahead and lobby for a change. Using quoted-string in the extension directive is the wrong thing to do. Because none of the actual directives use quoted-string, folks are likely to write parsers that don't handle all the complexities of quoted-string (which are legion). That means when we go to actually use quoted-string in a future directive, it won't actually work in many user agents. On the other hand, if we spec the extension directives without quoted-string, future extensions will work even if folks mistakenly implement quote-string (because DQUOTE is forbidden in the extension syntax I suggested above, so we'll never trigger the mistaken quoted-string parsing code). Everyone lives a happy life. Anyway, it's all somewhat of a moot point because the above will happen regardless of what we write in the spec. Even if we write quoted-string, when folks attempt to use these extension directives in the future, they'll find that they don't work and they'll update the syntax not to use quoted-string. Adam From julian.reschke@gmx.de Fri Dec 30 02:00:57 2011 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 E37DD21F8B54 for ; Fri, 30 Dec 2011 02:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcXDMvR8sc1d for ; Fri, 30 Dec 2011 02:00:56 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1875521F8B4E for ; Fri, 30 Dec 2011 02:00:55 -0800 (PST) Received: (qmail invoked by alias); 30 Dec 2011 10:00:52 -0000 Received: from p3EE2751C.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.28] by mail.gmx.net (mp033) with SMTP; 30 Dec 2011 11:00:52 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX197fXBIw7R7+UGtfSPnq+PiIeReAokl5+74txYwSy a8LhiViJfB3tBs Message-ID: <4EFD8BCE.7010909@gmx.de> Date: Fri, 30 Dec 2011 11:00:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 10:00:58 -0000 On 2011-12-30 10:13, Adam Barth wrote: > Using quoted-string in the extension directive is the wrong thing to > do. Because none of the actual directives use quoted-string, folks > are likely to write parsers that don't handle all the complexities of > quoted-string (which are legion). That means when we go to actually > use quoted-string in a future directive, it won't actually work in > many user agents. Unless we clarify the syntax, allow q-s everywhere, and have test cases. > On the other hand, if we spec the extension directives without > quoted-string, future extensions will work even if folks mistakenly > implement quote-string (because DQUOTE is forbidden in the extension > syntax I suggested above, so we'll never trigger the mistaken > quoted-string parsing code). Everyone lives a happy life. Absolutely not. First of all, some implementations will parse q-s, because that's consistent with other header fields. Also, not having q-s makes certain values impossible to send, in which case you'll need to invent yet another escaping syntax. > Anyway, it's all somewhat of a moot point because the above will > happen regardless of what we write in the spec. Even if we write > quoted-string, when folks attempt to use these extension directives in > the future, they'll find that they don't work and they'll update the > syntax not to use quoted-string. Why would they find that? Implementations can be fixed. Or is this argument based on the fact that you *currently* "own" one implementation and claim it can't be fixed? That would be a very strange thing to do in the context of an IETF WG trying to reach consensus. Best regards, Julian PS: I note that we are in violent agreement that the syntax should be the same for all directives, predefined or extension. We just come to different conclusions about what that syntax should be. From ietf@adambarth.com Fri Dec 30 10:38:12 2011 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 633EB21F8770 for ; Fri, 30 Dec 2011 10:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeQMRNAx6FI8 for ; Fri, 30 Dec 2011 10:38:11 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEBC721F86DD for ; Fri, 30 Dec 2011 10:38:11 -0800 (PST) Received: by iabz21 with SMTP id z21so3956245iab.31 for ; Fri, 30 Dec 2011 10:38:11 -0800 (PST) Received: by 10.42.163.200 with SMTP id d8mr42546571icy.41.1325270291489; Fri, 30 Dec 2011 10:38:11 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id d19sm130213958ibh.8.2011.12.30.10.38.08 (version=SSLv3 cipher=OTHER); Fri, 30 Dec 2011 10:38:08 -0800 (PST) Received: by iabz21 with SMTP id z21so3956138iab.31 for ; Fri, 30 Dec 2011 10:38:08 -0800 (PST) Received: by 10.42.151.195 with SMTP id f3mr42201504icw.19.1325270288108; Fri, 30 Dec 2011 10:38:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Fri, 30 Dec 2011 10:37:37 -0800 (PST) In-Reply-To: <4EFD8BCE.7010909@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> From: Adam Barth Date: Fri, 30 Dec 2011 10:37:37 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux 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, 30 Dec 2011 18:38:12 -0000 It seems we're not in agreement. We can repeat the same arguments over and over again, but it's not clear that would be productive. Adam On Fri, Dec 30, 2011 at 2:00 AM, Julian Reschke wro= te: > On 2011-12-30 10:13, Adam Barth wrote: >> >> Using quoted-string in the extension directive is the wrong thing to >> do. =A0Because none of the actual directives use quoted-string, folks >> are likely to write parsers that don't handle all the complexities of >> quoted-string (which are legion). =A0That means when we go to actually >> use quoted-string in a future directive, it won't actually work in >> many user agents. > > > Unless we clarify the syntax, allow q-s everywhere, and have test cases. > > >> On the other hand, if we spec the extension directives without >> quoted-string, future extensions will work even if folks mistakenly >> implement quote-string (because DQUOTE is forbidden in the extension >> syntax I suggested above, so we'll never trigger the mistaken >> quoted-string parsing code). =A0Everyone lives a happy life. > > > Absolutely not. > > First of all, some implementations will parse q-s, because that's consist= ent > with other header fields. Also, not having q-s makes certain values > impossible to send, in which case you'll need to invent yet another escap= ing > syntax. > > >> Anyway, it's all somewhat of a moot point because the above will >> happen regardless of what we write in the spec. =A0Even if we write >> quoted-string, when folks attempt to use these extension directives in >> the future, they'll find that they don't work and they'll update the >> syntax not to use quoted-string. > > > Why would they find that? Implementations can be fixed. > > Or is this argument based on the fact that you *currently* "own" one > implementation and claim it can't be fixed? That would be a very strange > thing to do in the context of an IETF WG trying to reach consensus. > > Best regards, Julian > > PS: I note that we are in violent agreement that the syntax should be the > same for all directives, predefined or extension. We just come to differe= nt > conclusions about what that syntax should be. From trac+websec@trac.tools.ietf.org Fri Dec 30 17:40:45 2011 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 2E26D21F8511 for ; Fri, 30 Dec 2011 17:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOaoaUmr6SiN for ; Fri, 30 Dec 2011 17:40:44 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A09F721F8505 for ; Fri, 30 Dec 2011 17:40:44 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rgnvj-00083e-GB; Fri, 30 Dec 2011 20:40:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Sat, 31 Dec 2011 01:40:14 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:1 Message-ID: <085.c94789b894d43a5fce9e943ecd079304@trac.tools.ietf.org> References: <070.4240e75d9bcd1a27acd9fe924417061f@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <070.4240e75d9bcd1a27acd9fe924417061f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111231014044.A09F721F8505@ietfa.amsl.com> Resent-Date: Fri, 30 Dec 2011 17:40:44 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 01:40:45 -0000 #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken Comment (by jeff.hodges@…): draft-ietf-websec-strict-transport-sec-03 contains fixes for the issues described in this ticket. Julian Reschke has reviewed -03, and provides feedback in this message.. Strict-Transport-Security syntax redux [Julian Reschke] https://www.ietf.org/mail-archive/web/websec/current/msg00918.html ..see also subsequent discussion in that email thread. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec