From alexey.melnikov@isode.com Wed Feb 1 07:00:41 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2900111E8089 for ; Wed, 1 Feb 2012 07:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upf1z8rfEehe for ; Wed, 1 Feb 2012 07:00:40 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 317AD11E8073 for ; Wed, 1 Feb 2012 07:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328108438; d=isode.com; s=selector; i=@isode.com; bh=/Pw0VyTYIJsLg9Ol0bmZyKAiYcX9DqCa7uRNWdbUXy8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=K6H359SBtFXa3sI93yV0tHo4BGOpNCEmhjZ3Yi8XzmhKIJOoQb10tqUijHx33jaqfJECv0 2GUP2bLoiNlPVoE8fsTrOuZHgJIqed+mAplW8geC/CFrafTZ3Q1SxXlQiKNnWw++nqXKww 4BksfclO7q8YLG7cJYoa5lgSZ7O7/Gc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 1 Feb 2012 15:00:38 +0000 Message-ID: <4F295398.1000108@isode.com> Date: Wed, 01 Feb 2012 15:00:40 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: =JeffH References: <4F288700.3040104@KingsMountain.com> In-Reply-To: <4F288700.3040104@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] #36: HSTS: fixup references 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, 01 Feb 2012 15:00:41 -0000 On 01/02/2012 00:27, =JeffH wrote: > Alexey pointed out to me.. Hi Jeff, > > > > BTW, you moved lots of references to Informational (e.g. all IDNA > > related), I think this is incorrect - their understanding is > required in > > order to implement HSTS correctly. > > So, yes, I did (ruthlessly) move a ton of references to Informational. > I wanted to pare down the Normative references to the absolutely > necessary ones. > > Wrt IDNA refs, I'm happy to move them back to Normative if that's what > folks think. Note that in typical implementations, all the IDN > normalizations have occurred before getting to the actual HSTS > implementation. there's this text in Section 8. User Agent Processing > Model... > > This processing model assumes that the UA implements IDNA2008 > [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 > "Internationalized Domain Names for Applications (IDNA): Dependency > and Migration". It also assumes that all domain names manipulated in > this specification's context are already IDNA-canonicalized as > outlined in Section 9 "Domain Name IDNA-Canonicalization" prior to > the processing specified in this section. > > The above assumptions mean that this processing model also > specifically assumes that appropriate IDNA and Unicode validations > and character list testing have occurred on the domain names, in > conjunction with their IDNA-canonicalization, prior to the processing > specified in this section. See the IDNA-specific security > considerations in Section 14.8 "Internationalized Domain Names" for > rationale and further details. > > So, if folks indeed wish IDN refs to be Normative, I'll move 'em back. You have normative (RFC 2119) language about use of IDN related specifications in the document, IESG statement on normative/informative references apply: . > Also please point out any other refs y'all think should be in the > Normative section but aren't. > > thanks, > > =JeffH From Jeff.Hodges@KingsMountain.com Wed Feb 1 07:34:15 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C2211E8071 for ; Wed, 1 Feb 2012 07:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.037 X-Spam-Level: X-Spam-Status: No, score=-99.037 tagged_above=-999 required=5 tests=[AWL=-0.956, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXA0iV7ELrZI for ; Wed, 1 Feb 2012 07:34:14 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 9582611E80F7 for ; Wed, 1 Feb 2012 07:34:14 -0800 (PST) Received: (qmail 29051 invoked by uid 0); 1 Feb 2012 15:34:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 1 Feb 2012 15:34:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4IDdgdvFtJcHT5CTLMZkzv4wntuPnrxT7NnP24r7R8M=; b=dGhxXLL8Qhx7c7mWWpkC5ry08fbpGDVy/zJP6t8PhhHoAHqUje0Hip3HYcB39f1oMCtLrq2PtSNVvfZTKiSaxCO8ARGR5RLzFz1EW9CB7RV3pS/7ZeC9dBJcG2dn9dy6; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.48]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RscCL-0005MC-0A; Wed, 01 Feb 2012 08:34:13 -0700 Message-ID: <4F295B75.9050800@KingsMountain.com> Date: Wed, 01 Feb 2012 07:34:13 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] #36: HSTS: fixup references 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, 01 Feb 2012 15:34:15 -0000 > You have normative (RFC 2119) language about use of IDN related > specifications in the document, IESG statement on normative/informative > references apply: > . doh! good point, thanks, will fix. =JeffH From ynir@checkpoint.com Thu Feb 2 14:54:44 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1002F21F8655 for ; Thu, 2 Feb 2012 14:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+ojR53t0ngU for ; Thu, 2 Feb 2012 14:54:43 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 305D121F8650 for ; Thu, 2 Feb 2012 14:54:41 -0800 (PST) X-CheckPoint: {4F2B10D0-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q12Mse89029860 for ; Fri, 3 Feb 2012 00:54:40 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Feb 2012 00:54:40 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 3 Feb 2012 00:54:39 +0200 From: Yoav Nir To: IETF WebSec WG Date: Fri, 3 Feb 2012 00:54:39 +0200 Thread-Topic: I-D Action: draft-nir-websec-extended-origin-00.txt Thread-Index: Aczh/aUIQO/LIhDuQAuf+kjfsK/BIA== Message-ID: References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_C35E9FBD8AF74F63B7981316B985E032checkpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [websec] Fwd: I-D Action: draft-nir-websec-extended-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, 02 Feb 2012 22:54:44 -0000 --_000_C35E9FBD8AF74F63B7981316B985E032checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I have just submitted this draft. The purpose of this is to address the cas= e where a single portal hides several real servers behind it, by translatin= g their URLs into URL that seem to be from that server. In that case the same origin policy is not enforced correctly, because cook= ies and scripts from one server behind the portal (for example, a mail serv= er) can be shared and can affect pages form another server behind the same = portal. This draft proposes a header that will tell the client (browser) what the r= eal origin is, and allow the client to apply the SOP. If people find this interesting, I would like to discuss this in Paris. Any= comments will be greatly appreciated. Yoav Begin forwarded message: From: "internet-drafts@ietf.org" > Subject: I-D Action: draft-nir-websec-extended-origin-00.txt Date: February 3, 2012 12:00:21 AM GMT+02:00 To: "i-d-announce@ietf.org" > Reply-To: "internet-drafts@ietf.org" > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A More Granular Web Origin Concept Author(s) : Yoav Nir Filename : draft-nir-websec-extended-origin-00.txt Pages : 8 Date : 2012-02-02 This document defines an HTTP header that allows to partition a single origin as defined in RFC 6454 into multiple origins, so that the same origin policy applies among them. The header introduced in this document allows the portal to specify that resources that appear to be from the same origin should, in fact, be treated as though they are from different origins, by extending the 3-tuple of the origin to a 4-tuple. The user agent is expected to apply the same-origin policy according to the 4-tuple rather than the 3-tuple. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-websec-extended-origin-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-nir-websec-extended-origin-00.txt --_000_C35E9FBD8AF74F63B7981316B985E032checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi

