From ynir@checkpoint.com Wed Feb 6 23:46:50 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2835321F885B for ; Wed, 6 Feb 2013 23:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUd2wJIYaHVI for ; Wed, 6 Feb 2013 23:46:49 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B482721F8809 for ; Wed, 6 Feb 2013 23:46:48 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r177kk12006956; Thu, 7 Feb 2013 09:46:46 +0200 X-CheckPoint: {51135822-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Thu, 7 Feb 2013 09:46:46 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: [secdir] SecDir review of draft-williams-websec-session-continue-prob-00 Thread-Index: AQHOBQdHZfDb+/q650OjUEleUceCiQ== Date: Thu, 7 Feb 2013 07:46:45 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211199DCC1@IL-EX10.ad.checkpoint.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC30277211199DCC1ILEX10adcheckpo_" MIME-Version: 1.0 Cc: "ietf-websec-sessions@googlegroups.com" Subject: [websec] Fwd: [secdir] SecDir review of draft-williams-websec-session-continue-prob-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: Thu, 07 Feb 2013 07:46:50 -0000 --_000_4613980CFC78314ABFD7F85CC30277211199DCC1ILEX10adcheckpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI Begin forwarded message: From: Ben Laurie > Subject: Re: [secdir] Fwd: RE: SecDir review of draft-williams-websec-sessi= on-continue-prob-00 Date: February 7, 2013 3:58:27 AM GMT+02:00 To: Stephen Farrell > Cc: "secdir@ietf.org" > Not really a proper review, but some thoughts: " 4. Resistance to active attacks on https. [NOTE: This should probably NOT be a requirement. Instead we should be happy to note where a proposed protocol provides this.]" I'm very confused by this point, but... a) What active attacks? Need to specify them. b) If there are active attacks that are actually effective (surely not?) that can be avoided by these protocols, then avoidance should be compulsory. And then... " 8. Session continuation must provide protection against man-in-the- middle (MITM) attacks when using TLS. (This is important when using anonymous Diffie-Hellman cipher suites for TLS, as well as when using server certificates from low-value Public Key Infrastructures (PKI)." Seems to be a couple of examples of what they're talking about. " 10. Must work across all types of proxies. Proxies that can modify the plaintext HTTP requests and responses can (but should not) interfere with any session continuation protocol." A man-in-the-middle is a type of proxy, so this seems like an unsatisfiable requirement. --_000_4613980CFC78314ABFD7F85CC30277211199DCC1ILEX10adcheckpo_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable FYI

Begin forwarded message:

From: Ben L= aurie <benl@google.com>
Subject: Re= : [secdir] Fwd: RE: SecDir review of draft-williams-websec-session-continue= -prob-00
Date: Febru= ary 7, 2013 3:58:27 AM GMT+02:00
To: Steph= en Farrell <stephen.farrell= @cs.tcd.ie>

Not really a proper review, but some thoughts:

" 4. Resistance to active attacks on https. [NOTE: This should

       probably NOT be a requirement. &n= bsp;Instead we should be happy to
       note where a proposed protocol pr= ovides this.]"

I'm very confused by this point, but...

a) What active attacks? Need to specify them.

b) If there are active attacks that are actually effective (surely
not?) that can be avoided by these protocols, then avoidance should be
compulsory.

And then...

