From alexey.melnikov@isode.com Sat May 7 09:36:46 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21FDE068B for ; Sat, 7 May 2011 09:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGdWYJuyWl3v for ; Sat, 7 May 2011 09:36:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D6379E06BA for ; Sat, 7 May 2011 09:36:45 -0700 (PDT) Received: from [188.29.43.244] (188.29.43.244.threembb.co.uk [188.29.43.244]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 7 May 2011 17:36:42 +0100 Message-ID: <4DC574F9.5000809@isode.com> Date: Sat, 07 May 2011 17:36:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: websec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Review of draft-ietf-websec-mime-sniff-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: Sat, 07 May 2011 16:36:47 -0000 I have a mixed feeling on this document and I am still thinking on larger issues with it, so expect a followup message on the subject. In the meantime, below are more obvious issues: RFC 2119 is not a Normative Reference, but it should be, as the document is using MUSTs. 2. Metadata For octets received via HTTP, the Content-Type HTTP header field, if present, indicates the media type. Let the official-type be the media type indicted by the HTTP Content-Type header field, if present. If the Content-Type header field is absent or if its value cannot be interpreted as a media type (e.g. because its value doesn't contain a U+002F SOLIDUS ('/') character), then there is no official- type. I would prefer if this text is clearer that the last sentence is dealing with messages which are invalid according to RFC 2616. For octets fetched over some other protocols, e.g. FTP, there is no FTP needs an Informative reference. type information. Note: Comparisons between media types, as defined by MIME specifications, are done in an ASCII case-insensitive manner. [RFC2046] This should be a reference. Probably Normative? 3. Web Pages 2. If the octets were fetched via HTTP and there is an HTTP Content- Type header field and the value of the last such header field has octets that *exactly* match the octets contained in one of the Aren't you supposed to match media types case insensitively? following lines: 4. If the official-type is "unknown/unknown", "application/unknown", I am very curious to know which products are generating "unknown". Does application/unknown need to be registered in the media type registry? or "*/*", jump to the "unknown type" section below. 4. Text or Binary This section defines the *rules for distinguishing if a resource is text or binary*. 1. The user agent MAY wait for 512 or more octets be to arrive. Drop "be"? Note: Waiting for 512 octets octets to arrive causes the text- or-binary algorithm to be deterministic for a given sequence Does it? I think this section is showing euristics which are likely (but are not guaranteed) to produce the correct result. of octets. 4. If none of the first n octets are binary data octets then let the sniffed-type be "text/plain" and abort these steps. +-------------------------+ | Binary Data Byte Ranges | +-------------------------+ | 0x00 -- 0x08 | | 0x0B | | 0x0E -- 0x1A | | 0x1C -- 0x1F | +-------------------------+ Does this table try to cover all UTF encodings: UTF-8, UTF-16LE and UTF-16BE? 5. Unknown Type I think some of the media types listed in this section need registering, e.g. image/bmp, image/webp. But chairs can help out with this. 5.1. Signature for H.264 I think this algorithm needs to be verified by somebody with experience in H.264. I can ask for a RAI Area review. 7. Video This section defines the *rules for sniffing videos specifically*. If the first octets match one of the signatures in Section 5 for one of the following media types, then let the sniffed-type be the corresponding media type and abort these steps: o video/H264 Note that the section 5 currently doesn't define video/H264 o video/webm This media type needs registering as well. From ietf@adambarth.com Sat May 7 17:31:22 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA41E06A3 for ; Sat, 7 May 2011 17:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[AWL=-1.496, 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 vKpJOkp+4plW for ; Sat, 7 May 2011 17:31:21 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7DE069A for ; Sat, 7 May 2011 17:31:21 -0700 (PDT) Received: by yic13 with SMTP id 13so1900141yic.31 for ; Sat, 07 May 2011 17:31:20 -0700 (PDT) Received: by 10.90.149.16 with SMTP id w16mr4547035agd.138.1304814679912; Sat, 07 May 2011 17:31:19 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id x37sm4748959ana.8.2011.05.07.17.31.18 (version=SSLv3 cipher=OTHER); Sat, 07 May 2011 17:31:18 -0700 (PDT) Received: by gyf3 with SMTP id 3so1902179gyf.31 for ; Sat, 07 May 2011 17:31:18 -0700 (PDT) Received: by 10.90.21.27 with SMTP id 27mr4579479agu.6.1304814678059; Sat, 07 May 2011 17:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.65.18 with HTTP; Sat, 7 May 2011 17:30:48 -0700 (PDT) In-Reply-To: <4DC574F9.5000809@isode.com> References: <4DC574F9.5000809@isode.com> From: Adam Barth Date: Sat, 7 May 2011 17:30:48 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] Review of draft-ietf-websec-mime-sniff-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: Sun, 08 May 2011 00:31:22 -0000 Thanks for the review. On Sat, May 7, 2011 at 9:36 AM, Alexey Melnikov wrote: > I have a mixed feeling on this document and I am still thinking on larger > issues with it, so expect a followup message on the subject. I look forward to your message. > In the meantime, below are more obvious issues: > > RFC 2119 is not a Normative Reference, but it should be, as the document = is > using MUSTs. Fixed. > 2. =A0Metadata > > =A0For octets received via HTTP, the Content-Type HTTP header field, if > =A0present, indicates the media type. =A0Let the official-type be the > =A0media type indicted by the HTTP Content-Type header field, if > =A0present. =A0If the Content-Type header field is absent or if its value > =A0cannot be interpreted as a media type (e.g. because its value doesn't > =A0contain a U+002F SOLIDUS ('/') character), then there is no official- > =A0type. > > I would prefer if this text is clearer that the last sentence is dealing > with messages which are invalid according to RFC 2616. Done. > =A0For octets fetched over some other protocols, e.g. =A0FTP, there is no > > FTP needs an Informative reference. Done. > =A0type information. > > =A0Note: Comparisons between media types, as defined by MIME > =A0specifications, are done in an ASCII case-insensitive manner. > =A0[RFC2046] > > This should be a reference. Probably Normative? Done. > 3. =A0Web Pages > > =A02. =A0If the octets were fetched via HTTP and there is an HTTP Content= - > =A0 =A0 =A0Type header field and the value of the last such header field = has > =A0 =A0 =A0octets that *exactly* match the octets contained in one of the > > Aren't you supposed to match media types case insensitively? In general, yes, but this list comes from a particular buggy implementation that used exactly these octets. We could expand the scope of this bandaid, but it's unclear whether that's a good idea. > =A0 =A0 =A0following lines: > > =A04. =A0If the official-type is "unknown/unknown", "application/unknown"= , > > I am very curious to know which products are generating "unknown". I don't have that information. When collecting the data for this part of the spec, I wasn't allowed to look at the URLs associated with the types for privacy reasons. > Does application/unknown need to be registered in the media type registry= ? We certainly could register it if that would be helpful > =A0 =A0 =A0or "*/*", jump to the "unknown type" section below. > > 4. =A0Text or Binary > > =A0This section defines the *rules for distinguishing if a resource is > =A0text or binary*. > > =A01. =A0The user agent MAY wait for 512 or more octets be to arrive. > > Drop "be"? Fixed. > =A0 =A0 =A0 =A0 Note: Waiting for 512 octets octets to arrive causes the = text- > =A0 =A0 =A0 =A0 or-binary algorithm to be deterministic for a given seque= nce > > Does it? I think this section is showing euristics which are likely (but = are > not guaranteed) to produce the correct result. It's deterministic, but not necessarily "correct" (for some external notion of correctness). > =A0 =A0 =A0 =A0 of octets. > > =A04. =A0If none of the first n octets are binary data octets then let th= e > =A0 =A0 =A0sniffed-type be "text/plain" and abort these steps. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-------------------------= + > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Binary Data Byte Ranges = | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-------------------------= + > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 0x00 -- 0x08 =A0 =A0 =A0= =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 0x0B =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 0x0E -- 0x1A =A0 =A0 =A0= =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| 0x1C -- 0x1F =A0 =A0 =A0= =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-------------------------= + > > Does this table try to cover all UTF encodings: UTF-8, UTF-16LE and > UTF-16BE? This table is purely empirical. It's what folks do, for better or worse. > 5. =A0Unknown Type > > I think some of the media types listed in this section need registering, > e.g. image/bmp, image/webp. But chairs can help out with this. The MIME registry is missing lots of types that are used in the world. It would certainly be valuable to align the MIME registry with reality. > 5.1. =A0Signature for H.264 > > I think this algorithm needs to be verified by somebody with experience i= n > H.264. I can ask for a RAI Area review. Thanks. I got it from an H.264 expert at Apple and checked it on a couple example videos. However, it's the part of the document that's furtherest from my expertise. > 7. =A0Video > > =A0This section defines the *rules for sniffing videos specifically*. > > =A0If the first octets match one of the signatures in Section 5 for one > =A0of the following media types, then let the sniffed-type be the > =A0corresponding media type and abort these steps: > > =A0o =A0video/H264 > > Note that the section 5 currently doesn't define video/H264 I've already corrected this issue locally. > =A0o =A0video/webm > > This media type needs registering as well. Thanks! Adam From Internet-Drafts@ietf.org Sat May 7 17:45:02 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A87E06A3; Sat, 7 May 2011 17:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 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 hXmWszwnhaok; Sat, 7 May 2011 17:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0265EE06A6; Sat, 7 May 2011 17:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110508004502.3883.40670.idtracker@ietfa.amsl.com> Date: Sat, 07 May 2011 17:45:02 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 00:45:02 -0000 --NextPart 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 : Media Type Sniffing Author(s) : A. Barth, I. Hickson Filename : draft-ietf-websec-mime-sniff-03.txt Pages : 24 Date : 2011-05-07 Many web servers supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, user agents consider the content of HTTP responses as well as the Content-Type header fields when determining the effective media type of the response. This document describes an algorithm for determining the effective media type of HTTP responses that balances security and compatibility considerations. Please send feedback on this draft to websec@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-mime-sniff-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-websec-mime-sniff-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-07173434.I-D@ietf.org> --NextPart-- From duerst@it.aoyama.ac.jp Sun May 8 18:53:54 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2DAE0738 for ; Sun, 8 May 2011 18:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.481 X-Spam-Level: X-Spam-Status: No, score=-100.481 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 TYCfo6j3gI5S for ; Sun, 8 May 2011 18:53:53 -0700 (PDT) Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id 632BFE069A for ; Sun, 8 May 2011 18:53:52 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p491rj9W000457 for ; Mon, 9 May 2011 10:53:45 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 2c90_13bc_2ca3c994_79df_11e0_9ab5_001d0969ab06; Mon, 09 May 2011 10:53:45 +0900 Received: from [IPv6:::1] ([133.2.210.5]:56714) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 9 May 2011 10:53:42 +0900 Message-ID: <4DC74914.7030206@it.aoyama.ac.jp> Date: Mon, 09 May 2011 10:53:24 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Adam Barth References: <4DC574F9.5000809@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Review of draft-ietf-websec-mime-sniff-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, 09 May 2011 01:53:54 -0000 On 2011/05/08 9:30, Adam Barth wrote: > On Sat, May 7, 2011 at 9:36 AM, Alexey Melnikov > wrote: >> 4. If the official-type is "unknown/unknown", "application/unknown", >> >> I am very curious to know which products are generating "unknown". > > I don't have that information. When collecting the data for this part > of the spec, I wasn't allowed to look at the URLs associated with the > types for privacy reasons. Intriguing. I always thought privacy applied to clients, not to (public) servers. Or was this data collected from private servers? Regards, Martin. From ietf@adambarth.com Sun May 8 19:55:14 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFEAE06BB for ; Sun, 8 May 2011 19:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.291 X-Spam-Level: X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[AWL=-1.615, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 KuJeNcsPST43 for ; Sun, 8 May 2011 19:55:13 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74AAEE069A for ; Sun, 8 May 2011 19:55:13 -0700 (PDT) Received: by gwb20 with SMTP id 20so2112523gwb.31 for ; Sun, 08 May 2011 19:55:12 -0700 (PDT) Received: by 10.236.78.34 with SMTP id f22mr6776415yhe.428.1304909712256; Sun, 08 May 2011 19:55:12 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by mx.google.com with ESMTPS id f23sm2431930yhn.63.2011.05.08.19.55.10 (version=SSLv3 cipher=OTHER); Sun, 08 May 2011 19:55:10 -0700 (PDT) Received: by yic13 with SMTP id 13so2116419yic.31 for ; Sun, 08 May 2011 19:55:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.209.8 with SMTP id l8mr2296944agq.195.1304909710201; Sun, 08 May 2011 19:55:10 -0700 (PDT) Received: by 10.90.65.18 with HTTP; Sun, 8 May 2011 19:55:10 -0700 (PDT) Received: by 10.90.65.18 with HTTP; Sun, 8 May 2011 19:55:10 -0700 (PDT) In-Reply-To: <4DC74914.7030206@it.aoyama.ac.jp> References: <4DC574F9.5000809@isode.com> <4DC74914.7030206@it.aoyama.ac.jp> Date: Sun, 8 May 2011 19:55:10 -0700 Message-ID: From: Adam Barth To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=0016367d54a1bd92f204a2cef7bd Cc: websec@ietf.org Subject: Re: [websec] Review of draft-ietf-websec-mime-sniff-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, 09 May 2011 02:55:14 -0000 --0016367d54a1bd92f204a2cef7bd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The data was collected via opt-in anonymous usuage statistics in a web browser. The data likely covers both public and private servers and is weighted by how often those servers are visited by actual browser users. Adam On May 8, 2011 6:53 PM, Martin J. D=FCrst wrote: > On 2011/05/08 9:30, Adam Barth wrote: >> On Sat, May 7, 2011 at 9:36 AM, Alexey Melnikov >> wrote: > >>> 4. If the official-type is "unknown/unknown", "application/unknown", >>> >>> I am very curious to know which products are generating "unknown". >> >> I don't have that information. When collecting the data for this part >> of the spec, I wasn't allowed to look at the URLs associated with the >> types for privacy reasons. > > Intriguing. I always thought privacy applied to clients, not to (public) > servers. Or was this data collected from private servers? > > Regards, Martin. --0016367d54a1bd92f204a2cef7bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The data was collected via opt-in anonymous usuage statistics in a web b= rowser.=A0 The data likely covers both public and private servers and is we= ighted by how often those servers are visited by actual browser users.

Adam

On May 8, 2011 6:53 PM, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> wrot= e:
> On 2011/05/08 9:30, Adam Barth wrote:
&g= t;> On Sat, May 7, 2011 at 9:36 AM, Alexey Melnikov
>> <alexey.melnikov@i= sode.com> wrote:
>
>>> 4. If the official-typ= e is "unknown/unknown", "application/unknown",
>&= gt;>
>>> I am very curious to know which products are generating "= unknown".
>>
>> I don't have that information. = When collecting the data for this part
>> of the spec, I wasn'= t allowed to look at the URLs associated with the
>> types for privacy reasons.
>
> Intriguing. I always t= hought privacy applied to clients, not to (public)
> servers. Or was= this data collected from private servers?
>
> Regards, Mart= in.
--0016367d54a1bd92f204a2cef7bd-- From tobias.gondrom@gondrom.org Thu May 12 22:44:05 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03699E06B6 for ; Thu, 12 May 2011 22:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsorDXi8wmI7 for ; Thu, 12 May 2011 22:44:04 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id C4DBEE0657 for ; Thu, 12 May 2011 22:44:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ccGM8XgXLv/roXpP8P4ZhB2YSvtMXzAkmX1TCV8ZDo18SY0SO+irOSlWes+7vwCFcnnM57IQLLQaTwk9mOmqHlKjeJQPqeF7HT5AmXe5+/J+PR4hwF6D0pAuZUPper7k; 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 32696 invoked from network); 13 May 2011 07:44:01 +0200 Received: from unknown (HELO seraphim.heaven) (218.188.76.73) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 May 2011 07:44:01 +0200 Message-ID: <4DCCC54F.6090107@gondrom.org> Date: Fri, 13 May 2011 06:44:47 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: websec@ietf.org References: <4D66CC25.6070202@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [websec] Reviews of draft-ietf-websec-origin and principles-of-origin - until end of May X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 05:44:05 -0000 Hello dear websec fellows, to follow up on one of the tasks from our meeting in Prague is the draft http://tools.ietf.org/html/draft-ietf-websec-origin-00 and http://www.ietf.org/id/draft-abarth-principles-of-origin-00.txt At the meeting 8 people (am not gonna name them here) indicated that they still want to submit their review and feedback on this draft until May. I would like to ask you and every interested party to please do that, so that Adam can incorporate your comments for a timely progress and next version. During the meeting there was also the suggestion to merge both documents (origin and principles-of-origin) with no objections raised. If you want to raise objections against that merge please do so now, so that Adam can proceed with the next revision of the document. As the document has been reviewed thoroughly in its version before it was adopted as a WG document and seems quite stable and mature, I perceive it likely, it could go into WGLC soon. So definitely now is a good time to review it and get your comments in. All the best, Tobias (websec chair) From julian.reschke@gmx.de Fri May 13 01:47:44 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7262FE079A for ; Fri, 13 May 2011 01:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 cyr7pqy+zA2f for ; Fri, 13 May 2011 01:47:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3A95DE06C2 for ; Fri, 13 May 2011 01:47:42 -0700 (PDT) Received: (qmail invoked by alias); 13 May 2011 08:47:41 -0000 Received: from p508FADDE.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.173.222] by mail.gmx.net (mp068) with SMTP; 13 May 2011 10:47:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Ef+8TsANE7x0TrGkKiL235wH5fY6apQ46IiqNo8 MlCwFhDrRPJduR Message-ID: <4DCCF025.3070702@gmx.de> Date: Fri, 13 May 2011 10:47:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Tobias Gondrom References: <4D66CC25.6070202@stpeter.im> <4DCCC54F.6090107@gondrom.org> In-Reply-To: <4DCCC54F.6090107@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: [websec] Comments on draft-abarth-principles-of-origin-00, was: Reviews of draft-ietf-websec-origin and principles-of-origin - until end of May X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 08:47:44 -0000 On 13.05.2011 07:44, Tobias Gondrom wrote: > ... > During the meeting there was also the suggestion to merge both documents > (origin and principles-of-origin) with no objections raised. If you want > to raise objections against that merge please do so now, so that Adam > can proceed with the next revision of the document. > ... I believe that having two documents make sense; what's the benefit of merging? That being said, a few comments on draft-abarth-principles-of-origin-00: Terminology: replace "URL" by "URI" throughout. Replace "MIME type" by "media type" throughout. Add proper references. ... A: Although the DNS has hierarchical delegation, the trust relationships between host names vary by deployment. For example, at many educational institutions, students can host content at https://example.edu/~student/, but that does not mean a document authored by a student should be part of the same origin (i.e., represent the same principal) as a web application for managing grades hosted at https://grades.example.edu/. Comment: Maybe point out that under this arrangement, the URIs for different students *will* be in the same origin? ... 4. Authority It's a bit unfortunate that "authority" is used by RFC 3986 (URI) for something slightly different. If we don't want to change the term (which I assume) then it might be a good idea to clarify that this is not the same thing as the "authority" component of a URI as defined in . Best regards, Julian From alexey.melnikov@isode.com Thu May 26 11:14:52 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33C2130031 for ; Thu, 26 May 2011 11:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 XGrb7NdHrA-V for ; Thu, 26 May 2011 11:14:49 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9504013002F for ; Thu, 26 May 2011 11:14:49 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 26 May 2011 19:14:48 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4DDE986D.2030307@isode.com> Date: Thu, 26 May 2011 19:14:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: websec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Review of draft-ietf-websec-origin-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: Thu, 26 May 2011 18:14:52 -0000 I agree that section marked TBD and missing references marked "[cite]" should be fixed. Additionally: 3. Origin An origin represents a web principal. Typically, user agents determine the origin of a piece of content from the URI from which they retrieved the content. In this section, we define how to compute an origin from a URI. The origin of a URI is the value computed by the following algorithm: 1. If the URI does not use a server-based naming authority, or if the URI is not an absolute URI, then return a globally unique identifier. Does this cover URI schemes like "mailto" and "about"? I am not sure that the term "server-based naming authority" is specified anywhere. 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 return a globally unique identifier. [...] 5. Let uri-host be the idna-canonicalization of the host component of the URI. 6. If there is no port component of the URI: If mailto/about or the like are not covered above, then 5/6 are a problem. 7. Return the triple (uri-scheme, uri-host, uri-port). Should the username part be included as well, if allowed/used by the URI scheme? 6.3. User Agent Requirements o The value of the Origin header MUST be either: * The string "null" (i.e., the byte sequence %x6E, %x75, %x6C, %x6C). * The value of the Origin header in the previous-request. The user agent MUST NOT choose this option if the ascii- serialization of previous-uri is not identical to the last serialized-origin in the Origin header of the previous request. * The value of the Origin header in previous header extended with a space and the ascii-serialization of the origin of previous- uri. The user agent MUST NOT choose this option if the ascii- serialization of the origin of previous-uri is "null". Regarding the last sentence: what should be done in this case?It doesn't look like the previous quoted paragraph covers this alternative. I actually found the 3 choices to be confusing. Maybe an example demonstrating each case would help? From mnot@mnot.net Fri May 27 22:24:11 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C940E0676 for ; Fri, 27 May 2011 22:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.245 X-Spam-Level: X-Spam-Status: No, score=-105.245 tagged_above=-999 required=5 tests=[AWL=-2.646, 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 ylPwR1lD4jrh for ; Fri, 27 May 2011 22:24:11 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id EDAAFE064A for ; Fri, 27 May 2011 22:24:10 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.214.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CD98A509B3; Sat, 28 May 2011 01:24:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Sat, 28 May 2011 15:24:00 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adam Barth X-Mailer: Apple Mail (2.1084) Cc: websec Subject: Re: [websec] Principles of the Same-Origin Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 05:24:11 -0000 Hi Adam, A bit late to the party, but FWIW I like this document. It brings two questions to mind, however: * Currently, HTTPbis ticket 270 [1] moves the details of the Upgrade = process in HTTP to p2-semantics [2], which "updates" (not obsoletes) = RFC2817 [3], the definition of how to upgrade to TLS within HTTP/1.1 = (i.e., without changing the scheme). I'm wondering if a stronger = statement needs to be made; e.g., obsoleting 2817, or marking it = historic. It may also be worth mentioning in your draft as a bad = practice. * It doesn't mention CORS [4], which is a *much* more fine-grained (and = as I've said many times, undesirably chatty) definition of a trust = domain. Shouldn't there be some guidance the relationship between these = different concepts, when it's appropriate ot use them, etc? Cheers, 1. 2. 3. 4. On 22/02/2011, at 9:10 AM, Adam Barth wrote: > Pursuant to the charter, I've posted an informational draft that > "describes the same-origin security model overall:" >=20 > http://www.ietf.org/id/draft-abarth-principles-of-origin-00.txt >=20 > I don't expect this document to be very controversial. I'm sure folks > will nitpick me over renaming URL to URI and MIME types to media > types, however. :) >=20 > Feedback welcome. >=20 > Adam > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec -- Mark Nottingham http://www.mnot.net/ From ietf@adambarth.com Fri May 27 22:30:14 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4E9E0692 for ; Fri, 27 May 2011 22:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBQp46gt6czh for ; Fri, 27 May 2011 22:30:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7119CE068B for ; Fri, 27 May 2011 22:30:13 -0700 (PDT) Received: by gyf3 with SMTP id 3so1329847gyf.31 for ; Fri, 27 May 2011 22:30:12 -0700 (PDT) Received: by 10.90.126.17 with SMTP id y17mr2749471agc.64.1306560612711; Fri, 27 May 2011 22:30:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id j3sm1842479anm.13.2011.05.27.22.30.11 (version=SSLv3 cipher=OTHER); Fri, 27 May 2011 22:30:11 -0700 (PDT) Received: by yxk30 with SMTP id 30so1324169yxk.31 for ; Fri, 27 May 2011 22:30:11 -0700 (PDT) Received: by 10.91.181.17 with SMTP id i17mr2720464agp.124.1306560611071; Fri, 27 May 2011 22:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.35.6 with HTTP; Fri, 27 May 2011 22:29:41 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Fri, 27 May 2011 22:29:41 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Principles of the Same-Origin Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 05:30:14 -0000 On Fri, May 27, 2011 at 10:24 PM, Mark Nottingham wrote: > A bit late to the party, but FWIW I like this document. Thanks. Not too late. I've got the doc open in my editor as we speak. :) > It brings two questions to mind, however: > > * Currently, HTTPbis ticket 270 [1] moves the details of the Upgrade proc= ess in HTTP to p2-semantics [2], which "updates" (not obsoletes) RFC2817 [3= ], the definition of how to upgrade to TLS within HTTP/1.1 (i.e., without c= hanging the scheme). I'm wondering if a stronger statement needs to be made= ; e.g., obsoleting 2817, or marking it historic. It may also be worth menti= oning in your draft as a bad practice. Yeah, it's probably not intuitive why this causes security problems. > * It doesn't mention CORS [4], which is a *much* more fine-grained (and a= s I've said many times, undesirably chatty) definition of a trust domain. S= houldn't there be some guidance the relationship between these different co= ncepts, when it's appropriate ot use them, etc? There's a whole topic of controlled interaction between principals (e.g., CORS, postMessage). That's certainly important stuff, but I'm not clear to me how to says something helpful about it compactly. In some sense, it's "a layer above" in that it builds on top of these concepts. I'll find a way to add something in the network access section about opting into more sharing (e.g., CORS). Thanks! Adam > 1. > 2. > 3. > 4. > > > On 22/02/2011, at 9:10 AM, Adam Barth wrote: > >> Pursuant to the charter, I've posted an informational draft that >> "describes the same-origin security model overall:" >> >> http://www.ietf.org/id/draft-abarth-principles-of-origin-00.txt >> >> I don't expect this document to be very controversial. =A0I'm sure folks >> will nitpick me over renaming URL to URI and MIME types to media >> types, however. =A0:) >> >> Feedback welcome. >> >> Adam >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec > > -- > Mark Nottingham =A0 http://www.mnot.net/ > > > > From chris@lookout.net Sat May 28 09:02:16 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD19E06BC for ; Sat, 28 May 2011 09:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 drZkOs68bYM8 for ; Sat, 28 May 2011 09:02:16 -0700 (PDT) Received: from cl38.gs02.gridserver.com (cl38.gs02.gridserver.com [64.13.232.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE94E0664 for ; Sat, 28 May 2011 09:02:15 -0700 (PDT) Received: from c-71-231-104-2.hsd1.wa.comcast.net ([71.231.104.2]:40006 helo=[192.168.1.112]) by cl38.gs02.gridserver.com with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.69) (envelope-from ) id 1QQLxu-0000pg-Er; Sat, 28 May 2011 09:02:15 -0700 Message-ID: <4DE11C88.2090409@lookout.net> Date: Sat, 28 May 2011 09:02:16 -0700 From: Chris Weber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Adam Barth References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: 17546 chris@lookout.net Cc: websec Subject: Re: [websec] Principles of the Same-Origin Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 16:02:16 -0000 Some minor suggestions on section "5.2. Network Access". "Access to network resources varies depending on whether the resources are in the same origin as the document attempting to access them. Generally, reading information from another origin is forbidden." Based on the generality of the content that is allowed - images, script, style sheets, it almost seems that the above sentence could be reversed to say that "Generally, reading information from another origin is allowed." Otherwise, you could further demonstrate some of the cases where it is generally forbidden, such as with XmlHttpRequest. "However, a document is permitted use some kinds of resources retrieved from other origins. For example, a document is permitted to execute script, render images, and apply style sheets from any origin. Likewise, a document can display a document from another origin in a frame." The notion of displaying a document in a frame may be misleading in the context of this paragraph, given that the other examples grant full access to the creator document's DOM, while the document in the frame does not. "Generally, sending information to another origin is permitted. However, sending information over the network in arbitrary formats is dangerous. For this reason, user agents restrict documents to sending information using particular protocols, such as in an HTTP request without custom headers." I'm feeling a bit hungry here, can you provide some more food for thought? Some simple examples may help. I'm thinking of HTML's postMessage interface and HTML forms. Best regards, Chris Weber From chris@lookout.net Sat May 28 09:15:51 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204F3E0688 for ; Sat, 28 May 2011 09:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 k-YGVMLI2K+W for ; Sat, 28 May 2011 09:15:50 -0700 (PDT) Received: from cl07.gs02.gridserver.com (cl07.gs02.gridserver.com [64.13.232.16]) by ietfa.amsl.com (Postfix) with ESMTP id A5762E0664 for ; Sat, 28 May 2011 09:15:50 -0700 (PDT) Received: from c-71-231-104-2.hsd1.wa.comcast.net ([71.231.104.2]:40034 helo=[192.168.1.112]) by cl07.gs02.gridserver.com with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.69) (envelope-from ) id 1QQMB3-0005YB-15 for websec@ietf.org; Sat, 28 May 2011 09:15:50 -0700 Message-ID: <4DE11FB8.8050602@lookout.net> Date: Sat, 28 May 2011 09:15:52 -0700 From: Chris Weber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: websec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: 17546 chris@lookout.net Subject: Re: [websec] Principles of the Same-Origin Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 16:15:51 -0000 I wanted to suggest that section "3. Origin" include some examples presented in a clear and explicit way, such as in a list. 3.1 Examples of Resources With the Same Origin All of the following resources can be said to have the same origin. http://example.com http://example.com:80 http://example.com/path/file http://example.com In these cases each URI would be parsed into identical scheme, host, and port components. 3.2 Examples of Resources With Different Origin Each of the following resources can be said to have a different origin from the others in this list. http://example.com http://example.com:8080 http://www.example.com https://example.com:80 https://example.com http://google.com http://ietf.org In each case at least one element from the URI scheme, host, and port component will differ from the others in the list. Best regards, Chris Weber