I ha= ve just submitted this draft. The purpose of this is to address the case wh= ere a single portal hides several real servers behind it, by translating th= eir URLs into URL that seem to be from that server.

In that case the same origin policy is not enforced correctly, because co= okies and scripts from one server behind the portal (for example, a mail se= rver) can be shared and can affect pages form another server behind the sam= e portal.

This draft proposes a header that will t= ell the client (browser) what the real origin is, and allow the client to a= pply the SOP.

If people find this interesting, I w= ould like to discuss this in Paris. Any comments will be greatly appreciate= d.

Yoav

Begin forwarded message:<= /div>
From: "intern= et-drafts@ietf.org" <int= ernet-drafts@ietf.org>
Su= bject: Date: February 3, 2012 12:00:21 AM GMT+02:00


A New Internet-Draft is available fro= m the on-line Internet-Drafts directories.

Title      = ;     : A More Granular Web Origin Concept
Author(s) &nbs= p;     : Yoav Nir
Filename      =   : draft-nir-websec-extended-origin-00.txt
Pages    &nbs= p;      : 8
Date       = ;     : 2012-02-02

  This docume= nt defines an HTTP header that allows to partition a
  single= origin as defined in RFC 6454 into multiple origins, so that
 &nb= sp;the same origin policy applies among them.

  The heade= r introduced in this document allows the portal to specify
  = that resources that appear to be from the same origin should, in
 =  fact, be treated as though they are from different origins, by
&n= bsp; extending the 3-tuple of the origin to a 4-tuple.  The user = agent is
  expected to apply the same-origin policy according= to the 4-tuple
  rather than the 3-tuple.


A URL f= or this Internet-Draft is:
http://www.ietf.org/internet-dra= fts/draft-nir-websec-extended-origin-00.txt

Internet-Drafts are = also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<= br>
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/inter= net-drafts/draft-nir-websec-extended-origin-00.txt