" 8. Session continuation must provide protection against man-in-the-<= br>
       middle (MITM) attacks when using = TLS.  (This is important when
       using anonymous Diffie-Hellman ci= pher suites for TLS, as well as
       when using server certificates fr= om low-value Public Key
       Infrastructures (PKI)."

Seems to be a couple of examples of what they're talking about.

" 10. Must work across all types of proxies. Proxies that can modify
       the plaintext HTTP requests and r= esponses can (but should not)
       interfere with any session contin= uation protocol."

A man-in-the-middle is a type of proxy, so this seems like an
unsatisfiable requirement.


--_000_4613980CFC78314ABFD7F85CC30277211199DCC1ILEX10adcheckpo_-- From benl@google.com Thu Feb 7 00:10:50 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9FB21F8903 for ; Thu, 7 Feb 2013 00:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rRZdEKDxxE7 for ; Thu, 7 Feb 2013 00:10:49 -0800 (PST) Received: from mail-ie0-x229.google.com (ie-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 99EB121F88F7 for ; Thu, 7 Feb 2013 00:10:49 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id 13so3176427iea.28 for ; Thu, 07 Feb 2013 00:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=raX0uomONUI3tL+8LJjB7OsIyYVTqyMwXKPY73uR4nk=; b=gyLYsH2mQnX8vKX6nQkzv7T+sICUi1ZADsifpiV26e87m6UC478XxSt8YsV/Rehr5A /eIQs8cjbtVs/iVXRKpi7Eb3lmyathAe/O8yINTL8QgsvDWYfXZeztqMuBR4iu3X8Xp5 cUF8lEnKKC6gc9Ub9XwhQylvZEgZlciJFSVLGQOUyldTbeHAInR0NV03dn2hLWPmAjyO Jg3yAebwtSaPAm5DrE/1mLK3ZZ9nu/eNzI+o2SanTFAE3RjfgfDea10nqmunM62p7qrd gPfufmMx47NNyc58JPWinXb6suaDyOeDtR51OwIHdNdTdzfusE8IDJ4/tIoXdJJoSH4m Dkqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=raX0uomONUI3tL+8LJjB7OsIyYVTqyMwXKPY73uR4nk=; b=WLyYiVl5WKVNw/deipGY7jSmrkKS6fcq9HYcfcKbocl3OPMcqAyUzmkHC+Im07cMG+ 0HJfQKBrFXvtOtqg0iplh6x+bV3ixzJsr8ds3DmRqzlmiES4xZLNUfboq9lCoHJw4ZD6 hEwFjSvfqTA9o8qLeWAZNcSHu8nDqBWRPr+4MKnie7efIUM8vOTV0H/yhI6CihbuvbFO EwT5g+OQllMi1D65+Evjbp2MVtmu1FBFNFL2fjdFu4plI64o3U6oZlU2TnJn9FCu8Xkq 6UZ/MaS2PEt+8JcR0PBqwZzeq8sIv3RPqQSqF9p5s7r+vDI1USpz9qJU7zYuBbjNpeYX +SWQ== MIME-Version: 1.0 X-Received: by 10.50.222.195 with SMTP id qo3mr881823igc.14.1360224649093; Thu, 07 Feb 2013 00:10:49 -0800 (PST) Received: by 10.64.5.168 with HTTP; Thu, 7 Feb 2013 00:10:48 -0800 (PST) In-Reply-To: <4613980CFC78314ABFD7F85CC30277211199DCC1@IL-EX10.ad.checkpoint.com> References: <4613980CFC78314ABFD7F85CC30277211199DCC1@IL-EX10.ad.checkpoint.com> Date: Thu, 7 Feb 2013 08:10:48 +0000 Message-ID: From: Ben Laurie To: Yoav Nir , "secdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnjiLtS7tP6oRa2sfhBoNHDHOLaf3cbjKPLDCc8leyAAfAXCmcr4ilvu6Qd1TyzVUWysw9VOx42zAlBkuGRMEULEGYIPjyfDG3T+NOns6xa5vZaHjWXpra2IJfO2mniE8jQXEalXPtvWmdsDZ23DIuX4Zi5T+ugcoeVbKH4bOktHpK397JAshQ90K/nCtW2zUnRG6rG Cc: "ietf-websec-sessions@googlegroups.com" , IETF WebSec WG Subject: Re: [websec] Fwd: [secdir] SecDir review of draft-williams-websec-session-continue-prob-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: Thu, 07 Feb 2013 08:10:50 -0000 On 7 February 2013 07:46, Yoav Nir wrote (that I wrote): > " 10. Must work across all types of proxies. Proxies that can modify > > the plaintext HTTP requests and responses can (but should not) > interfere with any session continuation protocol." > > A man-in-the-middle is a type of proxy, so this seems like an > unsatisfiable requirement. Actually, that's not quite right. Protocols can work across a proxy, but what's required is that the proxy does not gain the ability to pretend to be one of the endpoints. If you satisfy this, then a MitM can snoop, but can't masquerade. But this seems to impose quite a strong constraint on the protocol: in particular, future traffic must somehow be bound to the (end-to-end) session continuation. From bhill@paypal-inc.com Mon Feb 11 14:09:53 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42CD21F8A89 for ; Mon, 11 Feb 2013 14:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.8 X-Spam-Level: X-Spam-Status: No, score=-9.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVrJc6DLhGPl for ; Mon, 11 Feb 2013 14:09:52 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 28B6E21F8A80 for ; Mon, 11 Feb 2013 14:09:51 -0800 (PST) DomainKey-Signature: s=paypalcorp; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=uZlJbwBbT5yXi5UTLnyLLyGlua43U0drKzInnvoi3mzsyY0HTBN7PkTl GpnNZnu1rLoGIW8fXwWU182hAy55dur3DNqr1uhGnFMat4aNqhAmkGwKq Kf2FJ+pH+lwaCZljEhr5iKY82Eyz/4cIsdtnI1IaDrLwB1KSZpcVnIhv4 k=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1360620592; x=1392156592; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=fSjL1srQtXSL1udTr7snlUs3dSSjx7QcO/zlLExa+TM=; b=m2LI6eZKOKDJI//lq4R5GDyl0rXBVXPKmicrDmxA1bnLoGAEw3KQLyad +iFBnJE0wY7JiRv2anC8BTNk6kXQc1Y3NZ59xBc8OZCjgaouLR23U/p1c Ikn2J+ouID9zpQdLeAotN1CVhWoyPr/3EiR6gFCDjVOQ6NRiB8JU2BlM1 M=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.84,646,1355126400"; d="scan'208";a="12765961" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-004.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 11 Feb 2013 14:09:51 -0800 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-004.corp.ebay.com ([fe80::a487:c570:9abc:bb59%14]) with mapi id 14.02.0318.004; Mon, 11 Feb 2013 15:09:51 -0700 From: "Hill, Brad" To: Yoav Nir , Julian Reschke , "Tobias Gondrom (tobias.gondrom@gondrom.org)" Thread-Topic: X-Frame-Options EBNF bug at Mozilla Thread-Index: Ac4IpIq0IjFESr+DQEGnUPazAUlfLQ== Date: Mon, 11 Feb 2013 22:09:50 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E279156B0@DEN-EXDDA-S12.corp.ebay.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: IETF WebSec WG Subject: [websec] X-Frame-Options EBNF bug at Mozilla 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, 11 Feb 2013 22:09:53 -0000 This bug at Mozilla was recently brought to my attention: https://bugzilla.mozilla.org/show_bug.cgi?id=3D836132 It seems to indicate that the specified EBNF of using a colon between "ALLO= W-FROM" and the URI is not the actual behavior of most user agents that imp= lement that functionality. Perhaps we should update this to reflect the predominant implementation in = the field. (Internet Explorer's) -Brad > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Yoav Nir > Sent: Tuesday, January 29, 2013 5:30 AM > To: Julian Reschke > Cc: IETF WebSec WG > Subject: Re: [websec] WGLC feedback for X-Frame-Options >=20 > Yes. Tobias will submit a revised version soon, incorporating the WGLC > comments. >=20 > Yoav >=20 > On Jan 29, 2013, at 3:20 PM, Julian Reschke > wrote: >=20 > > On 2012-11-06 18:25, Julian Reschke wrote: > >> Hi there, > >> > >> here's my feedback from the HTTP/editorial point of view: > >> ... > > > > Just checking: is the WG still working on this draft? There doesn't see= m to > be any activity since October 2012... > > >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From julian.reschke@gmx.de Wed Feb 13 02:00:19 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48A521F8869 for ; Wed, 13 Feb 2013 02:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.645 X-Spam-Level: X-Spam-Status: No, score=-104.645 tagged_above=-999 required=5 tests=[AWL=-2.845, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 TyHWg1cn5uam for ; Wed, 13 Feb 2013 02:00:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 75FBA21F886A for ; Wed, 13 Feb 2013 02:00:13 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MARzI-1UBajY3Fne-00BfWM for ; Wed, 13 Feb 2013 11:00:10 +0100 Received: (qmail invoked by alias); 13 Feb 2013 10:00:10 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 13 Feb 2013 11:00:10 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19ytaM6kdFyBT7Em/kTjbuM2q4zDbdtSXq/coPme2 +gMKOdENXnQaEK Message-ID: <511B6429.7000702@gmx.de> Date: Wed, 13 Feb 2013 11:00:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Hill, Brad" References: <370C9BEB4DD6154FA963E2F79ADC6F2E279156B0@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E279156B0@DEN-EXDDA-S12.corp.ebay.com> 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] X-Frame-Options EBNF bug at Mozilla 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, 13 Feb 2013 10:00:19 -0000 On 2013-02-11 23:09, Hill, Brad wrote: > This bug at Mozilla was recently brought to my attention: > > https://bugzilla.mozilla.org/show_bug.cgi?id=836132 > > It seems to indicate that the specified EBNF of using a colon between "ALLOW-FROM" and the URI is not the actual behavior of most user agents that implement that functionality. > > Perhaps we should update this to reflect the predominant implementation in the field. (Internet Explorer's) > > -Brad Removing the colon (*not* making it optional) would also be consistent with the description in . Note that the ABNF needs to be updated to RFC 5234 syntax anyway, and that it should only describe the header field value, such as: X-Frame-Options = "DENY" / "SAMEORIGIN" / ("ALLOW-FROM" RWS URI) RWS = URI = (we may want to discuss restricting URI to scheme + authority, though). Best regards, Julian From derhoermi@gmx.net Wed Feb 13 06:09:55 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3EA21F8714 for ; Wed, 13 Feb 2013 06:09:55 -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 z1aE1ObFXgEw for ; Wed, 13 Feb 2013 06:09:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 01ADC21F86F6 for ; Wed, 13 Feb 2013 06:09:47 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MPsKa-1U0exE3QeI-0054Mr for ; Wed, 13 Feb 2013 15:09:46 +0100 Received: (qmail invoked by alias); 13 Feb 2013 14:09:46 -0000 Received: from p5B23193A.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.25.58] by mail.gmx.net (mp030) with SMTP; 13 Feb 2013 15:09:46 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18S2WRJES4SwepRzKvfxJ76n7XVGKgHKjTHRvujKS GB8Jh+sDzlWs/R From: Bjoern Hoehrmann To: websec@ietf.org Date: Wed, 13 Feb 2013 15:09:47 +0100 Message-ID: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: [websec] RFC6454 (Origin) vs URI schemes unlike "http" 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, 13 Feb 2013 14:09:55 -0000 Hi, https://tools.ietf.org/html/rfc6454 fails to properly account for a number of cases where URIs and URI schemes are slightly unusual, e.g. The origin of a URI is the value computed by the following algorithm: 1. If the URI does not use a hierarchical element as a naming authority (see [RFC3986], Section 3.2) or if the URI is not an absolute URI, then generate a fresh globally unique identifier and return that value. ... 2. Let uri-scheme be the scheme component of the URI, converted to lowercase. 3. If the implementation doesn't support the protocol given by uri- scheme, then generate a fresh globally unique identifier and return that value. Consider `javascript://example.org`. In order to make the determination whether "the URI" uses "a hierarchical element as a naming authority" you have to know the scheme, but the scheme is not mentioned until after the first step, which may lead one to believe that you can make this de- termination without knowing the scheme. For 'javascript' in particular there is no "over the wire" "protocol", so it's not clear what to do in the third step. Consider this from the perspective of someone making a generic URI library and giving URI objects some `.origin` property: how would that work? A browser might support "ftp" but a user might disable loading resources over FTP in the browser; or it might phase out FTP support but keep supporting 'ftp' URIs (like by still knowing the default port). What is the "Origin of a URI" then? Does it matter if you do not actually load content from such a URI, or don't do it in a web-browser-like fashion? I am not sure... Further down there is 5. Let uri-host be the host component of the URI, converted to lower case (using the i;ascii-casemap collation defined in [RFC4790]). What if there is no `host` component? `news:de.comp.text.xml` does not have one, even though the scheme does use "a hierarchical element as a naming authority" and the URI is valid? For that matter, what if there is such a component but it's the empty string (like in `file:///`, if you ignore the specific provision for 'file')? It seems the empty string would pass through the "algorithm", but it's unclear if that is inten- tional and what the security considerations are in this regard. 6. If there is no port component of the URI: 1. Let uri-port be the default port for the protocol given by uri-scheme. Otherwise: 2. Let uri-port be the port component of the URI. Per RFC 3986 schemes may define a default port but do not have to. What if a scheme does not define a default port? Also, what if the component is present, but is the empty string? In section 6.1 I'm told 1. Append a U+003A COLON code point (":") and the given port, in base ten, to result. I can't give the empty string in base ten. Per RFC 3986 the port compo- nent should be omitted when it is the empty string, which would lead to use of the default port if any, but there is no provision in RFC 6454 for normalising URIs and it's valid to use the empty string as value so that is valid input into the "Origin of a URI" "algorithm". regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From sm@resistor.net Wed Feb 13 11:48:33 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDA121E8055; Wed, 13 Feb 2013 11:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPSGLjo87ZvJ; Wed, 13 Feb 2013 11:48:29 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE9621F852C; Wed, 13 Feb 2013 11:48:29 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1DJmJpr001254; Wed, 13 Feb 2013 11:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360784904; bh=mmzsCLn2r8UjQDgXt9elQzA9QYrXgTEnyrcO/r+06eQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=t1LBkNTK/E/D4dz7dIM4IZMqs7LpOMWIvpNdD8w8yaF4GDP6kuJ2cO0X98ZbMaYcu GkynNMvu3tSVC51INdSm3Zard8rXf5r4Vqrmxat3DUGaXkW/EmEI7zb8QHAgcGMD1P QNhT665mPioMKeOYcac6egG0ia5GP7Lq9ztzPwm0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360784904; i=@resistor.net; bh=mmzsCLn2r8UjQDgXt9elQzA9QYrXgTEnyrcO/r+06eQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KReMLv4xsl0kDuUGq0n0x4qLis2YHNaYivpgjRp7si1t24cQlGwS7IFAazTTEA17R DKnWNF9ii+lyZlO91d9VfqM4IlAkjRhJZpmB7pUXMRP7WnpW43Y+JXT/GNHnDCfoC6 NQPmayQqsVFoEYaylltqIMeKBt1a8OLymnL/wUwM= Message-Id: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 13 Feb 2013 11:44:59 -0800 To: Bjoern Hoehrmann From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: websec@ietf.org, ietf-message-headers@ietf.org Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 13 Feb 2013 19:48:33 -0000 Hi Bjoern, [Cc to Websec as it is their document] At 09:37 13-02-2013, Bjoern Hoehrmann wrote: > http://www.iana.org/assignments/message-headers/prov-headers.html and >http://www.iana.org/assignments/message-headers/perm-headers.html list >the "Origin" header for HTTP, one per RFC 6454 and one from an earlier >W3C registration. Is that as it should be? No. IANA did what it was requested to do. Anyway, in my opinion, it would have to be fixed (process stuff). Regards, -sm From julian.reschke@gmx.de Wed Feb 13 12:12:27 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDBE21F86BC for ; Wed, 13 Feb 2013 12:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.398 X-Spam-Level: X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=-3.799, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOzE41N80lgr for ; Wed, 13 Feb 2013 12:12:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9A821F86B8 for ; Wed, 13 Feb 2013 12:12:26 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LkDn2-1Uc2Ik27pa-00c92n for ; Wed, 13 Feb 2013 21:12:24 +0100 Received: (qmail invoked by alias); 13 Feb 2013 20:12:24 -0000 Received: from p5DD94DF5.dip.t-dialin.net (EHLO [192.168.1.102]) [93.217.77.245] by mail.gmx.net (mp020) with SMTP; 13 Feb 2013 21:12:24 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1++20QRp82+f143WopqzsqC3I9+51ZTzdyjCcHZmj 0wBLGkDtoZ2TKl Message-ID: <511BF3A3.2090005@gmx.de> Date: Wed, 13 Feb 2013 21:12:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> In-Reply-To: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf-message-headers@ietf.org, Bjoern Hoehrmann , websec@ietf.org Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 13 Feb 2013 20:12:27 -0000 On 2013-02-13 20:44, SM wrote: > Hi Bjoern, > > [Cc to Websec as it is their document] > > At 09:37 13-02-2013, Bjoern Hoehrmann wrote: >> http://www.iana.org/assignments/message-headers/prov-headers.html and >> http://www.iana.org/assignments/message-headers/perm-headers.html list >> the "Origin" header for HTTP, one per RFC 6454 and one from an earlier >> W3C registration. Is that as it should be? > > No. IANA did what it was requested to do. Anyway, in my opinion, it > would have to be fixed (process stuff). > ... Yes and no. The core task is running the registries, and those really should be set up such that things like that simply can not happen. Seems like a software problem to me -- apparently there are two registries where there should be only one. Best regards, Julian From ynir@checkpoint.com Wed Feb 13 12:12:42 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB8B21F86C4; Wed, 13 Feb 2013 12:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7K2eiYEJop5; Wed, 13 Feb 2013 12:12:42 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B48CC21F8688; Wed, 13 Feb 2013 12:12:41 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r1DKCMwp003033; Wed, 13 Feb 2013 22:12:26 +0200 X-CheckPoint: {511BEF83-1-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Wed, 13 Feb 2013 22:12:22 +0200 From: Yoav Nir To: SM Thread-Topic: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional Thread-Index: AQHOCiMpQA8EvxXllUyKA9V7P1HJZ5h4Fw6A Date: Wed, 13 Feb 2013 20:12:22 +0000 Message-ID: <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> In-Reply-To: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.231] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <321990BE4A858A4C92C5810FCB3AA21E@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Bjoern Hoehrmann , "" Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 13 Feb 2013 20:12:42 -0000 Hi SM The W3C one is from a very old document, the first draft of which dates bac= k to 2005. Anne van Kesteren has been editing it since 2007. The Origin header was first mentioned in the draft from September 2008. The= re it is sully explained. In 2009 the name of the document was changed to "Cross-Origin Resource Shar= ing". Starting with the version from July 2010, that document references the WebS= ec draft, and later the RFC. I suppose the provisional header should be removed, but the now-defunct W3C= group is no longer available to request this. I'll see what can be done. Yoav On Feb 13, 2013, at 9:44 PM, SM wrote: > Hi Bjoern, >=20 > [Cc to Websec as it is their document] >=20 > At 09:37 13-02-2013, Bjoern Hoehrmann wrote: >> http://www.iana.org/assignments/message-headers/prov-headers.html and >> http://www.iana.org/assignments/message-headers/perm-headers.html list >> the "Origin" header for HTTP, one per RFC 6454 and one from an earlier >> W3C registration. Is that as it should be? >=20 > No. IANA did what it was requested to do. Anyway, in my opinion, it wou= ld have to be fixed (process stuff). >=20 > Regards, > -sm >=20 >=20 >=20 >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Email secured by Check Point From julian.reschke@gmx.de Wed Feb 13 12:24:26 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687FE21F8703 for ; Wed, 13 Feb 2013 12:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.225 X-Spam-Level: X-Spam-Status: No, score=-106.225 tagged_above=-999 required=5 tests=[AWL=-3.626, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sB2OO5PEM6z for ; Wed, 13 Feb 2013 12:24:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id A916A21F86FD for ; Wed, 13 Feb 2013 12:24:25 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lsuw8-1V2Kpe1v4M-012aAs for ; Wed, 13 Feb 2013 21:24:24 +0100 Received: (qmail invoked by alias); 13 Feb 2013 20:24:24 -0000 Received: from p5DD97762.dip.t-dialin.net (EHLO [192.168.1.102]) [93.217.119.98] by mail.gmx.net (mp017) with SMTP; 13 Feb 2013 21:24:24 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19hIQptt4ph4XaW5KcQ+eGEXE2el5tJeeuQh9NcOi 4huYAU22kivyfd Message-ID: <511BF66F.5070100@gmx.de> Date: Wed, 13 Feb 2013 21:24:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Yoav Nir References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Bjoern Hoehrmann , "" , "" Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 13 Feb 2013 20:24:26 -0000 On 2013-02-13 21:12, Yoav Nir wrote: > Hi SM > > The W3C one is from a very old document, the first draft of which dates back to 2005. Anne van Kesteren has been editing it since 2007. > > The Origin header was first mentioned in the draft from September 2008. There it is sully explained. > In 2009 the name of the document was changed to "Cross-Origin Resource Sharing". > Starting with the version from July 2010, that document references the WebSec draft, and later the RFC. > > I suppose the provisional header should be removed, but the now-defunct W3C group is no longer available to request this. > > I'll see what can be done. > > Yoav > ... Well. You make it sound as if it's ok to run two different registries with partly overlapping values. It's not. It's a bug in the way IANA handles this. This is what needs to be fixed. Best regards, Julian From barryleiba.mailing.lists@gmail.com Wed Feb 13 12:31:00 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2FF21E803D; Wed, 13 Feb 2013 12:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JL4jTiGcppK; Wed, 13 Feb 2013 12:30:59 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 76C4021F8651; Wed, 13 Feb 2013 12:30:59 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so1048183vbn.0 for ; Wed, 13 Feb 2013 12:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EbnrH0X4v4eHS46L/TYIFw2BaG4lzfFixibliOeAXUM=; b=gzUSof1wEutfiKiPHqC37nlF/n2wvJGJuxJCgHUbxczHKXimtB85eGn4VgHchbbETO M2rJTin9Q8G3y8IeBKu3cmoqNi4xJB71XPKvWcamwy/LUOc+X7mT153blZk7M3KX41Np pXklERlv/TeWYREnKaengtUput5bo3+qThogiyURnkSEys61Kv5dX++MctuZzmC9vxDS lm2BpVOIiP8vOVyQCj7pbSZO86VVSKcjStQXCN3VxGntc+jokvJYaGpxyErTaoAOTeim VcdpS2fA8i9sQiltLibwnPQFfsCO2/HDwKJK3on1BxTXTdvU5GAKAUq0+UU88aDBKye2 CgvA== MIME-Version: 1.0 X-Received: by 10.52.67.133 with SMTP id n5mr26480552vdt.24.1360787458415; Wed, 13 Feb 2013 12:30:58 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 13 Feb 2013 12:30:58 -0800 (PST) In-Reply-To: <511BF66F.5070100@gmx.de> References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> Date: Wed, 13 Feb 2013 15:30:58 -0500 X-Google-Sender-Auth: NQeZCNWjnkmBz7DO40y9i1yf7e0 Message-ID: From: Barry Leiba To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Bjoern Hoehrmann , "" Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 13 Feb 2013 20:31:00 -0000 > You make it sound as if it's ok to run two different registries with partly > overlapping values. It's not. It's a bug in the way IANA handles this. This > is what needs to be fixed. Indeed. I've already suggested to Yoav, off list, how to get this fixed in this case. I will talk with IANA in Orlando about dealing with it systematically. Barry, Applications AD From sm@resistor.net Wed Feb 13 12:32:43 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E0B21F862A; Wed, 13 Feb 2013 12:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq52B15z7SeQ; Wed, 13 Feb 2013 12:32:42 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D968521F8628; Wed, 13 Feb 2013 12:32:42 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1DKWNAk022825; Wed, 13 Feb 2013 12:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360787550; bh=rKCQeBEaYrM6QabYxf4Be641CyHF8zAzK8R7/pBgjF0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2r1JVwcmdmQhVM76wyeXITjKwzJntFNx6ka08T465l21/7k0AtuyQno5nxRlRA3F3 h7CrpuQpGgnPh7xrA+hG9NAfGbBOMiNxkI/gN2sD9o0c4MwRmWGHr7V0C9WE6CZxDk vpHeVyqz4HzetrNzNNBt9I4HKAuY9lh7kZwGQDDk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360787550; i=@resistor.net; bh=rKCQeBEaYrM6QabYxf4Be641CyHF8zAzK8R7/pBgjF0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MCUI+R3iAdM79XZyCchYaAzJO0zo/ah1Q8G8lfZVWTaEALaV6efBICwB6cP8aqPCy k1qClCLiWGd+WEH3NRhm1hrX99ZQoaL6+7Vr08Edl+2csu76glDMl8qSwgi+JmrQRW AO7GRIKH+uleg/UjH22k4FUY8VGly+O5/1LyYlTQ= Message-Id: <6.2.5.6.2.20130213122642.0a997470@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 13 Feb 2013 12:32:12 -0800 To: Julian Reschke From: SM In-Reply-To: <511BF66F.5070100@gmx.de> References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: websec@ietf.org, Bjoern Hoehrmann , ietf-message-headers@ietf.org Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 13 Feb 2013 20:32:44 -0000 Hi Julian, At 12:24 13-02-2013, Julian Reschke wrote: >You make it sound as if it's ok to run two different registries with >partly overlapping values. It's not. It's a bug in the way IANA >handles this. This is what needs to be fixed. It's easier to fix the bug first. The following could be used: "When a new entry is recorded in the permanent message header field registry, IANA will remove any corresponding entries (with the same field name and protocol) from the provisional registry." That avoids overlapping values. Regards, -sm From ynir@checkpoint.com Wed Feb 13 12:43:30 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0D721F85D0; Wed, 13 Feb 2013 12:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4TxM6xYUsnS; Wed, 13 Feb 2013 12:43:29 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6520221F85C0; Wed, 13 Feb 2013 12:43:29 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r1DKhKjC007868; Wed, 13 Feb 2013 22:43:20 +0200 X-CheckPoint: {511BF6C4-3-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Wed, 13 Feb 2013 22:43:20 +0200 From: Yoav Nir To: Julian Reschke Thread-Topic: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional Thread-Index: AQHOCiMpQA8EvxXllUyKA9V7P1HJZ5h4Fw6AgAADU4CAAAVSgA== Date: Wed, 13 Feb 2013 20:43:18 +0000 Message-ID: <4613980CFC78314ABFD7F85CC3027721119A7198@IL-EX10.ad.checkpoint.com> References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> In-Reply-To: <511BF66F.5070100@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.231] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: <28C291D2A2670F4CB6B6B12FEC6A3382@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bjoern Hoehrmann , "" , "" Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 13 Feb 2013 20:43:30 -0000 On Feb 13, 2013, at 10:24 PM, Julian Reschke wrote: > Well. >=20 > You make it sound as if it's ok to run two different registries with part= ly overlapping values. It's not. It's a bug in the way IANA handles this. T= his is what needs to be fixed. >=20 > Best regards, Julian I don't want to turn this into a process debate, but having a provisional r= egistry like this allows you to create interoperable implementations while = the document is still at draft. I often see a push to get a document publis= hed because we need the IANA assignments for products.=20 Of course they could still do this with a single registry where provisional= entries are somehow marked (with an asterisk?). That way we wouldn't get t= o a situation where we have double entries. Yoav= From ietf@adambarth.com Wed Feb 13 12:45:57 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4522321F8658 for ; Wed, 13 Feb 2013 12:45:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWM--vVvEwqJ for ; Wed, 13 Feb 2013 12:45:55 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id A1F9121F85F0 for ; Wed, 13 Feb 2013 12:45:54 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id gg13so1273057lbb.16 for ; Wed, 13 Feb 2013 12:45:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=uQeJo7l9mz4YHPGyE9dlUdmSk8wfPXUzCkkKCsYGHTk=; b=UDKQTczAmq6/Yg9+hYjKBXHuAj90wgdl2ChxffLk59rf4i5upppynxBAqIs3HCohkm ZIRaFIEOR8Gl52c3+eHn5p48wv3vFaKuKESNhgoTUDdll7ikIK7Gcr+kF5nIK9pMRpd9 Kn89V+0Q/YJkH2e6tS2hSQaHzpandFtvWuO5xEfKejEpQiVfERZbVJwZ6S5hz3pBFdi1 PsBF1V9T57bipJ+PneIsyYEZY38WZVUVtVzo0M24B8MI3TiEehUy1G5/Xkm+7hLy47Nu Vl4C9m7S96pejOy4IYan6OY0CB/nI+feFwb814aQlJ70xtjNa26YZm77ldhaxS/KY5Cf et5g== X-Received: by 10.112.23.34 with SMTP id j2mr9277664lbf.118.1360788353500; Wed, 13 Feb 2013 12:45:53 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mx.google.com with ESMTPS id t17sm6147858lam.9.2013.02.13.12.45.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 12:45:52 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id s4so1239336lbc.7 for ; Wed, 13 Feb 2013 12:45:51 -0800 (PST) X-Received: by 10.112.48.163 with SMTP id m3mr5000101lbn.90.1360788351482; Wed, 13 Feb 2013 12:45:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.88.210 with HTTP; Wed, 13 Feb 2013 12:45:21 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Wed, 13 Feb 2013 12:45:21 -0800 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnO9nw4AsOxSmOwcWQ6mvgqD4DpcbUfDUDnnma3yp7KYYZAHwgc700kK1l84ekRnIe0OUoC Cc: websec Subject: Re: [websec] RFC6454 (Origin) vs URI schemes unlike "http" 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, 13 Feb 2013 20:45:57 -0000 Yeah, the next time we update the spec, we'll probably need to reference http://url.spec.whatwg.org/, which has the needed definitions. Adam On Wed, Feb 13, 2013 at 6:09 AM, Bjoern Hoehrmann wrote= : > Hi, > > https://tools.ietf.org/html/rfc6454 fails to properly account for a > number of cases where URIs and URI schemes are slightly unusual, e.g. > > The origin of a URI is the value computed by the following algorithm: > > 1. If the URI does not use a hierarchical element as a naming > authority (see [RFC3986], Section 3.2) or if the URI is not an > absolute URI, then generate a fresh globally unique identifier > and return that value. > ... > 2. Let uri-scheme be the scheme component of the URI, converted to > lowercase. > > 3. If the implementation doesn't support the protocol given by uri- > scheme, then generate a fresh globally unique identifier and > return that value. > > Consider `javascript://example.org`. In order to make the determination > whether "the URI" uses "a hierarchical element as a naming authority" > you have to know the scheme, but the scheme is not mentioned until after > the first step, which may lead one to believe that you can make this de- > termination without knowing the scheme. > > For 'javascript' in particular there is no "over the wire" "protocol", > so it's not clear what to do in the third step. Consider this from the > perspective of someone making a generic URI library and giving URI > objects some `.origin` property: how would that work? A browser might > support "ftp" but a user might disable loading resources over FTP in the > browser; or it might phase out FTP support but keep supporting 'ftp' > URIs (like by still knowing the default port). What is the "Origin of a > URI" then? Does it matter if you do not actually load content from such > a URI, or don't do it in a web-browser-like fashion? I am not sure... > > Further down there is > > 5. Let uri-host be the host component of the URI, converted to lower > case (using the i;ascii-casemap collation defined in [RFC4790]). > > What if there is no `host` component? `news:de.comp.text.xml` does not > have one, even though the scheme does use "a hierarchical element as a > naming authority" and the URI is valid? For that matter, what if there > is such a component but it's the empty string (like in `file:///`, if > you ignore the specific provision for 'file')? It seems the empty string > would pass through the "algorithm", but it's unclear if that is inten- > tional and what the security considerations are in this regard. > > 6. If there is no port component of the URI: > > 1. Let uri-port be the default port for the protocol given by > uri-scheme. > > Otherwise: > > 2. Let uri-port be the port component of the URI. > > Per RFC 3986 schemes may define a default port but do not have to. What > if a scheme does not define a default port? Also, what if the component > is present, but is the empty string? In section 6.1 I'm told > > 1. Append a U+003A COLON code point (":") and the given port, in > base ten, to result. > > I can't give the empty string in base ten. Per RFC 3986 the port compo- > nent should be omitted when it is the empty string, which would lead to > use of the default port if any, but there is no provision in RFC 6454 > for normalising URIs and it's valid to use the empty string as value so > that is valid input into the "Origin of a URI" "algorithm". > > regards, > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From julian.reschke@gmx.de Wed Feb 13 12:54:37 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D940B21F86A8 for ; Wed, 13 Feb 2013 12:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4XV1QW0qyz5 for ; Wed, 13 Feb 2013 12:54:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BEE7621F86AE for ; Wed, 13 Feb 2013 12:54:25 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M3xZE-1Uvm072bPm-00rbjq for ; Wed, 13 Feb 2013 21:54:21 +0100 Received: (qmail invoked by alias); 13 Feb 2013 20:54:21 -0000 Received: from p54BB23EA.dip.t-dialin.net (EHLO [192.168.1.102]) [84.187.35.234] by mail.gmx.net (mp024) with SMTP; 13 Feb 2013 21:54:21 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1//u1c9QC3/09hyMt/VD+h6S0jCmxa21cISX4bpwP YD860z/RZ0ZZbg Message-ID: <511BFD7B.40101@gmx.de> Date: Wed, 13 Feb 2013 21:54:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Yoav Nir References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> <4613980CFC78314ABFD7F85CC3027721119A7198@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC3027721119A7198@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "" , Bjoern Hoehrmann , "" Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 13 Feb 2013 20:54:37 -0000 On 2013-02-13 21:43, Yoav Nir wrote: > > On Feb 13, 2013, at 10:24 PM, Julian Reschke > wrote: > >> Well. >> >> You make it sound as if it's ok to run two different registries with partly overlapping values. It's not. It's a bug in the way IANA handles this. This is what needs to be fixed. >> >> Best regards, Julian > > I don't want to turn this into a process debate, but having a provisional registry like this allows you to create interoperable implementations while the document is still at draft. I often see a push to get a document published because we need the IANA assignments for products. Yes. > Of course they could still do this with a single registry where provisional entries are somehow marked (with an asterisk?). That way we wouldn't get to a situation where we have double entries. The key thing being that both registries share the same namespace, so, by definition, an entry can not appear in both. If it does, there's a process/software problem. Of course the trivial way to do this right is to implement a *single* registry, and to just store a flag for each entry. Best regards, Julian From mnot@mnot.net Wed Feb 13 21:04:51 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C3221E80DE; Wed, 13 Feb 2013 21:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.504 X-Spam-Level: X-Spam-Status: No, score=-105.504 tagged_above=-999 required=5 tests=[AWL=-2.905, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlagYeXpRbIg; Wed, 13 Feb 2013 21:04:50 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C021E80D5; Wed, 13 Feb 2013 21:04:47 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.202.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5AFB522E200; Thu, 14 Feb 2013 00:04:39 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <511BFD7B.40101@gmx.de> Date: Thu, 14 Feb 2013 16:04:34 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <94E75F54-CA07-4276-98BD-F34C99A11A4A@mnot.net> References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> <4613980CFC78314ABFD7F85CC3027721119A7198@IL-EX10.ad.checkpoint.com> <511BFD7B.40101@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Wed, 13 Feb 2013 22:30:58 -0800 Cc: "" , Bjoern Hoehrmann , "" Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 14 Feb 2013 05:04:52 -0000 We've been talking for a while about revising 3864; it needs a lot more = than this done. Cheers, On 14/02/2013, at 7:54 AM, Julian Reschke wrote: > On 2013-02-13 21:43, Yoav Nir wrote: >>=20 >> On Feb 13, 2013, at 10:24 PM, Julian Reschke >> wrote: >>=20 >>> Well. >>>=20 >>> You make it sound as if it's ok to run two different registries with = partly overlapping values. It's not. It's a bug in the way IANA handles = this. This is what needs to be fixed. >>>=20 >>> Best regards, Julian >>=20 >> I don't want to turn this into a process debate, but having a = provisional registry like this allows you to create interoperable = implementations while the document is still at draft. I often see a push = to get a document published because we need the IANA assignments for = products. >=20 > Yes. >=20 >> Of course they could still do this with a single registry where = provisional entries are somehow marked (with an asterisk?). That way we = wouldn't get to a situation where we have double entries. >=20 > The key thing being that both registries share the same namespace, so, = by definition, an entry can not appear in both. If it does, there's a = process/software problem. >=20 > Of course the trivial way to do this right is to implement a *single* = registry, and to just store a flag for each entry. >=20 > Best regards, Julian >=20 > _______________________________________________ > Ietf-message-headers mailing list > Ietf-message-headers@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-message-headers -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Wed Feb 13 23:57:06 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C848821F871C for ; Wed, 13 Feb 2013 23:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSjMw0aLNtlw for ; Wed, 13 Feb 2013 23:57:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 063DB21F8B7C for ; Wed, 13 Feb 2013 23:57:05 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MTMoj-1UW8Bi0XWZ-00SO8Q for ; Thu, 14 Feb 2013 08:57:05 +0100 Received: (qmail invoked by alias); 14 Feb 2013 07:57:04 -0000 Received: from p54BB23EA.dip.t-dialin.net (EHLO [192.168.1.102]) [84.187.35.234] by mail.gmx.net (mp035) with SMTP; 14 Feb 2013 08:57:04 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18EjsAJ7/IEntCMCmHoBkkkaBpWCHIEdfI763rXI0 QI8M9oSoWXAbHZ Message-ID: <511C98CC.1020801@gmx.de> Date: Thu, 14 Feb 2013 08:57:00 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mark Nottingham References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> <4613980CFC78314ABFD7F85CC3027721119A7198@IL-EX10.ad.checkpoint.com> <511BFD7B.40101@gmx.de> <94E75F54-CA07-4276-98BD-F34C99A11A4A@mnot.net> In-Reply-To: <94E75F54-CA07-4276-98BD-F34C99A11A4A@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "" , Bjoern Hoehrmann , "" Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 14 Feb 2013 07:57:06 -0000 On 2013-02-14 06:04, Mark Nottingham wrote: > We've been talking for a while about revising 3864; it needs a lot more than this done. > > Cheers, > ... True, but the issue applies to all registries that are split into categories. Best regards, Julian From derhoermi@gmx.net Thu Feb 14 10:18:53 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCB121F8611 for ; Thu, 14 Feb 2013 10:18:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo2sDc4c9hsm for ; Thu, 14 Feb 2013 10:18:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA0621F8487 for ; Thu, 14 Feb 2013 10:18:51 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lefrs-1Uh0z700Ja-00qOqC for ; Thu, 14 Feb 2013 19:18:51 +0100 Received: (qmail invoked by alias); 14 Feb 2013 18:18:50 -0000 Received: from p5B233AC3.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.58.195] by mail.gmx.net (mp020) with SMTP; 14 Feb 2013 19:18:50 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19C9d5RcZNCMTQ1SjmVAU+q9YGc6cT+7GaDbkAwdu ql5v+7ALJRw2hp From: Bjoern Hoehrmann To: Graham Klyne Date: Thu, 14 Feb 2013 19:18:50 +0100 Message-ID: <6u9qh814bhlc8cfm3961dirk41ncj78s88@hive.bjoern.hoehrmann.de> References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> <6.2.5.6.2.20130213122642.0a997470@resistor.net> <511D0BB9.3010907@ninebynine.org> In-Reply-To: <511D0BB9.3010907@ninebynine.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf-message-headers@ietf.org, websec@ietf.org Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 14 Feb 2013 18:18:53 -0000 * Graham Klyne wrote: >On 13/02/2013 20:32, SM wrote: >> It's easier to fix the bug first. >> >> The following could be used: >> >> "When a new entry is recorded in the permanent message header field >> registry, IANA will remove any corresponding entries (with the same >> field name and protocol) from the provisional registry." >> >> That avoids overlapping values. > >Just for the record: > > http://www.rfc-editor.org/rfc/rfc3864.txt, section 4.3 Excellent. I gave up grepping for "same" after the first couple of hits. I agree that Graham should just go ahead and ask IANA to remove the re- dundant entry (I'd have done that, copying ietf-message-headers, had I found the text above). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From GK@ninebynine.org Thu Feb 14 08:19:21 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E521F8884; Thu, 14 Feb 2013 08:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g6dr31EDcH0; Thu, 14 Feb 2013 08:19:20 -0800 (PST) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id A995321F8831; Thu, 14 Feb 2013 08:19:20 -0800 (PST) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1U61Wk-0002a5-jK; Thu, 14 Feb 2013 16:19:14 +0000 Received: from dhcp39.zoo.ox.ac.uk ([129.67.25.217]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1U61Wj-00052f-6C; Thu, 14 Feb 2013 16:19:13 +0000 Message-ID: <511D0BB9.3010907@ninebynine.org> Date: Thu, 14 Feb 2013 16:07:21 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20130213113549.0afcce60@resistor.net> <4613980CFC78314ABFD7F85CC3027721119A6FFE@IL-EX10.ad.checkpoint.com> <511BF66F.5070100@gmx.de> <6.2.5.6.2.20130213122642.0a997470@resistor.net> In-Reply-To: <6.2.5.6.2.20130213122642.0a997470@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Mailman-Approved-At: Thu, 14 Feb 2013 19:42:29 -0800 Cc: Julian Reschke , ietf-message-headers@ietf.org, Bjoern Hoehrmann , websec@ietf.org Subject: Re: [websec] [Ietf-message-headers] HTTP 'Origin' permanent and provisional 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, 14 Feb 2013 16:19:21 -0000 On 13/02/2013 20:32, SM wrote: > Hi Julian, > At 12:24 13-02-2013, Julian Reschke wrote: >> You make it sound as if it's ok to run two different registries with partly >> overlapping values. It's not. It's a bug in the way IANA handles this. This is >> what needs to be fixed. > > It's easier to fix the bug first. > > The following could be used: > > "When a new entry is recorded in the permanent message header field > registry, IANA will remove any corresponding entries (with the same > field name and protocol) from the provisional registry." > > That avoids overlapping values. Just for the record: http://www.rfc-editor.org/rfc/rfc3864.txt, section 4.3 #g From internet-drafts@ietf.org Mon Feb 18 07:33:28 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A5F21F8BD0; Mon, 18 Feb 2013 07:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yogrfm5WwIBe; Mon, 18 Feb 2013 07:33:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600F221F893D; Mon, 18 Feb 2013 07:33:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218153328.6806.72004.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 07:33:28 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-framework-reqs-00.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 15:33:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : Web Security Framework: Problem Statement and Requiremen= ts Author(s) : Jeff Hodges Filename : draft-ietf-websec-framework-reqs-00.txt Pages : 28 Date : 2013-02-18 Abstract: Web-based malware and attacks are proliferating rapidly on the Internet. New web security mechanisms are also rapidly growing in number, although in an incoherent fashion. This document provides a brief overview of the present situation and the various seemingly piece-wise approaches being taken to mitigate the threats. It then provides an overview of requirements as presently being expressed by the community in various online and face-to-face discussions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-framework-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-framework-reqs-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Tue Feb 19 14:16:09 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C58C21F8837 for ; Tue, 19 Feb 2013 14:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei-JN5jKZqSw for ; Tue, 19 Feb 2013 14:16:09 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 901D621F8806 for ; Tue, 19 Feb 2013 14:16:08 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r1JMG7mM020823 for ; Wed, 20 Feb 2013 00:16:07 +0200 X-CheckPoint: {5123F52B-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Wed, 20 Feb 2013 00:16:07 +0200 From: Yoav Nir To: IETF WebSec WG Thread-Topic: Meeting in Orlando Thread-Index: AQHODu62OjGU75GJ80izzl2ZT+7ReQ== Date: Tue, 19 Feb 2013 22:16:05 +0000 Message-ID: <461AE8BF-4C7D-42A4-9D6D-491EE318BCD4@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.119] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <657473FB46DC4142BAE89633EA2A3E3F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] Meeting in Orlando 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, 19 Feb 2013 22:16:09 -0000 Hi all The WebSec working group will meet in Orlando, on Wednesday, March 13th at = 15:10. On the agenda are our current work items (framework requirements and key pi= nning) plus discussion of a proposed item, session continuation (or "sessio= n management") We have a two hour session, which should suffice. If anyone would like to r= equest a time slot to present or discuss some other issue, please contact T= obias and me really soon.=20 For your convenience, here are links to the drafts we will be discussing: - Framework Requirements: http://tools.ietf.org/html/draft-ietf-websec-fram= ework-reqs - Key Pinning: http://tools.ietf.org/html/draft-ietf-websec-key-pinning - X-Frame-Options: http://tools.ietf.org/html/draft-ietf-websec-x-frame-opt= ions - Session Continuation: http://tools.ietf.org/html/draft-williams-websec-se= ssion-continue-prob Yoav & Tobias WG Chairs= From internet-drafts@ietf.org Mon Feb 25 11:05:00 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6814D21F9362; Mon, 25 Feb 2013 11:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9xf8IFajHCw; Mon, 25 Feb 2013 11:05:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F581F0D0C; Mon, 25 Feb 2013 11:04:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225190458.24804.95574.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 11:04:58 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-x-frame-options-02.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:05:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IETF. Title : HTTP Header Field X-Frame-Options Author(s) : David Ross Tobias Gondrom Filename : draft-ietf-websec-x-frame-options-02.txt Pages : 11 Date : 2013-02-25 Abstract: To improve the protection of web applications against Clickjacking, this specification describes the X-Frame-Options HTTP response header field that declares a policy communicated from the server to the client browser on whether the browser may display the transmitted content in frames that are part of other web pages. This informational document serves to document the existing use and specification of this X-Frame-Options HTTP response header field. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-websec-x-frame-options-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tobias.gondrom@gondrom.org Tue Feb 26 01:43:25 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4221F8650 for ; Tue, 26 Feb 2013 01:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.287 X-Spam-Level: X-Spam-Status: No, score=-95.287 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPw+332wQKo2 for ; Tue, 26 Feb 2013 01:43:19 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id E940321F84A2 for ; Tue, 26 Feb 2013 01:43:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fP2dwQ4xl+TJQfm2uabiRyjea91KIkiFB6IxUTbzqt5pWPunsCeWETJqvo1iocT9IQDo+iT9ENb68XE8OR76s1N9lK5VdIWAz7MkIBwM+HKYyFei0WPo5apDPi1RSEuk; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 28544 invoked from network); 26 Feb 2013 10:43:15 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 26 Feb 2013 10:43:15 +0100 Message-ID: <512C83B0.6050007@gondrom.org> Date: Tue, 26 Feb 2013 17:43:12 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: websec@ietf.org References: <20130225190458.24804.95574.idtracker@ietfa.amsl.com> In-Reply-To: <20130225190458.24804.95574.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] I-D Action: draft-ietf-websec-x-frame-options-02.txt - status update 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, 26 Feb 2013 09:43:25 -0000 Hi all, just a quick update on the status of the informational X-Frame-Options draft. First, let me thank everyone for the great reviews and feedback and apologize for not posting the revised draft earlier. Was a little bit occupied with other work items and also wanted to give enough time to thoroughly incorporate all your feedback. I am very grateful for your reviews and feedback and went through all the emails and incorporated every bit of review feedback you gave me (in some cases I received feedback from more than one person on an individual paragraph in which case I chose the proposals that seemed the best fit to me). The revision includes the WGLC feedback from Adam, Alexey, Barry, Brad, Dave, Jeff, Julian, Mark, Peter and Yoav. And I think it significantly improved the quality of the draft which was before the WGLC still with a few typos and not clearly to understand sentences. I hope the revision does not reflect a good improvement. Personally, I do not think this update made any major changes to the draft, especially as it is only documenting what is out there anyway. So whether we want to re-initiate a second WGLC or submit this to the IESG for LC, will be up to you and my co-chair Yoav and potentially Alexey (if he still volunteering to play I-D shepherd for this doc). Best regards, Tobias On 26/02/13 03:04, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Security Working Group of the IETF. > > Title : HTTP Header Field X-Frame-Options > Author(s) : David Ross > Tobias Gondrom > Filename : draft-ietf-websec-x-frame-options-02.txt > Pages : 11 > Date : 2013-02-25 > > Abstract: > To improve the protection of web applications against Clickjacking, > this specification describes the X-Frame-Options HTTP response header > field that declares a policy communicated from the server to the > client browser on whether the browser may display the transmitted > content in frames that are part of other web pages. This > informational document serves to document the existing use and > specification of this X-Frame-Options HTTP response header field. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-x-frame-options-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Tue Feb 26 01:54:04 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFB321F8A25 for ; Tue, 26 Feb 2013 01:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.295 X-Spam-Level: X-Spam-Status: No, score=-95.295 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UZXTNUmU0n5 for ; Tue, 26 Feb 2013 01:54:03 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 560FD21F8A22 for ; Tue, 26 Feb 2013 01:54:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ZtQysOkNHgKoohZYNENsHZkmmyzVKXdDI+m+Yd8KwUg02LzzIRlyVsxRpfX8NJIM0By+yWH1ppemwla2vDLNfph0AEpDwWxfVrF7JXN8FtN0plcJB1gsVxU3PEZaB3ZZ; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 28647 invoked from network); 26 Feb 2013 10:54:02 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 26 Feb 2013 10:54:02 +0100 Message-ID: <512C8637.8080700@gondrom.org> Date: Tue, 26 Feb 2013 17:53:59 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: websec@ietf.org References: <461AE8BF-4C7D-42A4-9D6D-491EE318BCD4@checkpoint.com> In-Reply-To: <461AE8BF-4C7D-42A4-9D6D-491EE318BCD4@checkpoint.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] Meeting in Orlando 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, 26 Feb 2013 09:54:04 -0000 Hi all, just a quick comment: As I did not see any complicated feedback on XFO during the WGLC, I think we probably won't need time for the XFO draft in Orlando (though I will be open for any discussion topics that might still be there and any additional feedback you may have). It would be great if we could focus on the other three open drafts and achieve progress with them - Framework Requirements - Key Pinning - and the new draft on Session Continuation Especially we should now focus and try to make progress on Framework Requirements and Pinning! If you have any other topics you think are important for websec, please let Yoav and me know ASAP, so we can put them into the WG meeting agenda which we have to finish by Mar-4! Kind regards, Tobias On 20/02/13 06:16, Yoav Nir wrote: > Hi all > > The WebSec working group will meet in Orlando, on Wednesday, March 13th at 15:10. > > On the agenda are our current work items (framework requirements and key pinning) plus discussion of a proposed item, session continuation (or "session management") > > We have a two hour session, which should suffice. If anyone would like to request a time slot to present or discuss some other issue, please contact Tobias and me really soon. > > For your convenience, here are links to the drafts we will be discussing: > > - Framework Requirements: http://tools.ietf.org/html/draft-ietf-websec-framework-reqs > - Key Pinning: http://tools.ietf.org/html/draft-ietf-websec-key-pinning > - X-Frame-Options: http://tools.ietf.org/html/draft-ietf-websec-x-frame-options > - Session Continuation: http://tools.ietf.org/html/draft-williams-websec-session-continue-prob > > Yoav & Tobias > WG Chairs > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Tue Feb 26 02:25:05 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC4C21F8A3F for ; Tue, 26 Feb 2013 02:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.903 X-Spam-Level: X-Spam-Status: No, score=-94.903 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk1GvzKYZONQ for ; Tue, 26 Feb 2013 02:25:05 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8821F89DA for ; Tue, 26 Feb 2013 02:25:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=BWEMrzOw4CAVzq2R3Aw2gHqMyFoxyis1uhChF+15s57Tiz6Amk1SDoALvWt7xPFoLFjCzUlEocM5TvlwGFsLF5EvYm+P0FdNmpFRhb46hULK25TFnBesQxo67yv8CSAd; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 29928 invoked from network); 26 Feb 2013 11:25:03 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.18.138?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 26 Feb 2013 11:25:03 +0100 Message-ID: <512C8D7B.4000307@gondrom.org> Date: Tue, 26 Feb 2013 18:24:59 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: bhill@paypal-inc.com References: <370C9BEB4DD6154FA963E2F79ADC6F2E279156B0@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E279156B0@DEN-EXDDA-S12.corp.ebay.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: julian.reschke@gmx.de, websec@ietf.org Subject: Re: [websec] X-Frame-Options EBNF bug at Mozilla 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, 26 Feb 2013 10:25:05 -0000 Thanks a lot for bringing this to WG attention. It seems that I misread that point when I first wrote the draft. Actually the same is true for IE. I corrected the ABNF in the new version to reflect IE and Mozilla behavior. Best regards and thanks a lot for catching this! Tobias On 12/02/13 06:09, Hill, Brad wrote: > This bug at Mozilla was recently brought to my attention: > > https://bugzilla.mozilla.org/show_bug.cgi?id=836132 > > It seems to indicate that the specified EBNF of using a colon between "ALLOW-FROM" and the URI is not the actual behavior of most user agents that implement that functionality. > > Perhaps we should update this to reflect the predominant implementation in the field. (Internet Explorer's) > > -Brad > >> -----Original Message----- >> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On >> Behalf Of Yoav Nir >> Sent: Tuesday, January 29, 2013 5:30 AM >> To: Julian Reschke >> Cc: IETF WebSec WG >> Subject: Re: [websec] WGLC feedback for X-Frame-Options >> >> Yes. Tobias will submit a revised version soon, incorporating the WGLC >> comments. >> >> Yoav >> >> On Jan 29, 2013, at 3:20 PM, Julian Reschke >> wrote: >> >>> On 2012-11-06 18:25, Julian Reschke wrote: >>>> Hi there, >>>> >>>> here's my feedback from the HTTP/editorial point of view: >>>> ... >>> Just checking: is the WG still working on this draft? There doesn't seem to >> be any activity since October 2012... >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec From julian.reschke@gmx.de Tue Feb 26 08:06:16 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEE421F85E0 for ; Tue, 26 Feb 2013 08:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.313 X-Spam-Level: X-Spam-Status: No, score=-104.313 tagged_above=-999 required=5 tests=[AWL=-2.513, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5Z98y+VeMo5 for ; Tue, 26 Feb 2013 08:06:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id CF12821F853D for ; Tue, 26 Feb 2013 08:06:15 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lmhpd-1UkG1d4BUp-00aDay for ; Tue, 26 Feb 2013 17:06:15 +0100 Received: (qmail invoked by alias); 26 Feb 2013 16:06:14 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 26 Feb 2013 17:06:14 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/9nIQtTWT9IBZRIy7KDng4270+Cbw2ZsUsKocHFS lbITqbE4i5J30u Message-ID: <512CDD75.9030308@gmx.de> Date: Tue, 26 Feb 2013 17:06:13 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Tobias Gondrom References: <370C9BEB4DD6154FA963E2F79ADC6F2E279156B0@DEN-EXDDA-S12.corp.ebay.com> <512C8D7B.4000307@gondrom.org> In-Reply-To: <512C8D7B.4000307@gondrom.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] X-Frame-Options EBNF bug at Mozilla 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, 26 Feb 2013 16:06:16 -0000 On 2013-02-26 11:24, Tobias Gondrom wrote: > Thanks a lot for bringing this to WG attention. > It seems that I misread that point when I first wrote the draft. > Actually the same is true for IE. > I corrected the ABNF in the new version to reflect IE and Mozilla behavior. > Best regards and thanks a lot for catching this! > Tobias > ... See : > Phil Ames (New to Bugzilla) 2013-02-26 08:00:53 PST > > From http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02#section-2.2 : > > "The values are specified as ABNF strings, and therefore are case-insensitive" > > and the relevant methods in the code use "[header-value].LowerCaseEqualsLiteral(...)" so they match case-insensitively. > > One note, I think the spec is incorrect in stating that FF/Chrome support colons in 2.2.2, Chrome has no support at all for Allow-From (just my pending patch which has the same behavior as the one that led to this bug), and obviously colons are not supported here either (and the intent seems to be to not permit them). So I believe needs to be fixed; in the best case by just removing it. Best regards, Julian From tgondrom@gmx.net Tue Feb 26 08:28:24 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5521F8758 for ; Tue, 26 Feb 2013 08:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFMlD3COXrKp for ; Tue, 26 Feb 2013 08:28:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5765221F8635 for ; Tue, 26 Feb 2013 08:28:20 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MKffd-1UA6XU1htH-001wE8 for ; Tue, 26 Feb 2013 17:28:19 +0100 Received: (qmail invoked by alias); 26 Feb 2013 16:28:18 -0000 Received: from d1-162-57-143-118-on-nets.com (EHLO [10.8.18.138]) [118.143.57.162] by mail.gmx.net (mp001) with SMTP; 26 Feb 2013 17:28:18 +0100 X-Authenticated: #1793214 X-Provags-ID: V01U2FsdGVkX19Je2gHaVxJqzmM8aFJTedtTsncPLpiBcs2/49dtc kxdww8vHZyvd5D Message-ID: <512CE299.8090703@gmx.net> Date: Wed, 27 Feb 2013 00:28:09 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: julian.reschke@gmx.de References: <370C9BEB4DD6154FA963E2F79ADC6F2E279156B0@DEN-EXDDA-S12.corp.ebay.com> <512C8D7B.4000307@gondrom.org> <512CDD75.9030308@gmx.de> In-Reply-To: <512CDD75.9030308@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] X-Frame-Options EBNF bug at Mozilla 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, 26 Feb 2013 16:28:24 -0000 On 27/02/13 00:06, Julian Reschke wrote: > On 2013-02-26 11:24, Tobias Gondrom wrote: >> Thanks a lot for bringing this to WG attention. >> It seems that I misread that point when I first wrote the draft. >> Actually the same is true for IE. >> I corrected the ABNF in the new version to reflect IE and Mozilla >> behavior. >> Best regards and thanks a lot for catching this! >> Tobias >> ... > > > See : > >> Phil Ames (New to Bugzilla) 2013-02-26 08:00:53 PST >> >> From >> http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02#section-2.2 >> : >> >> "The values are specified as ABNF strings, and therefore are >> case-insensitive" >> >> and the relevant methods in the code use >> "[header-value].LowerCaseEqualsLiteral(...)" so they match >> case-insensitively. >> >> One note, I think the spec is incorrect in stating that FF/Chrome >> support colons in 2.2.2, Chrome has no support at all for Allow-From >> (just my pending patch which has the same behavior as the one that >> led to this bug), and obviously colons are not supported here either >> (and the intent seems to be to not permit them). > > So I believe > > needs to be fixed; in the best case by just removing it. I would be fine with removing this. Just for the record: >From another reviewer/security researcher, I received on Jan-9 the following feedback: "IE8+ : X-Frame-Options: ALLOW-FROM http://example.com/ IETF-draft : X-Frame-Options: ALLOW-FROM: http://example.com/ IE needs no colon between "ALLOW-FROM" and uri.Firefox and Chrome accept both." Which indicated that Firefox and Chrome would support both, which is why I kept it in. But in reflection, it probably does not add value to talk about all other possible syntax form that could be supported in some browsers due to tolerance. So I would agree with you to remove 2.2.2. (And if until Sunday I don't hear any objections, I will do so.) Best regards and thanks for the feedback, Tobias > > Best regards, Julian > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From julian.reschke@gmx.de Tue Feb 26 08:37:36 2013 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2CD21F8A05 for ; Tue, 26 Feb 2013 08:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.245 X-Spam-Level: X-Spam-Status: No, score=-104.245 tagged_above=-999 required=5 tests=[AWL=-2.445, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFreFRiJGBWd for ; Tue, 26 Feb 2013 08:37:35 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id EE1D221F89EE for ; Tue, 26 Feb 2013 08:37:34 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LiqoN-1UgQ1j14EX-00cus2 for ; Tue, 26 Feb 2013 17:37:34 +0100 Received: (qmail invoked by alias); 26 Feb 2013 16:37:34 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 26 Feb 2013 17:37:34 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19fFI0yhTVfvAhLWBUeDLJPoNvncud2A5ki+lYcIM VglXHY299B2mJJ Message-ID: <512CE4CC.6010005@gmx.de> Date: Tue, 26 Feb 2013 17:37:32 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Tobias Gondrom References: <370C9BEB4DD6154FA963E2F79ADC6F2E279156B0@DEN-EXDDA-S12.corp.ebay.com> <512C8D7B.4000307@gondrom.org> <512CDD75.9030308@gmx.de> <512CE299.8090703@gmx.net> In-Reply-To: <512CE299.8090703@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] X-Frame-Options EBNF bug at Mozilla 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, 26 Feb 2013 16:37:36 -0000 On 2013-02-26 17:28, Tobias Gondrom wrote: > On 27/02/13 00:06, Julian Reschke wrote: >> On 2013-02-26 11:24, Tobias Gondrom wrote: >>> Thanks a lot for bringing this to WG attention. >>> It seems that I misread that point when I first wrote the draft. >>> Actually the same is true for IE. >>> I corrected the ABNF in the new version to reflect IE and Mozilla >>> behavior. >>> Best regards and thanks a lot for catching this! >>> Tobias >>> ... >> >> >> See : >> >>> Phil Ames (New to Bugzilla) 2013-02-26 08:00:53 PST >>> >>> From >>> http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-02#section-2.2 >>> : >>> >>> "The values are specified as ABNF strings, and therefore are >>> case-insensitive" >>> >>> and the relevant methods in the code use >>> "[header-value].LowerCaseEqualsLiteral(...)" so they match >>> case-insensitively. >>> >>> One note, I think the spec is incorrect in stating that FF/Chrome >>> support colons in 2.2.2, Chrome has no support at all for Allow-From >>> (just my pending patch which has the same behavior as the one that >>> led to this bug), and obviously colons are not supported here either >>> (and the intent seems to be to not permit them). >> >> So I believe >> >> needs to be fixed; in the best case by just removing it. > > I would be fine with removing this. > > Just for the record: >>From another reviewer/security researcher, I received on Jan-9 the > following feedback: > "IE8+ : > > X-Frame-Options: ALLOW-FROM http://example.com/ > > IETF-draft : > > X-Frame-Options: ALLOW-FROM: http://example.com/ > > IE needs no colon between "ALLOW-FROM" and uri.Firefox and Chrome accept > both." Firefox is in the process of getting fixed. > Which indicated that Firefox and Chrome would support both, which is why > I kept it in. > But in reflection, it probably does not add value to talk about all > other possible syntax form that could be supported in some browsers due > to tolerance. > ... Indeed, we should only document a single format that will work across browsers. > So I would agree with you to remove 2.2.2. > (And if until Sunday I don't hear any objections, I will do so.) > > Best regards and thanks for the feedback, Tobias Best regards, Julian