= --_000_C35E9FBD8AF74F63B7981316B985E032checkpointcom_-- From Jeff.Hodges@KingsMountain.com Fri Feb 10 15:12:52 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E321F8533 for ; Fri, 10 Feb 2012 15:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.371 X-Spam-Level: X-Spam-Status: No, score=-99.371 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4+Oa0IRHppL for ; Fri, 10 Feb 2012 15:12:51 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id F2A3021F8514 for ; Fri, 10 Feb 2012 15:12:50 -0800 (PST) Received: (qmail 18748 invoked by uid 0); 10 Feb 2012 23:12:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 10 Feb 2012 23:12:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=eTAYfOwo5pDgVT+ez6cmovmp5HBowT3GYCATPfY7lT4=; b=FptPl8ZFwRxMkMScFQBUCnfMRk1Xeqvk1KA3SWUxsNES51AYns1F/x3vjqO2uns39fd9vWjuDt0iyhVbniXhws3E2psWswsFzwX1lI6rmGelEhxY9Gg8ThVvF0CwIapD; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.165]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Rvze5-0002zD-UK; Fri, 10 Feb 2012 16:12:49 -0700 Message-ID: <4F35A472.8060002@KingsMountain.com> Date: Fri, 10 Feb 2012 15:12:50 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: Pete Resnick , Paul Hoffman , IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 23:12:52 -0000 Thanks for reviewing the IDNA text Pete. > I really, truly wish we could avoid all reference to 5895 and UTS46. > (And this comes from a co-author of the former.) Basically, those > documents are about taking user (or other sorts of "unwashed" input) and > doing something 'magic' before handing it to something that expects > proper IDNs. Really, I'd like this kind of protocol document to say, > "What goes is this field is something that is properly pre-processed by > whatever handed it to us and if it's bogus, we're not going to do > anything to 'help' it." Note that that's what this spec attempts to do in the intro to section 7.. > This processing model assumes that the UA implements IDNA2008 > [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 11 > "Internationalized Domain Names for Applications (IDNA): Dependency > and Migration". It also assumes that all domain names manipulated in > this specification's context are already IDNA-canonicalized as > outlined in Section 8 "Domain Name IDNA-Canonicalization" prior to > the processing specified in this section. > > The above assumptions mean that this processing model also > specifically assumes that appropriate IDNA and Unicode validations > and character list testing have occured on the domain names, in > conjunction with their IDNA-canonicalization, prior to the processing > specified in this section. See the IDNA-specific security > considerations in Section 13.2 "Internationalized Domain Names" for > rationale and further details. > But I understand that this may be "happy > thoughts". If you really can't avoid talking about user input processing > in this document, I will hold my nose and say no more about it. yeah, sigh: lacking a more generalized spec laying out all that subsumed detail, it seems prudent (from a completeness perspective, at least) to include it. (I brought up concocting such a generalized how-shud-app-protocols-do-IDNA(-during-"transition-from-IDNA2003-to-2008") spec in the precis WG meeting in Taipei ietf-82, but there was a fair bit of pushback on the notion there) But, if the ADs and IESG were to decide we could get by without such language (i.e. section 10 IDNA: Dependency and Migration) in this spec we could excise it. (I'll leave it in for now) thanks again, =JeffH From tom@ritter.vg Thu Feb 16 13:01:42 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F77B21F8633 for ; Thu, 16 Feb 2012 13:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.945 X-Spam-Level: X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KZpNj2Bvqff for ; Thu, 16 Feb 2012 13:01:38 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5EB21F8617 for ; Thu, 16 Feb 2012 13:01:37 -0800 (PST) Received: by eekc41 with SMTP id c41so1103510eek.31 for ; Thu, 16 Feb 2012 13:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:content-type; bh=yzXjAyudlTGgXwv2t8p4UOSVYYKXvUoY64uOD1Bzsjs=; b=azFGy/MkBPO9w4eKk27wCKrkXl7+PJPuU9qj+v5rz+BK3mHeb8Cg09vyekL1ON2Q41 Kf4sx6K50LYxnEgDVY44D9676gViBhTl38xZvT9v81aSYIcPKc+0rCNyQJYzu4+VYbdi s7wZkm7aCK3HYAH6UVcMaGQ2GHPxCMbWe1Phk= Received: by 10.112.51.193 with SMTP id m1mr1626141lbo.58.1329426097144; Thu, 16 Feb 2012 13:01:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.38.4 with HTTP; Thu, 16 Feb 2012 13:01:17 -0800 (PST) From: Tom Ritter Date: Thu, 16 Feb 2012 16:01:17 -0500 Message-ID: To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm/PI6sGI5TDcvi4+UpD+nW2DvU+Gu0lqew4KEuAQuCcsF1BZ5J6qgBpAFwU0jw+Kqw6nBZ Subject: [websec] Outstanding Issues on draft-ietf-websec-key-pinning-01 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:01:42 -0000 In 2.3, I believe If the Public-Key-Pins response header field does not meet all four of these criteria should be "all three of these criteria" by my bullet-point count. To close up the hole with inherited parameters, in 2.2, prior to the "We pin public keys" note, add: If the SubjectPublicKeyInfo of a certificate is incomplete when taken in isolation, such as when holding a DSA key without domain parameters, a public key pin cannot be formed. And in 2.4, adding a phrase to the parenthetical comment in the big paragraph : If the connection has no errors, the UA will then apply a new correctness check: Pin Validation. To perform Pin Validation, the UA will compute the fingerprints of the SPKI structures in each certificate in the host's validated certificate chain. (The UA ignores certificates whose SPKI cannot be taken in isolation and superfluous certificates in the chain that do not form part of the validating chain.) The UA will then check that the set of these fingerprints intersects the set of fingerprints in that host's Pinning Metadata. If there is set intersection, the UA continues with the connection as normal. Otherwise, the UA MUST treat this Pin Failure as a non-recoverable error. Finally, I'd suggest the following change to 2.3.1, clarifying it's required-ness and a max-age of 0. 2.3.1. max-age max-age specifies the number of seconds, after the reception of the Public-Key-Pins HTTP Response Header, during which the UA regards the host as a Pinned Host. The delta-seconds production is specified in [rfc-2616]. max-age is a required attribute. If omitted, the UA MUST NOT note the host as a Pinned Host, and MUST discard any previously set Pinning Metadata for that host in its non-volatile store. If max-age is set to 0, the UA MUST likewise discard any previsouly set Pinning Metadata. I won't be insulted if you dislike my wording, but I think this is a complete summary of raised oustanding issues on -01. -tom From dross@microsoft.com Fri Feb 17 17:14:14 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF4711E80AE for ; Fri, 17 Feb 2012 17:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtIT8FUqclVa for ; Fri, 17 Feb 2012 17:14:14 -0800 (PST) Received: from AM1EHSOBE002.bigfish.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id C5E9811E808D for ; Fri, 17 Feb 2012 17:14:05 -0800 (PST) Received: from mail96-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Sat, 18 Feb 2012 01:14:05 +0000 Received: from mail96-am1 (localhost [127.0.0.1]) by mail96-am1-R.bigfish.com (Postfix) with ESMTP id 5EB554C00BA; Sat, 18 Feb 2012 01:14:05 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzz8275bhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail96-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dross@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail96-am1 (localhost.localdomain [127.0.0.1]) by mail96-am1 (MessageSwitch) id 1329527643114647_26669; Sat, 18 Feb 2012 01:14:03 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.252]) by mail96-am1.bigfish.com (Postfix) with ESMTP id 116D34A0051; Sat, 18 Feb 2012 01:14:03 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 18 Feb 2012 01:14:02 +0000 Received: from TK5EX14MBXC240.redmond.corp.microsoft.com ([169.254.4.36]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Fri, 17 Feb 2012 17:14:00 -0800 From: David Ross To: "Tobias Gondrom (tobias.gondrom@gondrom.org)" , IETF WebSec WG Thread-Topic: Frame-Options header and intermediate frames Thread-Index: Aczt143YGrgRy5sXSO+kYLVJtEB9ng== Date: Sat, 18 Feb 2012 01:14:00 +0000 Message-ID: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Eduardo' Vela , Michal Zalewski Subject: [websec] Frame-Options header and intermediate frames 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, 18 Feb 2012 01:14:14 -0000 Michal Zalewski and Eduardo Vela brought up an interesting scenario pertain= ing to the Frame-Options header. Specifically, if only the top level page = URL is validated w.r.t. SAMEORIGIN or ALLOW-FROM, malicious ads or other un= safe content in an intermediate frame could re-frame content from the top l= evel site for the purposes of clickjacking. In the RFC draft currently there is the following: --- SAMEORIGIN ... [TBD]current implementations do not display if the origin of the top-level-browsing-context is different than the origin of the page containing the FRAME-OPTIONS header. --- There's a good argument that sites attempting to avoid attacks such as phis= hing and clickjacking would not want to frame arbitrary content. Users rea= lly only have an easy way to make immediate and valid trust decisions about= the origin of the top level page, not frames contained within those pages.= But sites that frame arbitrary content do exist in the real world, for be= tter or worse. While there are different philosophical viewpoints on cross= -domain framing, there doesn't seem to be any reason to avoid creating a Va= lidateAllAncestors flag on Frame-Options which would instruct the browser t= o validate the URL of each hosting frame up to the top level. Given this, = sites that frame arbitrary content could at least make use of SAMEORIGIN an= d ALLOW-FROM for their intended purpose. We'd like to get the intermediate frame issue documented and describe the o= ptional ValidateAllAncestors flag in the RFC draft. David Ross dross@microsoft.com From ietf@adambarth.com Sat Feb 18 00:07:25 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DDA21E8043 for ; Sat, 18 Feb 2012 00:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKQzAFWf4YYI for ; Sat, 18 Feb 2012 00:07:24 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE0F321E8026 for ; Sat, 18 Feb 2012 00:07:23 -0800 (PST) Received: by wibhm9 with SMTP id hm9so2514774wib.31 for ; Sat, 18 Feb 2012 00:07:22 -0800 (PST) Received-SPF: pass (google.com: domain of ietf@adambarth.com designates 10.180.101.228 as permitted sender) client-ip=10.180.101.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ietf@adambarth.com designates 10.180.101.228 as permitted sender) smtp.mail=ietf@adambarth.com Received: from mr.google.com ([10.180.101.228]) by 10.180.101.228 with SMTP id fj4mr3517952wib.4.1329552442450 (num_hops = 1); Sat, 18 Feb 2012 00:07:22 -0800 (PST) Received: by 10.180.101.228 with SMTP id fj4mr3031497wib.4.1329552442383; Sat, 18 Feb 2012 00:07:22 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id by3sm1990487wib.3.2012.02.18.00.07.20 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 00:07:21 -0800 (PST) Received: by lahl5 with SMTP id l5so5310282lah.31 for ; Sat, 18 Feb 2012 00:07:20 -0800 (PST) Received-SPF: pass (google.com: domain of ietf@adambarth.com designates 10.152.132.133 as permitted sender) client-ip=10.152.132.133; Received: from mr.google.com ([10.152.132.133]) by 10.152.132.133 with SMTP id ou5mr8904671lab.46.1329552440256 (num_hops = 1); Sat, 18 Feb 2012 00:07:20 -0800 (PST) Received: by 10.152.132.133 with SMTP id ou5mr7444139lab.46.1329552440234; Sat, 18 Feb 2012 00:07:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.100.66 with HTTP; Sat, 18 Feb 2012 00:06:50 -0800 (PST) In-Reply-To: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com> References: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com> From: Adam Barth Date: Sat, 18 Feb 2012 00:06:50 -0800 Message-ID: To: David Ross Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnUHDTF+NRs1MB2VuoDoq1Zla04fc+0RuPMHqZZ4+UPKHOnPtwTTeyuv41IBrzGp+ZWIt9W Cc: Eduardo' Vela , IETF WebSec WG , Michal Zalewski Subject: Re: [websec] Frame-Options header and intermediate frames 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, 18 Feb 2012 08:07:25 -0000 On Fri, Feb 17, 2012 at 5:14 PM, David Ross wrote: > Michal Zalewski and Eduardo Vela brought up an interesting scenario perta= ining to the Frame-Options header. =A0Specifically, if only the top level p= age URL is validated w.r.t. SAMEORIGIN or ALLOW-FROM, malicious ads or othe= r unsafe content in an intermediate frame could re-frame content from the t= op level site for the purposes of clickjacking. > > In the RFC draft currently there is the following: > > --- > SAMEORIGIN > ... > =A0 =A0 =A0 =A0[TBD]current implementations do not display if the origin = of > =A0 =A0 =A0 =A0the top-level-browsing-context is different than the origi= n of > =A0 =A0 =A0 =A0the page containing the FRAME-OPTIONS header. > --- > > There's a good argument that sites attempting to avoid attacks such as ph= ishing and clickjacking would not want to frame arbitrary content. =A0Users= really only have an easy way to make immediate and valid trust decisions a= bout the origin of the top level page, not frames contained within those pa= ges. =A0But sites that frame arbitrary content do exist in the real world, = for better or worse. =A0While there are different philosophical viewpoints = on cross-domain framing, there doesn't seem to be any reason to avoid creat= ing a ValidateAllAncestors flag on Frame-Options which would instruct the b= rowser to validate the URL of each hosting frame up to the top level. =A0Gi= ven this, sites that frame arbitrary content could at least make use of SAM= EORIGIN and ALLOW-FROM for their intended purpose. > > We'd like to get the intermediate frame issue documented and describe the= optional ValidateAllAncestors flag in the RFC draft. That sounds like a reasonable way to extend the existing syntax. It's slightly ugly, but I'm not sure how worried we should be about the aesthetics. Adam From g.maone@informaction.com Sat Feb 18 00:33:07 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED6221F85FB for ; Sat, 18 Feb 2012 00:33:07 -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 me1w1ht1Zbac for ; Sat, 18 Feb 2012 00:33:06 -0800 (PST) Received: from mail2.informaction.com (mail2.informaction.com [82.103.137.214]) by ietfa.amsl.com (Postfix) with ESMTP id AE2F721F85F6 for ; Sat, 18 Feb 2012 00:33:00 -0800 (PST) Received: (qmail 4619 invoked by uid 89); 18 Feb 2012 08:32:56 -0000 Received: by simscan 1.4.0 ppid: 4612, pid: 4615, t: 0.1402s scanners: attach: 1.4.0 clamav: 0.97.2 /m: 54/d:13845 Received: from unknown (HELO ?192.168.1.196?) (g.maone@informaction.com@217.133.105.229) by ariel.informaction.com with ESMTPA; 18 Feb 2012 08:32:56 -0000 Message-ID: <4F3F623A.9060200@informaction.com> Date: Sat, 18 Feb 2012 09:32:58 +0100 From: Giorgio Maone User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adam Barth References: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eduardo' Vela , IETF WebSec WG , Michal Zalewski Subject: Re: [websec] Frame-Options header and intermediate frames 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, 18 Feb 2012 08:33:07 -0000 On 18/02/2012 09:06, Adam Barth wrote: > On Fri, Feb 17, 2012 at 5:14 PM, David Ross wrote: here's a good argument that sites attempting to avoid attacks such as phishing and clickjacking would not want to frame arbitrary content. Users really only have an easy way to make immediate and valid trust decisions about the origin of the top level page, not frames contained within those pages. But sites that frame arbitrary content do exist in the real world, for better or worse. While there are different philosophical viewpoints on cross-domain framing, there doesn't seem to be any reason to avoid creating a ValidateAllAncestors flag on Frame-Options which would instruct the browser to validate the URL of each hosting frame up to the top level. Given this, sites that frame arbitrary content could at least make use of SAMEORIGIN and ALLOW-FROM for their intended purpose. >> >> We'd like to get the intermediate frame issue documented and describe the optional ValidateAllAncestors flag in the RFC draft. > > That sounds like a reasonable way to extend the existing syntax. It's > slightly ugly Would just "AllAncestors" be clear enough? -- G From dross@microsoft.com Mon Feb 20 16:18:10 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F5321F8601 for ; Mon, 20 Feb 2012 16:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAzmcbeQdyz5 for ; Mon, 20 Feb 2012 16:18:09 -0800 (PST) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id A35E321F85F7 for ; Mon, 20 Feb 2012 16:18:09 -0800 (PST) Received: from mail54-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Feb 2012 00:18:05 +0000 Received: from mail54-tx2 (localhost [127.0.0.1]) by mail54-tx2-R.bigfish.com (Postfix) with ESMTP id D4793C02AA; Tue, 21 Feb 2012 00:18:04 +0000 (UTC) X-SpamScore: -16 X-BigFish: VS-16(zzbb2dI9371I542M1432N98dKzz1202hzz8275bhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail54-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dross@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail54-tx2 (localhost.localdomain [127.0.0.1]) by mail54-tx2 (MessageSwitch) id 1329783482442069_24098; Tue, 21 Feb 2012 00:18:02 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.252]) by mail54-tx2.bigfish.com (Postfix) with ESMTP id 6659D2A004B; Tue, 21 Feb 2012 00:18:02 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Feb 2012 00:18:01 +0000 Received: from TK5EX14MBXC240.redmond.corp.microsoft.com ([169.254.4.36]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0247.005; Tue, 21 Feb 2012 00:17:56 +0000 From: David Ross To: Giorgio Maone , Adam Barth Thread-Topic: [websec] Frame-Options header and intermediate frames Thread-Index: Aczt143YGrgRy5sXSO+kYLVJtEB9ngAPLZ4AAADppwAAhYzC0A== Date: Tue, 21 Feb 2012 00:17:55 +0000 Message-ID: <68291699F5EA8848B0EAC2E78480571FE01C5E@TK5EX14MBXC240.redmond.corp.microsoft.com> References: <68291699F5EA8848B0EAC2E78480571FDF9911@TK5EX14MBXC240.redmond.corp.microsoft.com> <4F3F623A.9060200@informaction.com> In-Reply-To: <4F3F623A.9060200@informaction.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Eduardo' Vela , IETF WebSec WG , Michal Zalewski Subject: Re: [websec] Frame-Options header and intermediate frames 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, 21 Feb 2012 00:18:10 -0000 AllAncestors sounds good to me. David Ross dross@microsoft.com -----Original Message----- From: Giorgio Maone [mailto:g.maone@informaction.com]=20 Sent: Saturday, February 18, 2012 12:33 AM To: Adam Barth Cc: David Ross; Eduardo' Vela; IETF WebSec WG; Michal Zalewski Subject: Re: [websec] Frame-Options header and intermediate frames On 18/02/2012 09:06, Adam Barth wrote: > On Fri, Feb 17, 2012 at 5:14 PM, David Ross wrote: here's a good argument that sites attempting to avoid attacks such as phish= ing and clickjacking would not want to frame arbitrary content.=20 Users really only have an easy way to make immediate and valid trust decisi= ons about the origin of the top level page, not frames contained within tho= se pages. But sites that frame arbitrary content do exist in the real worl= d, for better or worse. While there are different philosophical viewpoints= on cross-domain framing, there doesn't seem to be any reason to avoid crea= ting a ValidateAllAncestors flag on Frame-Options which would instruct the = browser to validate the URL of each hosting frame up to the top level. Giv= en this, sites that frame arbitrary content could at least make use of SAME= ORIGIN and ALLOW-FROM for their intended purpose. >> >> We'd like to get the intermediate frame issue documented and describe th= e optional ValidateAllAncestors flag in the RFC draft. > > That sounds like a reasonable way to extend the existing syntax. It's=20 > slightly ugly Would just "AllAncestors" be clear enough? -- G From James.H.Manger@team.telstra.com Wed Feb 22 16:26:37 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3CC21F85EC for ; Wed, 22 Feb 2012 16:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=-2.338, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGvGwDsmTJcP for ; Wed, 22 Feb 2012 16:26:36 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD1C21F85E3 for ; Wed, 22 Feb 2012 16:26:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,466,1325422800"; d="scan'208,217";a="63340635" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 23 Feb 2012 11:26:34 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6628"; a="51780509" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 23 Feb 2012 11:26:32 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 23 Feb 2012 11:26:31 +1100 From: "Manger, James H" To: Yoav Nir , IETF WebSec WG Date: Thu, 23 Feb 2012 11:26:29 +1100 Thread-Topic: I-D Action: draft-nir-websec-extended-origin-00.txt Thread-Index: Aczh/aUIQO/LIhDuQAuf+kjfsK/BIAPvz+Fg Message-ID: <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com> References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114EC261141WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [websec] I-D Action: draft-nir-websec-extended-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, 23 Feb 2012 00:26:37 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114EC261141WSMSG3153Vsrv_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable >> Title : A More Granular Web Origin Concept >> Filename : draft-nir-websec-extended-origin-00.txt > I have just submitted this draft. The purpose of this is to address the c= ase where a single portal hides several real servers behind it, by translat= ing their URLs into URL that seem to be from that server. > > In that case the same origin policy is not enforced correctly, because co= okies and scripts from one server behind the portal (for example, a mail se= rver) can be shared and can affect pages form another server behind the sam= e portal. > > This draft proposes a header that will tell the client (browser) what the= real origin is, and allow the client to apply the SOP. Yoav, SSL VPNs that proxy a whole bunch of web sites via a single host are indeed= a security problem as they break the same-origin protections that the indi= vidual web sites expect. However, I don=1B$B!G=1B(Bt think this draft=1B$B!= G=1B(Bs solution is the best approach. It requires browsers to fix what SSL= VPN=1B$B!G=1B(Bs have broken; and doesn=1B$B!G=1B(Bt provide much improvem= ent until the new functionality is implemented in all browsers and deployed= to most users. Wouldn=1B$B!G=1B(Bt it be better for SSL VPNs to use lots of sub-domains? F= or instance, to map internal sites to: https://a.sslvpn.example.com/webmail https://b.sslvpn.example.com/wiki/index.html https://c.sslvpn.example.com/stuff If the =1B$B!H=1B(BExtended-Origin=1B$B!I=1B(B HTTP header approach does pr= oceed=1B$B!D=1B(B 1] You don=1B$B!G=1B(Bt need multiple Extended-Origin headers for successiv= e portals in a path. A portal about to insert a header can just take into a= ccount any existing value if present. That is, insert a single Extended-Ori= gin response header that is unique for each combination of {original-domain= ; original-extended-origin-header-value}. 2] I think it would be better to serialize an extended-origin as an additio= nal sub-domain, not a fragment. The sub-domain could have a prefix so it ca= nnot (or is highly unlikely to) clash with a real sub-domain. Example: =1B$B"*=1B(B GET https://sslvpn.example.com/xyz =1B$B"+=1B(B Extended-Origin: asdhgasghd =1B$B"*=1B(B Origin: https://xb--asdhgasghd.sslvpn.example.com -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E114EC261141WSMSG3153Vsrv_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

>> Title        =    : A More Granular Web Origin Concept

>> Filename   : draft-nir-websec-extend= ed-origin-00.txt

 

> I have just submitted this dr= aft. The purpose of this is to address the case where a single portal hides= several real servers behind it, by translating their URLs into URL that se= em to be from that server.

> 

> In that case the= same origin policy is not enforced correctly, because cookies and scripts = from one server behind the portal (for example, a mail server) can be share= d and can affect pages form another server behind the same portal.

> 

> This draft proposes a header that will tell the cli= ent (browser) what the real origin is, and allow the client to apply the SO= P.

 

 <= /span>

Yoav,

 

SSL VPNs that proxy a whole bunch of web sites via a single host are indee= d a security problem as they break the same-origin protections that the ind= ividual web sites expect. However, I don=1B$B!G=1B(Bt think this draft=1B$B= !G=1B(Bs solution is the best approach. It requires browsers to fix what SS= L VPN=1B$B!G=1B(Bs have broken; and doesn=1B$B!G=1B(Bt provide much improve= ment until the new functionality is implemented in all browsers and deploye= d to most users.

&nbs= p;

Wouldn=1B$B!G=1B(Bt it be be= tter for SSL VPNs to use lots of sub-domains? For instance, to map internal= sites to:

 https://a.sslvpn.example.com/webm= ail

  https://b.sslvpn.example.com/= wiki/index.html

&nbs= p; https://c.sslvpn.example.= com/stuff

 <= /o:p>

 

If the =1B$B!H=1B(BExtended-Origin=1B$B!I=1B(B HTT= P header approach does proceed=1B$B!D=1B(B

 

1]= You don=1B$B!G=1B(Bt need multiple Extended-Origin headers for successive = portals in a path. A portal about to insert a header can just take into acc= ount any existing value if present. That is, insert a single Extended-Origi= n response header that is unique for each combination of {original-domain; = original-extended-origin-header-value}.

 

2] I= think it would be better to serialize an extended-origin as an additional = sub-domain, not a fragment. The sub-domain could have a prefix so it cannot= (or is highly unlikely to) clash with a real sub-domain. Example:

=1B$B"*=1B(B GET https://sslvpn.example.com/xyz

=1B$B"+=1B(B Extended-Origin: asdhgasghd=

=1B$B"*=1B(B Origin: http= s://xb--asdhgasghd.sslvpn.example.com

 

=  

--

James Manger

 

 

= --_000_255B9BB34FB7D647A506DC292726F6E114EC261141WSMSG3153Vsrv_-- From gerv@mozilla.org Thu Feb 23 06:47:32 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F265921F8824 for ; Thu, 23 Feb 2012 06:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a30YSp60h-2F for ; Thu, 23 Feb 2012 06:47:31 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 8535F21F8823 for ; Thu, 23 Feb 2012 06:47:31 -0800 (PST) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by dm-mail03.mozilla.org (Postfix) with ESMTP id 49A314AEDD1; Thu, 23 Feb 2012 06:47:30 -0800 (PST) Message-ID: <4F465180.6030807@mozilla.org> Date: Thu, 23 Feb 2012 14:47:28 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120118 Thunderbird/10.0 MIME-Version: 1.0 To: "Manger, James H" References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF WebSec WG Subject: Re: [websec] I-D Action: draft-nir-websec-extended-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, 23 Feb 2012 14:47:32 -0000 On 23/02/12 00:26, Manger, James H wrote: > Wouldn’t it be better for SSL VPNs to use lots of sub-domains? For > instance, to map internal sites to: > > https://a.sslvpn.example.com/webmail > > https://b.sslvpn.example.com/wiki/index.html > > https://c.sslvpn.example.com/stuff This would be much better. It would still allow the sites in some circumstances to maliciously mess with each other's cookies if they chose. I'm not entirely familiar with VPN technology, but if it were possible for VPNs everywhere always to use the same domain name for this purpose, e.g. vpn.example, then we could add *.vpn.example to the Public Suffix List and get at least some sort of protection between subdomains. Or even code in "strip off this prefix before doing domain calculations" support into clients. Just ideas :-) Gerv From ynir@checkpoint.com Thu Feb 23 06:58:45 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D35921F87B6 for ; Thu, 23 Feb 2012 06:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.168 X-Spam-Level: X-Spam-Status: No, score=-9.168 tagged_above=-999 required=5 tests=[AWL=-1.170, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7v7GoeMq713 for ; Thu, 23 Feb 2012 06:58:44 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 61A0C21F87C3 for ; Thu, 23 Feb 2012 06:58:43 -0800 (PST) X-CheckPoint: {4F464FF3-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1NEwekk023858; Thu, 23 Feb 2012 16:58:41 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 23 Feb 2012 16:58:40 +0200 From: Yoav Nir To: "Manger, James H" Date: Thu, 23 Feb 2012 16:58:43 +0200 Thread-Topic: I-D Action: draft-nir-websec-extended-origin-00.txt Thread-Index: AczyO6ClayzDt7DeQim8fjl7FzrVqw== Message-ID: <7BC9C725-9604-49C9-9A6B-B24B6B088B0A@checkpoint.com> References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_7BC9C725960449C99A6BB24B6B088B0Acheckpointcom_" MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] I-D Action: draft-nir-websec-extended-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, 23 Feb 2012 14:58:45 -0000 --_000_7BC9C725960449C99A6BB24B6B088B0Acheckpointcom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi James, thanks for reviewing. The scheme that you propose (a.sslvpn.example.com, b.sslvpn.example.com, etc.) really does w= ork. In fact, the product that my company makes offers this as an option. Sadly, our customers don't like it, hence the other option. Using multiple= FQDNs requires them to either buy multiple certificates, or a wildcard cer= tificate, both options are more expensive. Additionally this requires them = to add multiple DNS records, which for some reason they find cumbersome. About your other comments: 1) (no need for multiple headers) I agree. I think I will change this in -0= 1. I don't really think stacking portals is a good engineering idea. I just= added this for completeness, and I can replace it with text along your com= ment 2) I don't see that it makes much of a difference. I can do it either way. = Can you explain what is the advantage of this over the pseudo-fragment form= at? Thanks Yoav On Feb 23, 2012, at 2:26 AM, Manger, James H wrote: >> Title : A More Granular Web Origin Concept >> Filename : draft-nir-websec-extended-origin-00.txt > I have just submitted this draft. The purpose of this is to address the c= ase where a single portal hides several real servers behind it, by translat= ing their URLs into URL that seem to be from that server. > > In that case the same origin policy is not enforced correctly, because co= okies and scripts from one server behind the portal (for example, a mail se= rver) can be shared and can affect pages form another server behind the sam= e portal. > > This draft proposes a header that will tell the client (browser) what the= real origin is, and allow the client to apply the SOP. Yoav, SSL VPNs that proxy a whole bunch of web sites via a single host are indeed= a security problem as they break the same-origin protections that the indi= vidual web sites expect. However, I don=1B$B!G=1B(Bt think this draft=1B$B!= G=1B(Bs solution is the best approach. It requires browsers to fix what SSL= VPN=1B$B!G=1B(Bs have broken; and doesn=1B$B!G=1B(Bt provide much improvem= ent until the new functionality is implemented in all browsers and deployed= to most users. Wouldn=1B$B!G=1B(Bt it be better for SSL VPNs to use lots of sub-domains? F= or instance, to map internal sites to: https://a.sslvpn.example.com/webmail https://b.sslvpn.example.com/wiki/index.html https://c.sslvpn.example.com/stuff If the =1B$B!H=1B(BExtended-Origin=1B$B!I=1B(B HTTP header approach does pr= oceed=1B$B!D=1B(B 1] You don=1B$B!G=1B(Bt need multiple Extended-Origin headers for successiv= e portals in a path. A portal about to insert a header can just take into a= ccount any existing value if present. That is, insert a single Extended-Ori= gin response header that is unique for each combination of {original-domain= ; original-extended-origin-header-value}. 2] I think it would be better to serialize an extended-origin as an additio= nal sub-domain, not a fragment. The sub-domain could have a prefix so it ca= nnot (or is highly unlikely to) clash with a real sub-domain. Example: =1B$B"*=1B(B GET https://sslvpn.example.com/xyz =1B$B"+=1B(B Extended-Origin: asdhgasghd =1B$B"*=1B(B Origin: https://xb--asdhgasghd.sslvpn.example.com --_000_7BC9C725960449C99A6BB24B6B088B0Acheckpointcom_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi James, thanks for reviewing.

The scheme that you pro= pose (a.sslvpn.example.com, b.sslvpn.example.com, etc.) really= does work. In fact, the product that my company makes offers this as an op= tion.

Sadly, our customers don't like it, hence th= e other option.  Using multiple FQDNs requires them to either buy mult= iple certificates, or a wildcard certificate, both options are more expensi= ve. Additionally this requires them to add multiple DNS records, which for = some reason they find cumbersome.

About your other= comments:

1) (no need for multiple headers) I agr= ee. I think I will change this in -01. I don't really think stacking portal= s is a good engineering idea. I just added this for completeness, and I can= replace it with text along your comment

2) I don'= t see that it makes much of a difference. I can do it either way. Can you e= xplain what is the advantage of this over the pseudo-fragment format?
=

Thanks

Yoav

On Feb 23, 2012, at 2:26 AM, Manger, James H wrote:
<= br class=3D"Apple-interchange-newline">
= >> Title &nb= sp;         : A More Granular = Web Origin Concept
>> Filename   : dr= aft-nir-websec-extended-origin-00.txt

 
> I have just submitted this draft= . The purpose of this is to address the case where a single portal hides se= veral real servers behind it, by translating their URLs into URL that seem = to be from that server.
> 
>=  In that case the same origin policy is not enforced cor= rectly, because cookies and scripts from one server behind the portal (for = example, a mail server) can be shared and can affect pages form another ser= ver behind the same portal.
> 
> This draft proposes a header that will tell the clie= nt (browser) what the real origin is, and allow the client to apply the SOP= .
 
 
Yoav,
 <= /span>
SSL VPNs that proxy a whole bunch of web sit= es via a single host are indeed a security problem as they break the same-o= rigin protections that the individual web sites expect. However, I don=1B$B= !G=1B(Bt think this draft=1B$B!G=1B(Bs solution is the best approach. It re= quires browsers to fix what SSL VPN=1B$B!G=1B(Bs have broken; and doesn=1B$= B!G=1B(Bt provide much improvement until the new functionality is implement= ed in all browsers and deployed to most users.
 
Wouldn=1B$B!= G=1B(Bt it be better for SSL VPNs to use lots of sub-domains? For instance,= to map internal sites to:
 
If the =1B$B!H=1B(BExtended-Origin=1B$B!I=1B(B HT= TP header approach does proceed=1B$B!D=1B(B
 
1] You don=1B$B= !G=1B(Bt need multiple Extended-Origin headers for successive portals in a = path. A portal about to insert a header can just take into account any exis= ting value if present. That is, insert a single Extended-Origin response he= ader that is unique for each combination of {original-domain; original-exte= nded-origin-header-value}.
&= nbsp;
2] I think it would be better to= serialize an extended-origin as an additional sub-domain, not a fragment. = The sub-domain could have a prefix so it cannot (or is highly unlikely to) = clash with a real sub-domain. Example:
=1B$B"*=1B(B GET <= a href=3D"https://sslvpn.example.com/xyz" style=3D"color: blue; text-decora= tion: underline; ">https://sslvpn.example.com/xyz
=1B$B"+=1B(B Extended-Origin: asdhgasghd
=

= --_000_7BC9C725960449C99A6BB24B6B088B0Acheckpointcom_-- From James.H.Manger@team.telstra.com Thu Feb 23 15:35:05 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C601A21F87E5 for ; Thu, 23 Feb 2012 15:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qo4u8S9Da6a for ; Thu, 23 Feb 2012 15:35:05 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8038C21F8723 for ; Thu, 23 Feb 2012 15:35:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,472,1325422800"; d="scan'208,217";a="65371862" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 24 Feb 2012 10:35:02 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6629"; a="51620461" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 24 Feb 2012 10:35:02 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 24 Feb 2012 10:35:01 +1100 From: "Manger, James H" To: Yoav Nir Date: Fri, 24 Feb 2012 10:35:00 +1100 Thread-Topic: I-D Action: draft-nir-websec-extended-origin-00.txt Thread-Index: AczyO6ClayzDt7DeQim8fjl7FzrVqwARihCA Message-ID: <255B9BB34FB7D647A506DC292726F6E114EC261EA8@WSMSG3153V.srv.dir.telstra.com> References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com> <7BC9C725-9604-49C9-9A6B-B24B6B088B0A@checkpoint.com> In-Reply-To: <7BC9C725-9604-49C9-9A6B-B24B6B088B0A@checkpoint.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114EC261EA8WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] I-D Action: draft-nir-websec-extended-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, 23 Feb 2012 23:35:05 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114EC261EA8WSMSG3153Vsrv_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable > The scheme that you propose (a.sslvpn.example.com, b.sslvpn.example.com, etc.) really does= work. In fact, the product that my company makes offers this as an option. Good to hear. > Sadly, our customers don't like it, hence the other option. Using multip= le FQDNs requires them to either buy multiple certificates, or a wildcard c= ertificate, both options are more expensive. Additionally this requires the= m to add multiple DNS records, which for some reason they find cumbersome. Not sure that that is a good enough reason to introduce extended origins. >> 2] I think it would be better to serialize an extended-origin as an addi= tional sub-domain, not a fragment. The sub-domain could have a prefix so it= cannot (or is highly unlikely to) clash with a real sub-domain. Example: >> =1B$B"*=1B(B GET https://sslvpn.example.com/xyz >> =1B$B"+=1B(B Extended-Origin: asdhgasghd >> =1B$B"*=1B(B Origin: https://xb--asdhgasghd.sslvpn.example.com > 2) I don't see that it makes much of a difference. I can do it either way= . Can you explain what is the advantage of this over the pseudo-fragment fo= rmat? No big advantage. A pseudo-sub-domain hints at the better approach (using a= ctual sub-domains). It matches the existing syntax (which probably simplifi= es some code). -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E114EC261EA8WSMSG3153Vsrv_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

> The scheme that you prop= ose (a.sslvpn.example.com, b.sslvpn.example.com, etc.) really = does work. In fact, the product that my company makes offers this as an opt= ion.

 

Good to hear.=

 <= /p>

> Sadly, our customers don't like it, hence the other option.  Using m= ultiple FQDNs requires them to either buy multiple certificates, or a wildc= ard certificate, both options are more expensive. Additionally this require= s them to add multiple DNS records, which for some reason they find cumbers= ome.

 

Not sure that= that is a good enough reason to introduce extended origins.

 

>> 2] I think it would be better to ser= ialize an extended-origin as an additional sub-domain, not a fragment. The = sub-domain could have a prefix so it cannot (or is highly unlikely to) clas= h with a real sub-domain. Example:

>= > =1B$B"*=1B(B GET&nbs= p;https://sslvpn.example.= com/xyz

>> =1B$= B"+=1B(B Extended-Origin: asdhgasghd

>= ;> =1B$B"*=1B(B Origin: https:/= /xb--asdhgasghd.sslvpn.example.com

<= o:p> 

> 2) I don't see that it makes much of a difference= . I can do it either way. Can you explain what is the advantage of this ove= r the pseudo-fragment format?

 

No big advantage. A pseudo-sub-domain hints at the better appro= ach (using actual sub-domains). It matches the existing syntax (which proba= bly simplifies some code).

 

--

James M= anger

= --_000_255B9BB34FB7D647A506DC292726F6E114EC261EA8WSMSG3153Vsrv_-- From ynir@checkpoint.com Sun Feb 26 04:14:09 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F3021F85FD for ; Sun, 26 Feb 2012 04:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpGxm-kEhV4k for ; Sun, 26 Feb 2012 04:14:08 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C884921F85FB for ; Sun, 26 Feb 2012 04:14:07 -0800 (PST) X-CheckPoint: {4F4A1DC3-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1QCE0LE002784; Sun, 26 Feb 2012 14:14:05 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 26 Feb 2012 14:14:00 +0200 From: Yoav Nir To: "Manger, James H" Date: Sun, 26 Feb 2012 14:14:07 +0200 Thread-Topic: I-D Action: draft-nir-websec-extended-origin-00.txt Thread-Index: Acz0gB82ZoFbAcw4QyOD8khg3P9KmQ== Message-ID: References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com> <7BC9C725-9604-49C9-9A6B-B24B6B088B0A@checkpoint.com> <255B9BB34FB7D647A506DC292726F6E114EC261EA8@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114EC261EA8@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_C800BA3D89884DDAB5BB759435634746checkpointcom_" MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] I-D Action: draft-nir-websec-extended-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: Sun, 26 Feb 2012 12:14:09 -0000 --_000_C800BA3D89884DDAB5BB759435634746checkpointcom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable On Feb 24, 2012, at 1:35 AM, Manger, James H wrote: > The scheme that you propose (a.sslvpn.example.com, b.sslvpn.example.com, etc.) really does= work. In fact, the product that my company makes offers this as an option. Good to hear. > Sadly, our customers don't like it, hence the other option. Using multip= le FQDNs requires them to either buy multiple certificates, or a wildcard c= ertificate, both options are more expensive. Additionally this requires the= m to add multiple DNS records, which for some reason they find cumbersome. Not sure that that is a good enough reason to introduce extended origins. I checked the products of some of our competitors, and they seem to also of= fer both options. IMHO the cost and complexity of deployment for the user a= re valid considerations for engineering. In this case, the cost is incurred not because of technical necessity but b= ecause of the way browsers work with commercial CAs - that wildcard certifi= cates are more expensive, and multiple certificates are also more expensive= . Regardless, the cost and complexity are real. I hope to have a -01 draft ready in time, which will address your other poi= nt. Thanks again for the review Yoav --_000_C800BA3D89884DDAB5BB759435634746checkpointcom_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
On Feb 24, 2012, at 1:35 AM, Manger, James H wrote:
> = ;The scheme that you propose (a.sslvpn.examp= le.com, b.sslvpn.example.com, etc.) really does work. In fact, the product = that my company makes offers this as an option.
=
 
<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb= (31, 73, 125); ">Good to hear.
 
> Sadly,= our customers don't like it, hence the other option.  Using multiple = FQDNs requires them to either buy multiple certificates, or a wildcard cert= ificate, both options are more expensive. Additionally this requires them t= o add multiple DNS records, which for some reason they find cumbersome.
&nb= sp;
Not sure that that is a good enoug= h reason to introduce extended origins.
=

I checked the products of some of = our competitors, and they seem to also offer both options. IMHO the cost an= d complexity of deployment for the user are valid considerations for engine= ering. 

In this case, the cost is incurred no= t because of technical necessity but because of the way browsers work with = commercial CAs - that wildcard certificates are more expensive, and multipl= e certificates are also more expensive.  Regardless, the cost and comp= lexity are real.

I hope to have a -01 draft ready = in time, which will address your other point. 

Thanks again for the review

Yoav

<= /div>
= --_000_C800BA3D89884DDAB5BB759435634746checkpointcom_-- From ietf@adambarth.com Sun Feb 26 09:54:08 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8605021F8568 for ; Sun, 26 Feb 2012 09:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaLmdqRiB6Pt for ; Sun, 26 Feb 2012 09:54:08 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9EC621F855B for ; Sun, 26 Feb 2012 09:54:07 -0800 (PST) Received: by eeke51 with SMTP id e51so509487eek.31 for ; Sun, 26 Feb 2012 09:54:07 -0800 (PST) Received-SPF: pass (google.com: domain of ietf@adambarth.com designates 10.14.120.210 as permitted sender) client-ip=10.14.120.210; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ietf@adambarth.com designates 10.14.120.210 as permitted sender) smtp.mail=ietf@adambarth.com Received: from mr.google.com ([10.14.120.210]) by 10.14.120.210 with SMTP id p58mr187299eeh.98.1330278847037 (num_hops = 1); Sun, 26 Feb 2012 09:54:07 -0800 (PST) Received: by 10.14.120.210 with SMTP id p58mr142551eeh.98.1330278846846; Sun, 26 Feb 2012 09:54:06 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id s48sm47742835eem.0.2012.02.26.09.54.05 (version=SSLv3 cipher=OTHER); Sun, 26 Feb 2012 09:54:05 -0800 (PST) Received: by lagj5 with SMTP id j5so1079802lag.31 for ; Sun, 26 Feb 2012 09:54:04 -0800 (PST) Received-SPF: pass (google.com: domain of ietf@adambarth.com designates 10.112.82.6 as permitted sender) client-ip=10.112.82.6; Received: from mr.google.com ([10.112.82.6]) by 10.112.82.6 with SMTP id e6mr4411750lby.31.1330278844351 (num_hops = 1); Sun, 26 Feb 2012 09:54:04 -0800 (PST) Received: by 10.112.82.6 with SMTP id e6mr3734344lby.31.1330278844202; Sun, 26 Feb 2012 09:54:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.1.230 with HTTP; Sun, 26 Feb 2012 09:53:34 -0800 (PST) In-Reply-To: References: <20120202220021.31936.37346.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114EC261141@WSMSG3153V.srv.dir.telstra.com> <7BC9C725-9604-49C9-9A6B-B24B6B088B0A@checkpoint.com> <255B9BB34FB7D647A506DC292726F6E114EC261EA8@WSMSG3153V.srv.dir.telstra.com> From: Adam Barth Date: Sun, 26 Feb 2012 09:53:34 -0800 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlljAy7HGvaLKpuvzmYEO1cjNDvmjB9qrxgbDjWRqclwzreh5bcEdSzfb0ZcAXp0hGvSw99 Cc: IETF WebSec WG Subject: Re: [websec] I-D Action: draft-nir-websec-extended-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: Sun, 26 Feb 2012 17:54:08 -0000 2012/2/26 Yoav Nir : > > On Feb 24, 2012, at 1:35 AM, Manger, James H wrote: > >>=A0The scheme that you propose (a.sslvpn.example.com,=A0b.sslvpn.example.= com, >> etc.) really does work. In fact, the product that my company makes offer= s >> this as an option. > > Good to hear. > >>=A0Sadly, our customers don't like it, hence the other option. =A0Using >> multiple FQDNs requires them to either buy multiple certificates, or a >> wildcard certificate, both options are more expensive. Additionally this >> requires them to add multiple DNS records, which for some reason they fi= nd >> cumbersome. > > Not sure that that is a good enough reason to introduce extended origins. > > > I checked the products of some of our competitors, and they seem to also > offer both options. IMHO the cost and complexity of deployment for the us= er > are valid considerations for engineering. > > In this case, the cost is incurred not because of technical necessity but > because of the way browsers work with commercial CAs - that wildcard > certificates are more expensive, and multiple certificates are also more > expensive. =A0Regardless, the cost and complexity are real. > > I hope to have a -01 draft ready in time, which will address your other > point. > > Thanks again for the review Frankly, your proposal is very unlikely to be implemented. The engineering effort required to implement is quite large, if it's even possible. Consider, for example, that beyond just changing the browser, you'd also need to change Flash, Java, and every other plug-in that implements the same-origin policy. In addition to that complexity, there are many assumptions in browsers and in the software that surrounds browsers that origins are determined by URL. Your proposal breaks that assumption. Adam