From julian.reschke@gmx.de Tue May 1 01:10:59 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853AA21F84A1 for ; Tue, 1 May 2012 01:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=-0.925, 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 IrMgpn2gTF+l for ; Tue, 1 May 2012 01:10:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1DBCD21F844D for ; Tue, 1 May 2012 01:10:57 -0700 (PDT) Received: (qmail invoked by alias); 01 May 2012 08:10:55 -0000 Received: from p5DD973F3.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.115.243] by mail.gmx.net (mp027) with SMTP; 01 May 2012 10:10:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18wKG8a+nIwIMaLMduMSlWWAxyOLXmwIyaI7LLO17 2CY9KO+w3CP5Gp Message-ID: <4F9F9A8D.8080004@gmx.de> Date: Tue, 01 May 2012 10:10:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [websec] AppsDir review of 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: Tue, 01 May 2012 08:11:00 -0000 On 2012-05-01 04:55, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Monday, April 30, 2012 10:03 AM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-sec@tools.ietf.org >> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec >> >> On 2012-04-29 09:11, Murray S. Kucherawy wrote: >> > ... >>> Section 6.1.1: I think the "delta-seconds" should be: >>> >>> delta-seconds = 1*DIGIT >>> >>> ; defined in Section 3.3.2 of [RFC2616] ... >> >> That would copy the rule from RFC 2616 "by value". > > Why not just say "delta-seconds is defined in Section 3.3.2 of [RFC2616]" and leave out the restatement of the ABNF? Then it's truly only specified in one place. That's *exactly* what the prose ABNF rule is doing; except that it makes the in-spec ABNF complete. > ... Best regards, Julian From msk@cloudmark.com Tue May 1 06:44: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 965C621E809C for ; Tue, 1 May 2012 06:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 9o7jEtjWnLxn for ; Tue, 1 May 2012 06:44:07 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id EA10C21E80C8 for ; Tue, 1 May 2012 06:44:07 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 4dk11j0010ZaKgw01dk1Tj; Tue, 01 May 2012 06:44:07 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=WuKpwKjv c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=Pip2rxCYUeAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=iaFxQ7KoavX-IZ4UVGMA:9 a=CjuIK1q_8ugA:10 a=_RhRFcbxBZMA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Tue, 1 May 2012 06:43:37 -0700 From: "Murray S. Kucherawy" To: Julian Reschke Thread-Topic: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec Thread-Index: Ac0l10W9SlaETdSSRZWdVKRKL9SkswBVntWAAAXqgAAAGcuogAADHYPA Date: Tue, 1 May 2012 13:43:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> In-Reply-To: <4F9F9A8D.8080004@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335879847; bh=2g33PJv/rvs6t5CvpAvGBpByGHNjSlkX4yGdY9hX4bE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KFQJORl/i8yw3HgwgUVz1FKNGHy92sDnbqKuSOlncrmtHua+4NnmEgMlyYSMHcUys 2aiQHi+SBBUMKX7KavvkOooHUbYBTlTCrD4bpAIWBOtNCrvXnepjy/1jqNhOLXgUIp n72tg4AsxXFIzpYgtfCpADQYjmdTwy87TBh7LHFU= Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [websec] AppsDir review of 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: Tue, 01 May 2012 13:44:08 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, May 01, 2012 1:11 AM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-tran= sport-sec@tools.ietf.org > Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transpor= t-sec >=20 > > Why not just say "delta-seconds is defined in Section 3.3.2 of > > [RFC2616]" and leave out the restatement of the ABNF? Then it's truly > > only specified in one place. >=20 > That's *exactly* what the prose ABNF rule is doing; except that it > makes the in-spec ABNF complete. Yes, and I'm saying I think that's a risky thing to do. Granted, in this p= articular case it's pretty hard to copy and get wrong, but in general it's = safer to point to an authoritative definition of something rather than copy= it just so it's all local. -MSK From julian.reschke@gmx.de Tue May 1 12:54: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 B70E021E8424 for ; Tue, 1 May 2012 12:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.128 X-Spam-Level: X-Spam-Status: No, score=-103.128 tagged_above=-999 required=5 tests=[AWL=-0.529, 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 TbqEDoODJ-tt for ; Tue, 1 May 2012 12:54:10 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DD6CB21E8423 for ; Tue, 1 May 2012 12:54:09 -0700 (PDT) Received: (qmail invoked by alias); 01 May 2012 19:54:08 -0000 Received: from p5DD97D93.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.125.147] by mail.gmx.net (mp069) with SMTP; 01 May 2012 21:54:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+716Vsv3a7k1uUwrlZcQ5wjeBzXDKwFD9Nv+4/51 5stlNhLTlbjcbn Message-ID: <4FA03F4D.3050606@gmx.de> Date: Tue, 01 May 2012 21:53:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [websec] AppsDir review of 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: Tue, 01 May 2012 19:54:10 -0000 On 2012-05-01 15:43, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Tuesday, May 01, 2012 1:11 AM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-sec@tools.ietf.org >> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec >> >>> Why not just say "delta-seconds is defined in Section 3.3.2 of >>> [RFC2616]" and leave out the restatement of the ABNF? Then it's truly >>> only specified in one place. >> >> That's *exactly* what the prose ABNF rule is doing; except that it >> makes the in-spec ABNF complete. > > Yes, and I'm saying I think that's a risky thing to do. Granted, in this particular case it's pretty hard to copy and get wrong, but in general it's safer to point to an authoritative definition of something rather than copy it just so it's all local. Technically it *does* point to the authoritative definition. Best regards, Julian From msk@cloudmark.com Wed May 2 10:48: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 659CE21F85CC for ; Wed, 2 May 2012 10:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 NjQGF4hfISpH for ; Wed, 2 May 2012 10:48:09 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id C32B421F85C0 for ; Wed, 2 May 2012 10:48:09 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 55oU1j0010ZaKgw015oUtM; Wed, 02 May 2012 10:48:34 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=Dv3UCRD+ c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=LvckAehuu68A:10 a=5SqQFJvkn3sA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=D_u2ATCz6vtTo4ItkiYA:9 a=CjuIK1q_8ugA:10 a=_RhRFcbxBZMA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 2 May 2012 10:48:02 -0700 From: "Murray S. Kucherawy" To: Julian Reschke Thread-Topic: ABNF references (was RE: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec) Thread-Index: AQHNKIu4kW6hhbexxk28TNX+IGDrBA== Date: Wed, 2 May 2012 17:48:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> In-Reply-To: <4FA03F4D.3050606@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335980914; bh=+P8QEJ1gvwck6EoJ+KqN2sNulfQamdFCBgaNCljwKRg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Hof1xSL4lyfcNW3o3FWgXWj20QUA7/JLvqVDzIgGjUkZP5CAmbS6yzwzAGqUtITX1 a5kD3gXTQYC5YQrDQD5rDaDqY602Fn45I2D9RT0M+vNnDCUhYW0ffkQMS8sk6bK5y4 KpnoXwJEBhaIAjoPPhn4duCJ2Yhyex/YD0nlNpHc= Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: [websec] ABNF references (was RE: AppsDir review of 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: Wed, 02 May 2012 17:48:10 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, May 01, 2012 12:54 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-tran= sport-sec@tools.ietf.org > Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transpor= t-sec >=20 > Technically it *does* point to the authoritative definition. The real issue here is that we don't have a (ahem) standard way to import A= BNF definitions from other documents. The specific problem in this case to= me is twofold: 1) Section 4 of RFC5234 specifies that the prose-val construction is a mech= anism of "last resort", which I take to mean one uses it only when the thin= g you need to describe is sufficiently complicated that it's easier to desc= ribe in English than in ABNF. I don't think "1*DIGIT" qualifies, nor does = an import from another document because we do it all the time with a non-AB= NF sentence. (Now, if that admonition in RFC5234 needs clarification, then= let's do that.) 2) There's a common axiom that says it's safer to refer to a definition rat= her than to copy it. I understand that we're up against reader convenience= here, which can suffer when a copy isn't used, especially when the definit= ions being recycled are scattered throughout many documents. Although I'm = infinitely confident the string "1*DIGIT" was copied correctly from RFC2616= to this draft, I'm concerned that approval of this use will eventually lea= d to a case where some author uses prose-val to copy something more complex= in the name of reader convenience, and get it wrong, and now we have two d= ocuments that don't agree on the definition of something. That may or may = not have serious side effects. What I would prefer in this case is to say one of these: "delta-seconds" in defined in Section 3.3.2 of RFC2616. delta-seconds =3D I strongly prefer the former. I still think the latter is an improper use = of prose-val, but at least the ABNF itself isn't copied there. To address the larger question, we definitely have to have some conversatio= n about the right way to do this in general. Perhaps another draft that up= dates RFC5234 which presents a consensus view of the right, safe, convenien= t way to do so would be useful. Perhaps further we just say that what you'= re doing here is the new official way to do so, where the ABNF inside the p= rose-val is a convenience copy with the understanding that the referenced d= efinition is authoritative if somehow they diverged. =20 For example, we could standardize on a prose-val whose contents are of the = form: name =3D < [ABNF] "from " [ "Section " 1*DIGIT *( "." 1*DIGIT) " of " ] "R= FC" 1*DIGIT > This would be interpreted as: "name" is defined in the specified RFC, possi= bly down to the specified Section. If ABNF is there, it is a convenience c= opy; the referenced document contains the official definition of "name". A= nd people would just discourage the convenience copy in cases where it's no= n-trivial. (We'd have to bang on this a bit to allow importing from docume= nts that aren't RFCs, but you get the idea.) I'd be happy to write that up as something that updates 5234 if people thin= k that's a good idea. -MSK From julian.reschke@gmx.de Wed May 2 11:34: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 AC86411E8083 for ; Wed, 2 May 2012 11:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.062 X-Spam-Level: X-Spam-Status: No, score=-103.062 tagged_above=-999 required=5 tests=[AWL=-0.462, 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 lfWLLl54FKeh for ; Wed, 2 May 2012 11:34:08 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 756BC11E8081 for ; Wed, 2 May 2012 11:34:07 -0700 (PDT) Received: (qmail invoked by alias); 02 May 2012 18:34:06 -0000 Received: from p5DD96838.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.104.56] by mail.gmx.net (mp070) with SMTP; 02 May 2012 20:34:06 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX192yUdWFVt2IeXqnf+Hp0TZeX6r+WCvxzC/xq9mD6 h/qogz947+Gd+g Message-ID: <4FA17E13.5070207@gmx.de> Date: Wed, 02 May 2012 20:33:55 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-ietf-websec-strict-transport-sec@tools.ietf.org" , "websec@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [websec] ABNF references (was RE: AppsDir review of 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: Wed, 02 May 2012 18:34:08 -0000 On 2012-05-02 19:48, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Tuesday, May 01, 2012 12:54 PM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org; websec@ietf.org; draft-ietf-websec-strict-transport-sec@tools.ietf.org >> Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec >> >> Technically it *does* point to the authoritative definition. > > The real issue here is that we don't have a (ahem) standard way to import ABNF definitions from other documents. The specific problem in this case to me is twofold: Exactly. It would be good to have that. > 1) Section 4 of RFC5234 specifies that the prose-val construction is a mechanism of "last resort", which I take to mean one uses it only when the thing you need to describe is sufficiently complicated that it's easier to describe in English than in ABNF. I don't think "1*DIGIT" qualifies, nor does an import from another document because we do it all the time with a non-ABNF sentence. (Now, if that admonition in RFC5234 needs clarification, then let's do that.) The choices we have are: a) import "by value" (copy the ABNF rule) b) import "by reference" For b), I see two options: b1) have a prose rule for the imported ABNF rule, or b2) just say it in prose. The advantage of b1 over b2 is that an ABNF checker can check whether the ABNF is complete (for some value of "complete"). I believe that using the prose rule for that is strictly better than having an incomplete ABNF, but it would certainly be cool to have something better than that. > 2) There's a common axiom that says it's safer to refer to a definition rather than to copy it. I understand that we're up against reader convenience here, which can suffer when a copy isn't used, especially when the definitions being recycled are scattered throughout many documents. Although I'm infinitely confident the string "1*DIGIT" was copied correctly from RFC2616 to this draft, I'm concerned that approval of this use will eventually lead to a case where some author uses prose-val to copy something more complex in the name of reader convenience, and get it wrong, and now we have two documents that don't agree on the definition of something. That may or may not have serious side effects. > > What I would prefer in this case is to say one of these: > > "delta-seconds" in defined in Section 3.3.2 of RFC2616. > > delta-seconds = > > I strongly prefer the former. I still think the latter is an improper use of prose-val, but at least the ABNF itself isn't copied there. > > To address the larger question, we definitely have to have some conversation about the right way to do this in general. Perhaps another draft that updates RFC5234 which presents a consensus view of the right, safe, convenient way to do so would be useful. Perhaps further we just say that what you're doing here is the new official way to do so, where the ABNF inside the prose-val is a convenience copy with the understanding that the referenced definition is authoritative if somehow they diverged. > > For example, we could standardize on a prose-val whose contents are of the form: > > name =< [ABNF] "from " [ "Section " 1*DIGIT *( "." 1*DIGIT) " of " ] "RFC" 1*DIGIT> Something like that, yes. It would help automated checkers a lot. > This would be interpreted as: "name" is defined in the specified RFC, possibly down to the specified Section. If ABNF is there, it is a convenience copy; the referenced document contains the official definition of "name". And people would just discourage the convenience copy in cases where it's non-trivial. (We'd have to bang on this a bit to allow importing from documents that aren't RFCs, but you get the idea.) > > I'd be happy to write that up as something that updates 5234 if people think that's a good idea. Best regards, Julian From Jeff.Hodges@KingsMountain.com Wed May 2 11:56:13 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 3AB0221F84CF for ; Wed, 2 May 2012 11:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1CcKkg8lPdX for ; Wed, 2 May 2012 11:56:12 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 4566C21F847E for ; Wed, 2 May 2012 11:56:12 -0700 (PDT) Received: (qmail 16424 invoked by uid 0); 2 May 2012 18:56:11 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 2 May 2012 18:56:11 -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=ltgPC35izhlhtMgU9ijW6S6xJxPSop/ZVQE6dEM2O8U=; b=TXCYzJgA6W1RFxdzc1gsEGWgBab2qryylS6KPXw+xRD9wJjUh7kUufB2tRMn+7K+UzagJUlW1xXP8NbX4/WGQlADDmULKxElGuikwTMMHOnu4n9GDourQqEFxszRm9PL; Received: from [205.248.100.252] (helo=[10.69.6.184]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SPeih-0007uN-8U; Wed, 02 May 2012 12:56:11 -0600 Message-ID: <4FA18343.2050901@KingsMountain.com> Date: Wed, 02 May 2012 11:56:03 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Alexey Melnikov , 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 205.248.100.252 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] IETF WebSec WG 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, 02 May 2012 18:56:13 -0000 Hi Alexey, thanks for the review, apologies for latency. > The two directives defined in this specification are described below. > The overall requirements for directives are: > > o The order of appearance of directives is not significant. > > o All directives MUST appear only once in an STS header field. > > o Directive names are case-insensitive. > > o UAs MUST ignore any STS header fields containing directives that > do not conform to their ABNF definition. > > Should this list also say something about how unrecognized directives > should be treated? I.e. are they ignored by default, is the whole > STS header field ignored, etc. Does the last bullet item above not address those questions? > Additional directives extending the semantic functionality of the STS > header field may be defined in other specifications (which "update" > this specification), > > Is this a requirement on future extensions? > (In general "updating" this specification using Updates: in the header > of the relevant RFC > is a) a heavy weight mechanism (it prevents Experimental extensions) and > b) this seems > like a wrong mechanism anyway, as Updates usually means that the > document being > updated can't be implemented without the document which updates it.) We can place in the above para whatever we/you/ourADs wish. Suggestions welcome. > 8.3. Errors in Secure Transport Establishment > > When connecting to a Known HSTS Host, the UA MUST terminate the > connection (see also Section 11 "User Agent Implementation Advice", > below) if there are any errors (e.g., certificate errors), whether > "warning" or "fatal" or any other error level, with the underlying > secure transport. This includes any issues with certificate > revocation checking whether via the Certificate Revocation List (CRL) > [RFC5280], or via the Online Certificate Status Protocol (OCSP) > [RFC2560]. > > This was discussed in Paris, but I had this in my notes already and would > like to emphasize this: I assume that explaining the reason for the failure > to the user (without letting the user to opt-out) is Ok? I think the > document > needs to make it clear that this is not prohibited. the above is being discussed in the "Showing errors in HSTS" thread. > 10.3. Implications of includeSubDomains > > For example, certification authorities often offer their CRL > distribution and OCSP services over plain HTTP, and sometimes at a > > The first use of OCSP needs an Informative reference. It's referenced way up at beginning of spec, but now ref'd here also in my -07 working copy. > subdomain of a publicly-available web application which may be > secured by TLS/SSL. For example, is a > publicly-available web application for "Example CA", a certification > authority. Customers use this web application to register their > public keys and obtain certificates. Example CA generates > certificates for customers containing > as the value for the "CRL > Distribution Points" and "Authority Information Access:OCSP" > certificate fields. > > 13. Internationalized Domain Names for Applications (IDNA): Dependency > and Migration > > IDNA2008 obsoletes IDNA2003, but there are differences between the > two specifications, and thus there can be differences in processing > (e.g., converting) domain name labels that have been registered under > one from those registered under the other. There will be a > transition period of some time during which IDNA2003-based domain > name labels will exist in the wild. User agents SHOULD implement > IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of > [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. > > I might be kicking a dead horse here, but MAY sounds a bit weak. > I especially dislike having the choice between 2 incompatible specs, > I think this might cause some interop problems. As far as I can tell, having had fairly extensive discussions with IDNA folk both privately and on various lists such as idna-update@, the above relects the the unfortunate state of the world at this time. For instance, Pete Resnick signed off on the language in the spec in this message to websec@... Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec https://www.ietf.org/mail-archive/web/websec/current/msg01015.html we should probably fork off any further discussion on this topic to that thread. > Also, does "in order to facilitate their IDNA transition" apply > to the second reference or to both references? It applies to both. One may implement [RFC5895] /or/ [UTS46] to facilitate one's IDNA transition (as I understand it). again, followups on this item and the above should probably be in the "Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec" thread here on websec@. > In Section 14.5: NTP needs an Informative Reference. fixed in my -07 working copy. > 15. IANA Considerations > > Below is the Internet Assigned Numbers Authority (IANA) Provisional > > I think here (and below) we should use "Permanent" registration for this > header field. > > Message Header Field registration information per [RFC3864]. > > Header field name: Strict-Transport-Security > Applicable protocol: HTTP > Status: provisional > Author/Change controller: TBD > Specification document(s): this one fixed in my -07 working copy thanks again, =JeffH From fielding@gbiv.com Wed May 2 12:32: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 75DE021E80BD; Wed, 2 May 2012 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.009 X-Spam-Level: X-Spam-Status: No, score=-106.009 tagged_above=-999 required=5 tests=[AWL=-3.410, 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 IJd4y3uoxPKq; Wed, 2 May 2012 12:32:40 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6421E8056; Wed, 2 May 2012 12:32:40 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 1A1662AC07A; Wed, 2 May 2012 12:32:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=xgrHMQnursLACXgB tVS+x63EGzggrYWDpwgHeQgnifClaM4g3WRz52lNJ604vPSwmyBc58qrRM/+U+RT 9KV6YD9zNvd2QFTDwT9wAfQ6BKMfWGx6N4pFLjvzhpaeshOoxlwrE8yZFkbY0Uzu VFjXbvA9i7EgeFDRO8I/OId11ko= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=SDGvZ0OzO3ZRMborggBvoT64Kvs=; b=g8Rk5yVTB0zF6hGd56uw76UlTD6Q U9zYlDO3Psc4XSpQ5C0bkqg8DKWheErP8GoAoNScO+x8a5FQechdYdMsK0SNYZFf 7Rl1iWUbB1sUxs8TrWlJDFud9WYLI3EBFIpIKLnRyhLOrRysoAdiw5Y5tLqHLT0w ++5j6opLbmxoeSw= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 7EB8D2AC0A9; Wed, 2 May 2012 12:32:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> Date: Wed, 2 May 2012 12:32:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1257) Cc: Julian Reschke , IETF WebSec WG , IETF Apps Discuss Subject: Re: [websec] [apps-discuss] ABNF references (was RE: AppsDir review of 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: Wed, 02 May 2012 19:32:41 -0000 On May 2, 2012, at 10:48 AM, Murray S. Kucherawy wrote: > 2) There's a common axiom that says it's safer to refer to a = definition rather than to copy it. I think we should recognize that as a false axiom and move on. We should refer to orthogonal definitions that are subject to independent change control -- e.g., protocol elements that are defined in another spec because they change at a different rate than the referring spec or are used by multiple specs. We should copy a definition by value if the referring spec depends on the definition (does not allow the parser to change even if some other spec were to define it and later extend it). My preference is to not use prose definitions at all -- I used them as a crutch when I first started writing IETF specs in 1994, and they burned me every time. And if we go down the slippery slope, I would love to have a formal definition of set reduction, as in ALPHA =3D ALPHANUM - DIGIT since I very commonly need rules that only differ by one or two characters being removed from the allowed set. ....Roy= From Jeff.Hodges@KingsMountain.com Wed May 2 12:46: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 04D6021F84EC for ; Wed, 2 May 2012 12:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id natDvRp5rz97 for ; Wed, 2 May 2012 12:46:14 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id EAEA121F84E7 for ; Wed, 2 May 2012 12:46:13 -0700 (PDT) Received: (qmail 23593 invoked by uid 0); 2 May 2012 19:46:03 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 2 May 2012 19:46:03 -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=XZpc7Nu8xv9OQle/SjrM56J8KTuFY0Oe+GbS/Fd3/oQ=; b=385aDkAunjC/D3a4ByBc44+IrM3snSHQciv4DszbiZujAUfq/d8dKALilTYMo/vllF/OzxPz3jKlKjQSecSegx63W2muysQlsaSe0PiV1Xp/STG1J1touZRWZOkpcgMJ; Received: from [205.248.100.252] (helo=[10.69.6.184]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SPfUv-0001tP-UC; Wed, 02 May 2012 13:46:02 -0600 Message-ID: <4FA18EF1.9040206@KingsMountain.com> Date: Wed, 02 May 2012 12:45:53 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Alexey Melnikov , 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 205.248.100.252 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 19:46:15 -0000 [ resent with correct Subject: ] Hi Alexey, thanks for the review, apologies for latency. > The two directives defined in this specification are described below. > The overall requirements for directives are: > > o The order of appearance of directives is not significant. > > o All directives MUST appear only once in an STS header field. > > o Directive names are case-insensitive. > > o UAs MUST ignore any STS header fields containing directives that > do not conform to their ABNF definition. > > Should this list also say something about how unrecognized directives > should be treated? I.e. are they ignored by default, is the whole > STS header field ignored, etc. Does the last bullet item above not address those questions? > Additional directives extending the semantic functionality of the STS > header field may be defined in other specifications (which "update" > this specification), > > Is this a requirement on future extensions? > (In general "updating" this specification using Updates: in the header > of the relevant RFC > is a) a heavy weight mechanism (it prevents Experimental extensions) and > b) this seems > like a wrong mechanism anyway, as Updates usually means that the > document being > updated can't be implemented without the document which updates it.) We can place in the above para whatever we/you/ourADs wish. Suggestions welcome. > 8.3. Errors in Secure Transport Establishment > > When connecting to a Known HSTS Host, the UA MUST terminate the > connection (see also Section 11 "User Agent Implementation Advice", > below) if there are any errors (e.g., certificate errors), whether > "warning" or "fatal" or any other error level, with the underlying > secure transport. This includes any issues with certificate > revocation checking whether via the Certificate Revocation List (CRL) > [RFC5280], or via the Online Certificate Status Protocol (OCSP) > [RFC2560]. > > This was discussed in Paris, but I had this in my notes already and would > like to emphasize this: I assume that explaining the reason for the failure > to the user (without letting the user to opt-out) is Ok? I think the > document > needs to make it clear that this is not prohibited. the above is being discussed in the "Showing errors in HSTS" thread. > 10.3. Implications of includeSubDomains > > For example, certification authorities often offer their CRL > distribution and OCSP services over plain HTTP, and sometimes at a > > The first use of OCSP needs an Informative reference. It's referenced way up at beginning of spec, but now ref'd here also in my -07 working copy. > subdomain of a publicly-available web application which may be > secured by TLS/SSL. For example, is a > publicly-available web application for "Example CA", a certification > authority. Customers use this web application to register their > public keys and obtain certificates. Example CA generates > certificates for customers containing > as the value for the "CRL > Distribution Points" and "Authority Information Access:OCSP" > certificate fields. > > 13. Internationalized Domain Names for Applications (IDNA): Dependency > and Migration > > IDNA2008 obsoletes IDNA2003, but there are differences between the > two specifications, and thus there can be differences in processing > (e.g., converting) domain name labels that have been registered under > one from those registered under the other. There will be a > transition period of some time during which IDNA2003-based domain > name labels will exist in the wild. User agents SHOULD implement > IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of > [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. > > I might be kicking a dead horse here, but MAY sounds a bit weak. > I especially dislike having the choice between 2 incompatible specs, > I think this might cause some interop problems. As far as I can tell, having had fairly extensive discussions with IDNA folk both privately and on various lists such as idna-update@, the above relects the the unfortunate state of the world at this time. For instance, Pete Resnick signed off on the language in the spec in this message to websec@... Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec https://www.ietf.org/mail-archive/web/websec/current/msg01015.html we should probably fork off any further discussion on this topic to that thread. > Also, does "in order to facilitate their IDNA transition" apply > to the second reference or to both references? It applies to both. One may implement [RFC5895] /or/ [UTS46] to facilitate one's IDNA transition (as I understand it). again, followups on this item and the above should probably be in the "Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec" thread here on websec@. > In Section 14.5: NTP needs an Informative Reference. fixed in my -07 working copy. > 15. IANA Considerations > > Below is the Internet Assigned Numbers Authority (IANA) Provisional > > I think here (and below) we should use "Permanent" registration for this > header field. > > Message Header Field registration information per [RFC3864]. > > Header field name: Strict-Transport-Security > Applicable protocol: HTTP > Status: provisional > Author/Change controller: TBD > Specification document(s): this one fixed in my -07 working copy thanks again, =JeffH From internet-drafts@ietf.org Wed May 2 13:26: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 0C17C21E8102; Wed, 2 May 2012 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snYZEmll1xZD; Wed, 2 May 2012 13:26:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9014521E8015; Wed, 2 May 2012 13:26:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120502202640.19881.77894.idtracker@ietfa.amsl.com> Date: Wed, 02 May 2012 13:26:40 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-strict-transport-sec-07.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 20:26:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IET= F. Title : HTTP Strict Transport Security (HSTS) Author(s) : Jeff Hodges Collin Jackson Adam Barth Filename : draft-ietf-websec-strict-transport-sec-07.txt Pages : 45 Date : 2012-05-02 This specification defines a mechanism enabling Web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by Web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-= 07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-0= 7.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ From Jeff.Hodges@KingsMountain.com Wed May 2 13:38:48 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B074521E8115 for ; Wed, 2 May 2012 13:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.751 X-Spam-Level: X-Spam-Status: No, score=-99.751 tagged_above=-999 required=5 tests=[AWL=-0.744, 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 VX7npb3Hm8Du for ; Wed, 2 May 2012 13:38:47 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 9AFD621E8112 for ; Wed, 2 May 2012 13:38:47 -0700 (PDT) Received: (qmail 18060 invoked by uid 0); 2 May 2012 20:38:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 2 May 2012 20:38:46 -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=WBZ+U3FKv7l/5mg7ORh4SkVtBVsjjQ5Fgc70s2VPSKg=; b=ZuIekFNUAaXoPBOhcFh2KeY8YOTOJscD0FjsMPvE5DkQVaamOnHl3kYf3k7/TBzIBkm0xvK64W42YvSi7C8ee/HacGjgLkYTxFUeLIlte1hzO7DTNGD5jQIKVLqUokO5; Received: from [205.248.100.252] (helo=[10.69.6.184]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SPgJy-0008Jw-M2 for websec@ietf.org; Wed, 02 May 2012 14:38:46 -0600 Message-ID: <4FA19B4F.9060606@KingsMountain.com> Date: Wed, 02 May 2012 13:38:39 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 205.248.100.252 authed with jeff.hodges+kingsmountain.com} Subject: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 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, 02 May 2012 20:38:48 -0000 New rev: https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-07 full issue ticket list for strict-transport-sec: Redline spec diff from previous rev: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-websec-strict-transport-sec-07.txt side-by-side diff from previous rev: https://tools.ietf.org/rfcdiff?url2=draft-ietf-websec-strict-transport-sec-07.txt Change Log is below. =JeffH ============================================================== Appendix D. Change Log [RFCEditor: please remove this section upon publication as an RFC.] Changes are grouped by spec revision listed in reverse issuance order. D.1. For draft-ietf-websec-strict-transport-sec Changes from -06 to -07: 1. Various minor/modest editorial tweaks throughout as I went through it pursuing the below issue tickets. Viewing a visual diff against -06 revision recommended. 2. fixed some minor editorial issues noted in review by Alexey, fixes noted in here: 3. Addressed ABNF exposition issues, specifically inclusion of quoted-string syntax for directive values. Fix STS header ABNF such that a leading ";" isn't required. Add example of quoted-string-encoded max-age-value. This addresses (re- opened) issue ticket #33. 4. Reworked sections 8.1 through 8.3 to ensure matching algorithm and resultant HSTS Policy application is more clear, and that it is explicitly stipulated to not muck with attributes of superdomain matching Known HSTS Hosts. This addresses issue ticket #37. 5. Added reference to [I-D.ietf-dane-protocol], pared back extraneous discussion in section 2.2, and updated discussion in 10.2 to accomodate TLSA (nee DANE). This addresses issue ticket #39. 6. Addressed various editorial items from issue ticket #40. 7. Loosened up the language regarding redirecting "http" requests to "https" in section 7.2 such that future flavors of permanent redirects are accommodated. This addresses issue ticket #43. 8. Reworked the terminology and language in Section 9, in particular defining the term "putative domain name string" to replace "valid Unicode-encoded string-serialized domain name". This addresses issue ticket #44. Changes from -05 to -06: . . . . --- end From julian.reschke@gmx.de Wed May 2 14:14:03 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DC411E809A for ; Wed, 2 May 2012 14:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.01 X-Spam-Level: X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=-0.411, 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 Sb+t+SxCp-iW for ; Wed, 2 May 2012 14:14:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 18E7311E80BF for ; Wed, 2 May 2012 14:14:01 -0700 (PDT) Received: (qmail invoked by alias); 02 May 2012 21:14:00 -0000 Received: from p5DD96838.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.104.56] by mail.gmx.net (mp031) with SMTP; 02 May 2012 23:14:00 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+oBb9zV3KoibnHuM+UVqLO4CuR/RiJyURWEbe/88 iqAE74xkNaoFgY Message-ID: <4FA1A395.7090704@gmx.de> Date: Wed, 02 May 2012 23:13:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Roy T. Fielding" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> In-Reply-To: <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG , IETF Apps Discuss Subject: Re: [websec] [apps-discuss] ABNF references (was RE: AppsDir review of 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: Wed, 02 May 2012 21:14:03 -0000 On 2012-05-02 21:32, Roy T. Fielding wrote: > ... > And if we go down the slippery slope, I would love to have a > formal definition of set reduction, as in > > ALPHA = ALPHANUM - DIGIT > ... +1000 From stpeter@stpeter.im Thu May 3 12:40: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 B2DAD21F8531 for ; Thu, 3 May 2012 12:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 TstHLqb7IlPY for ; Thu, 3 May 2012 12:40:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E022D21F861C for ; Thu, 3 May 2012 12:40:44 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7AD2240058; Thu, 3 May 2012 13:55:46 -0600 (MDT) Message-ID: <4FA2DF3B.7000506@stpeter.im> Date: Thu, 03 May 2012 13:40:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =JeffH References: <4FA18EF1.9040206@KingsMountain.com> In-Reply-To: <4FA18EF1.9040206@KingsMountain.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.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, 03 May 2012 19:40:46 -0000 On 5/2/12 1:45 PM, =JeffH wrote: >> 13. Internationalized Domain Names for Applications (IDNA): Dependency >> and Migration >> >> IDNA2008 obsoletes IDNA2003, but there are differences between the >> two specifications, and thus there can be differences in processing >> (e.g., converting) domain name labels that have been registered under >> one from those registered under the other. There will be a >> transition period of some time during which IDNA2003-based domain >> name labels will exist in the wild. User agents SHOULD implement >> IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of >> [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. >> >> I might be kicking a dead horse here, but MAY sounds a bit weak. >> I especially dislike having the choice between 2 incompatible specs, >> I think this might cause some interop problems. > > As far as I can tell, having had fairly extensive discussions with IDNA > folk both privately and on various lists such as idna-update@, the above > relects the the unfortunate state of the world at this time. For > instance, Pete Resnick signed off on the language in the spec in this > message to websec@... > > Re: [websec] wrt IDN processing-related security considerations for > draft-ietf-websec-strict-transport-sec > https://www.ietf.org/mail-archive/web/websec/current/msg01015.html > > we should probably fork off any further discussion on this topic to that > thread. Unfortunately, I think the text that Jeff produced is about the best we're going to do right now. Peter -- Peter Saint-Andre https://stpeter.im/ From ietf@adambarth.com Thu May 3 16:59:34 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 B942E11E8085 for ; Thu, 3 May 2012 16:59:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaHAmw+VeKRX for ; Thu, 3 May 2012 16:59:34 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5711E8080 for ; Thu, 3 May 2012 16:59:33 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1537803wgb.13 for ; Thu, 03 May 2012 16:59:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=mucgRhpovUjJjJcdtbrySyZOytrQVZkHxfiFJZpLws0=; b=KYqNn4J9L/3rr8D419GmqGkwFFAkTaThOadma9IPBLpZo+857hEy0+Y3JLSqJxgsRi Q0cDjZRa54wzkqnx3YCruxbCagka9jRUb/FngbTWboT/oGglxRmAHrK4td0RJj7gz1P6 Jx+3KOvKEUsJCTcYP7N4pw+ZN7hY4rdS1Mcymw22681xfdRzCd2i5b/o5WusnpycgWcJ +VaRTD3Ku3eUsTKe71Hs69Jie7de4tBms0zJ0NQRyDpAlF5urupGqq3sezjcvk2Z4yEZ Nxtwz5jOe8e226BgHRJ5CcmFla2+5SMohRkCDmt0r3ERf9bX0oGLWKtocU7VVmfEweOC muoQ== Received: by 10.180.83.198 with SMTP id s6mr7625735wiy.8.1336089570317; Thu, 03 May 2012 16:59:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id gg2sm8577325wib.7.2012.05.03.16.59.29 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 16:59:29 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1895492lbb.31 for ; Thu, 03 May 2012 16:59:28 -0700 (PDT) Received: by 10.152.145.169 with SMTP id sv9mr3762109lab.12.1336089568611; Thu, 03 May 2012 16:59:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.48.229 with HTTP; Thu, 3 May 2012 16:58:58 -0700 (PDT) From: Adam Barth Date: Thu, 3 May 2012 16:58:58 -0700 Message-ID: To: websec Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn0gN69IWH4IfhosbubAK3+P4D0FIEzUjKE9ZIwpNNhOWx9Ot1/mJiZCjii6qjwh6epO5WJ Subject: [websec] Frame-Options: Why a header and not a CSP directive? 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, 03 May 2012 23:59:34 -0000 In http://tools.ietf.org/html/draft-gondrom-frame-options-02 we're introducing a new HTTP header called Frame-Options. Is there a particular reason to create yet-another-HTTP-header for carrying this security policy? Rather than inventing a new HTTP header, we can use the extensible Content-Security-Policy header. == Proposed in draft-gondrom-frame-options == Frame-Options: XYZ Where XYZ is the Frame-Options policy. == Using Content-Security-Policy == Content-Security-Policy: frame-options XYZ There are added benefits to using a common policy header. For example, Content-Security-Policy has a report-uri directive that web sites can use to learn when their security policies are violated: Content-Security-Policy: frame-options XYZ; report-uri /csp-reports.cgi Note: Content-Security-Policy 1.0 is very close to WGLC in the W3C WebAppSec working group. You can find the current draft at . The WebAppSec working group is soliciting proposals for CSP 1.1: http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1 In particular, we have an item on the wiki about coordinating with this working group about frame-options. It's entirely possible to define the frame-options directive in this working group and to have CSP 1.1 refer to whatever document this working group produces. In the long term, we'll probably want an IANA registry for CSP directives, but we haven't quite reached that level of technology yet. :) Kind regards, Adam From msk@cloudmark.com Thu May 3 21:12: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 D344B11E8073 for ; Thu, 3 May 2012 21:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 HEd2CMI+O4hs for ; Thu, 3 May 2012 21:12:41 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 54D6011E8088 for ; Thu, 3 May 2012 21:12:40 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id 5gCf1j0010ZaKgw01gCfmz; Thu, 03 May 2012 21:12:39 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=bcDpoZzB c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=IwnkqaXHG70A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=iv4-XWu8dhfzlnTx-awA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 3 May 2012 21:12:39 -0700 From: "Murray S. Kucherawy" To: IETF WebSec WG Thread-Topic: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 Thread-Index: AQHNKKOVIK8xOP6K90aK+FVnv+njq5a4/8Ww Date: Fri, 4 May 2012 04:12:38 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810C59D@exch-mbx901.corp.cloudmark.com> References: <4FA19B4F.9060606@KingsMountain.com> In-Reply-To: <4FA19B4F.9060606@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336104759; bh=0P0QJ0Vm/u69edqFUW6pziDd2L2DNFfTj4nXPA6yIWs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=p691ti2YguBV7sdfwXGmff5I1G/TPqVuUR3HCV0qenwigktHCCe+IRk2yQCjlv5tv l1sMVaiBN0ESGQeb+BWzag6uw4Zyl3az6fvpcDDpdKshPQvdIb1+/L7KXJXquqHNr1 4w33h9YcoJ+3Ht+9Wy6KsK6C7zvlk773zZTSFfMo= Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 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, 04 May 2012 04:12:41 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf = Of =3DJeffH > Sent: Wednesday, May 02, 2012 1:39 PM > To: IETF WebSec WG > Subject: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 >=20 > New rev: > https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-07 The ABNF is better but still doesn't allow for whitespace. In particular, = your example: Strict-Transport-Security: max-age=3D15768000 ; includeSubDomains ...does not match the current ABNF: Strict-Transport-Security =3D "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] ) directive =3D token [ "=3D" ( token | quoted-string ) ]=09 where: token =3D quoted-string =3D In RFC2616, "token" is defined as: token =3D 1* separators =3D "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=3D" | "{" | "}" | SP | HT So all the spaces after the colon are not currently valid. I didn't know i= f you wanted to take the spaces out or allow them (probably the latter), so= perhaps this is what you're after: directive =3D *( SP | HT ) token *( SP | HT ) [ "=3D" ( token | *( SP | HT= ) quoted-string ) ]=09 -MSK From msk@cloudmark.com Thu May 3 22:16: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 4886721F86C2 for ; Thu, 3 May 2012 22:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 sPw2xNl3KjIF for ; Thu, 3 May 2012 22:16:51 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id BCEE221F8666 for ; Thu, 3 May 2012 22:16:51 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 5hGV1j0010as01C01hGV5z; Thu, 03 May 2012 22:16:29 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=bcDpoZzB c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=IwnkqaXHG70A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=9395Y4Cp13saUTRnxMAA:9 a=CjuIK1q_8ugA:10 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Thu, 3 May 2012 22:16:29 -0700 From: "Murray S. Kucherawy" To: IETF WebSec WG Thread-Topic: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 Thread-Index: AQHNKKOVIK8xOP6K90aK+FVnv+njq5a4/8WwgAAYvuA= Date: Fri, 4 May 2012 05:16:29 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810D69E@exch-mbx901.corp.cloudmark.com> References: <4FA19B4F.9060606@KingsMountain.com> <9452079D1A51524AA5749AD23E00392810C59D@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392810C59D@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1336108589; bh=YVghW5vRKW7/lOfDfFNnp2WBoVLjwNTrRJXfqgwjSRY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Ao3WjHZyM+/SGIiNMontf+UxEOv3K99IcNWnIhsNcOXUvGdOK6ZWzak78VjSJIBZK 5aQUl5yLgmz24iCqO3ZvxCfPTXzs1M6mgUdNpSJLElxslF66iruBqT1OXl1rFBT9O2 WO81G/bpBE313E4bipg97z8sjSbTQpD86a65A59k= Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 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, 04 May 2012 05:16:52 -0000 Nevermind all of that. It looks like that's covered in RFC2616 Section 4.2= . -MSK From julian.reschke@gmx.de Fri May 4 00:11:53 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F47F21F86BE for ; Fri, 4 May 2012 00:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=-0.336, 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 GwZ2g22tT1ul for ; Fri, 4 May 2012 00:11:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 25DDB21F867A for ; Fri, 4 May 2012 00:11:51 -0700 (PDT) Received: (qmail invoked by alias); 04 May 2012 07:11:50 -0000 Received: from p5DD9779D.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.119.157] by mail.gmx.net (mp071) with SMTP; 04 May 2012 09:11:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/gSwd8DSvgHyk8kCKB8QnYkD4IAbG7NZJRKKzfWC PgkSeCpnMJ/aqL Message-ID: <4FA38134.4000808@gmx.de> Date: Fri, 04 May 2012 09:11:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 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-Y-GMX-Trusted: 0 Cc: websec Subject: Re: [websec] Frame-Options: Why a header and not a CSP directive? 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, 04 May 2012 07:11:53 -0000 On 2012-05-04 01:58, Adam Barth wrote: > In http://tools.ietf.org/html/draft-gondrom-frame-options-02 we're > introducing a new HTTP header called Frame-Options. Is there a > particular reason to create yet-another-HTTP-header for carrying this > security policy? Rather than inventing a new HTTP header, we can use > the extensible Content-Security-Policy header. > ... Well, the header field already exists as "x-frame-options", so the only thing new here is that there's a spec, and that it's promoting a prefix-less name. I have no opinion on whether it should be a CSP directive, but a goal should be to document what's out there, even if we don't like it. In *particular* if it is related to security, and used in practice. Best regards, Julian From alexey.melnikov@isode.com Fri May 4 01:47:21 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 C57CC21F846E for ; Fri, 4 May 2012 01:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.115 X-Spam-Level: X-Spam-Status: No, score=-101.115 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 3D1d9jF4eHHG for ; Fri, 4 May 2012 01:47:18 -0700 (PDT) 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 00B5321F846A for ; Fri, 4 May 2012 01:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1336121236; d=isode.com; s=selector; i=@isode.com; bh=KgZEub58QpcfZrMYZeTda6MVz/9Zof4rdYknyBmHDJ4=; 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=CALWXEr2W5SQhsTw1Yw1YV+It5fwtj2J2A0djH4u/FkUsp05kX5yYQd8/CzrYTPcScTlqJ bHyYS3BnEhQ5Ad8zz5WvuPSlLwlJuUyHxDLBT5hfojySlr7zxfSUPaaYAqY3Y8xiErDkT2 zq44RmoG/dBq22WvHEALNz2SMIjsWQs=; Received: from [188.29.197.176] (188.29.197.176.threembb.co.uk [188.29.197.176]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 4 May 2012 09:47:16 +0100 References: <4FA18EF1.9040206@KingsMountain.com> <4FA2DF3B.7000506@stpeter.im> In-Reply-To: <4FA2DF3B.7000506@stpeter.im> Message-Id: <8E815A59-6F8C-404B-B88C-E8C7CFA1CB1C@isode.com> X-Mailer: iPad Mail (9B176) From: Alexey Melnikov Date: Fri, 4 May 2012 09:47:09 +0100 To: Peter Saint-Andre , =JeffH MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: IETF WebSec WG Subject: Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 08:47:21 -0000 On 3 May 2012, at 20:40, Peter Saint-Andre wrote: > On 5/2/12 1:45 PM, =3DJeffH wrote: >=20 >>> 13. Internationalized Domain Names for Applications (IDNA): Dependency >>> and Migration >>>=20 >>> IDNA2008 obsoletes IDNA2003, but there are differences between the >>> two specifications, and thus there can be differences in processing >>> (e.g., converting) domain name labels that have been registered under= >>> one from those registered under the other. There will be a >>> transition period of some time during which IDNA2003-based domain >>> name labels will exist in the wild. User agents SHOULD implement >>> IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of= >>> [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. >>>=20 >>> I might be kicking a dead horse here, but MAY sounds a bit weak. >>> I especially dislike having the choice between 2 incompatible specs, >>> I think this might cause some interop problems. >>=20 >> As far as I can tell, having had fairly extensive discussions with IDNA >> folk both privately and on various lists such as idna-update@, the above >> relects the the unfortunate state of the world at this time. For >> instance, Pete Resnick signed off on the language in the spec in this >> message to websec@... >>=20 >> Re: [websec] wrt IDN processing-related security considerations for >> draft-ietf-websec-strict-transport-sec >> https://www.ietf.org/mail-archive/web/websec/current/msg01015.html >>=20 >> we should probably fork off any further discussion on this topic to that >> thread. >=20 > Unfortunately, I think the text that Jeff produced is about the best > we're going to do=20 We are setting ourselves up for some interop problems. We should bite the bu= llet and through RFC 5894 or UTS 46 out. From alexey.melnikov@isode.com Fri May 4 04:10:26 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 41BCF21F871C for ; Fri, 4 May 2012 04:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 yvEJSDkoWRrH for ; Fri, 4 May 2012 04:10:25 -0700 (PDT) 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 07B3021F871A for ; Fri, 4 May 2012 04:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1336129823; d=isode.com; s=selector; i=@isode.com; bh=9TywROaqWhXvsH9Auqi6LopWygUMGnxi182COa5wGgQ=; 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=nOa1eGParXaNHGb/U1sXwGUhBlB/f0WZNx982fMW7Nf5RQKiST3N2oWfdIv3/3Z6h0cGF7 UJxbbVS5bn9c0YJ0Ijzum5wU8FnZu6X7QT0RvOSLFXTwg9GkhMVLQKyWYIQGgNeIVjCpwN rTI5Jxyk8Guov+UzNaAn39+LaabaWPQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 4 May 2012 12:10:23 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FA3B940.2090204@isode.com> Date: Fri, 04 May 2012 12:10:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: =JeffH References: <4FA18EF1.9040206@KingsMountain.com> In-Reply-To: <4FA18EF1.9040206@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] Review of draft-ietf-websec-strict-transport-sec-06.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 11:10:26 -0000 On 02/05/2012 20:45, =JeffH wrote: > [ resent with correct Subject: ] > > Hi Alexey, thanks for the review, apologies for latency. Hi Jeff, > > The two directives defined in this specification are described > below. > > The overall requirements for directives are: > > > > o The order of appearance of directives is not significant. > > > > o All directives MUST appear only once in an STS header field. > > > > o Directive names are case-insensitive. > > > > o UAs MUST ignore any STS header fields containing directives that > > do not conform to their ABNF definition. > > > > Should this list also say something about how unrecognized directives > > should be treated? I.e. are they ignored by default, is the whole > > STS header field ignored, etc. > > Does the last bullet item above not address those questions? No. The last bullet is talking about recognized, but invalid data. I am asking about unrecognized data. > > Additional directives extending the semantic functionality of > the STS > > header field may be defined in other specifications (which "update" > > this specification), > > > > Is this a requirement on future extensions? > > (In general "updating" this specification using Updates: in the header > > of the relevant RFC > > is a) a heavy weight mechanism (it prevents Experimental extensions) > and > > b) this seems > > like a wrong mechanism anyway, as Updates usually means that the > > document being > > updated can't be implemented without the document which updates it.) > > We can place in the above para whatever we/you/ourADs wish. > Suggestions welcome. It is not about the location of this sentence. I think you need to strike "(which "update" this specification)". > > subdomain of a publicly-available web application which may be > > secured by TLS/SSL. For example, is a > > publicly-available web application for "Example CA", a > certification > > authority. Customers use this web application to register their > > public keys and obtain certificates. Example CA generates > > certificates for customers containing > > as the value for the "CRL > > Distribution Points" and "Authority Information Access:OCSP" > > certificate fields. > > > > 13. Internationalized Domain Names for Applications (IDNA): Dependency > > and Migration > > > > IDNA2008 obsoletes IDNA2003, but there are differences between the > > two specifications, and thus there can be differences in processing > > (e.g., converting) domain name labels that have been registered > under > > one from those registered under the other. There will be a > > transition period of some time during which IDNA2003-based domain > > name labels will exist in the wild. User agents SHOULD implement > > IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section > 7 of > > [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. > > > > I might be kicking a dead horse here, but MAY sounds a bit weak. > > I especially dislike having the choice between 2 incompatible specs, > > I think this might cause some interop problems. > > As far as I can tell, having had fairly extensive discussions with > IDNA folk both privately and on various lists such as idna-update@, > the above relects the the unfortunate state of the world at this time. > For instance, Pete Resnick signed off on the language in the spec in > this message to websec@... Commented on this in reply to Peter. > Re: [websec] wrt IDN processing-related security considerations for > draft-ietf-websec-strict-transport-sec > https://www.ietf.org/mail-archive/web/websec/current/msg01015.html > > we should probably fork off any further discussion on this topic to > that thread. > > > > Also, does "in order to facilitate their IDNA transition" apply > > to the second reference or to both references? > > It applies to both. One may implement [RFC5895] /or/ [UTS46] to > facilitate one's IDNA transition (as I understand it). Can you please move "in order to facilitate their IDNA transition" to the beginning of the sentence? I think this will make it clearer. > > again, followups on this item and the above should probably be in the > "Re: [websec] wrt IDN processing-related security considerations for > draft-ietf-websec-strict-transport-sec" thread here on websec@. > From Jeff.Hodges@KingsMountain.com Fri May 4 09:05:47 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC89421F86E2 for ; Fri, 4 May 2012 09:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.058 X-Spam-Level: X-Spam-Status: No, score=-100.058 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6Yi5PqzKHhS for ; Fri, 4 May 2012 09:05:47 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id DFEA921F86D3 for ; Fri, 4 May 2012 09:05:46 -0700 (PDT) Received: (qmail 3268 invoked by uid 0); 4 May 2012 16:05:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 4 May 2012 16:05:46 -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=YX08KlmWE6UvJ/xOUsOg//E9WhnTnwOph27lO+EzjQQ=; b=aijNXONtmOjMmeZIK9F3oq/4/PoLZfNzgpZa92KlE2jAJIdCWNIqzLYlnysNlwOIrCTJ51iCg96V2XizhP9uOeO7Z7LubTJvZnFCaCviwd8Qt8OBFbfjAmwaiUuqjo4U; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.90]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SQL0r-0004gc-PL; Fri, 04 May 2012 10:05:45 -0600 Message-ID: <4FA3FE5A.70405@KingsMountain.com> Date: Fri, 04 May 2012 09:05:46 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Murray S. Kucherawy" 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] new rev: draft-ietf-websec-strict-transport-sec-07 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, 04 May 2012 16:05:47 -0000 > Nevermind all of that. It looks like that's covered in RFC2616 Section 4.2. yes, as well as Section 2 of [RFC2616], as noted in S 6.1 of -strict-transport-sec-07 (and prior revs).. The ABNF syntax for the STS header field is given below. It is based on the Generic Grammar defined in Section 2 of [RFC2616] (which includes a notion of "implied linear whitespace", also known as "implied *LWS"). HTH, =JeffH From ietf@adambarth.com Fri May 4 09:50:36 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 1670821E8047 for ; Fri, 4 May 2012 09:50:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F54S-AJ-pgMr for ; Fri, 4 May 2012 09:50:35 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFB1F21E804B for ; Fri, 4 May 2012 09:50:34 -0700 (PDT) Received: by bkty8 with SMTP id y8so2862412bkt.31 for ; Fri, 04 May 2012 09:50:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=BYDagpCKYUVB0DzUl/o6pUXE8IrEUAOlVx/XKSM35CE=; b=juZtNNRcLwtWIjenH0SoQxpMKlfV++MnaJfyHkBH6rd3Z0dTl70wnaaHSzfCWam/F0 2gSGMGeW6Xd9RxY6V5WuabxLHQR1WMN6iAyDG7fv3AF+jRuh6l7XQeUU5c2ZFdzlVTRb V1olD1J4X6Wu+sm+/VErm5m5lIExgQGUrJ0TkBSg1Ftv3m0Od9WwVxEm21j+k1+0QEmu ijohfbtEGjLkKV8kcWvr01cX20vVr7FAhn4CW9ehGjQgNHj4nB5d9Ra8L3qrYFLybsQf 83R2wlmaXTn2nkCVpRU05iv+nezOC2AatgC32kWkBTDiRXgnu9F1j3eYMYrHatDFoCk6 FrVA== Received: by 10.205.137.14 with SMTP id im14mr2383995bkc.137.1336150233737; Fri, 04 May 2012 09:50:33 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id n17sm18038757bkw.5.2012.05.04.09.50.32 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 09:50:32 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2492069lbb.31 for ; Fri, 04 May 2012 09:50:31 -0700 (PDT) Received: by 10.152.111.41 with SMTP id if9mr6346976lab.19.1336150231342; Fri, 04 May 2012 09:50:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.48.229 with HTTP; Fri, 4 May 2012 09:50:01 -0700 (PDT) In-Reply-To: <4FA38134.4000808@gmx.de> References: <4FA38134.4000808@gmx.de> From: Adam Barth Date: Fri, 4 May 2012 09:50:01 -0700 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnIV97rxzWSabTQ5QIoA4Jv0Fvsk4UqDC0r9H8SO1ehkznfxn6lNVUny93dkdhrxkh6s8A2 Cc: websec Subject: Re: [websec] Frame-Options: Why a header and not a CSP directive? 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, 04 May 2012 16:50:36 -0000 On Fri, May 4, 2012 at 12:11 AM, Julian Reschke wro= te: > On 2012-05-04 01:58, Adam Barth wrote: >> In http://tools.ietf.org/html/draft-gondrom-frame-options-02 we're >> introducing a new HTTP header called Frame-Options. =A0Is there a >> particular reason to create yet-another-HTTP-header for carrying this >> security policy? =A0Rather than inventing a new HTTP header, we can use >> the extensible Content-Security-Policy header. >> ... > > Well, the header field already exists as "x-frame-options", so the only > thing new here is that there's a spec, and that it's promoting a prefix-l= ess > name. > > I have no opinion on whether it should be a CSP directive, but a goal sho= uld > be to document what's out there, even if we don't like it. In *particular= * > if it is related to security, and used in practice. Yes, I agree that we should document the existing X-Frame-Options header. However, the Frame-Options header doesn't yet exist. Rather than introduce it, I wonder if we'd be better off making the "unprefixed" version a CSP directive rather than an HTTP header. Adam From brian.e.carpenter@gmail.com Wed May 2 23:39:29 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78BA21F85AD; Wed, 2 May 2012 23:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.547 X-Spam-Level: X-Spam-Status: No, score=-101.547 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRFAK6yAJjSh; Wed, 2 May 2012 23:39:29 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B028D21F8528; Wed, 2 May 2012 23:39:28 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so951113wgb.13 for ; Wed, 02 May 2012 23:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eyQz2wZyT49+gQhZz5zLwn/4WfoYActLSRf7EapuBoU=; b=rHcp663V9ZxzjsLV70YvrDOl4Au1cfRFgdn8kpNZukhbH9dFlWkD/qDGG+mY90TJxU xnDWPkINPl3cgbk6D4lUsnK1s7vTlRay0TNBMdGNdKuv2byJjzFewh5PAJ8amSFm4hi7 atfpMnOM2l1vDoNHHnAqCo/Z4erg3ZXtRVe4wF+t2bPzVxV5JhuTKoJbdRqukAiqdt3T VcJE40dLk95Sv/gH1lcZ8kHBTzyQO48u1fr4X/XVQqUnqO2WWweqiVhKkUVmLFoer1IZ 5+hVb3ejdsEEo9OmDGw4wKJwlHbm6kPBEv056s8madlabfPuVmRtTcCeiuGzSKPISCfF /7OQ== Received: by 10.216.134.155 with SMTP id s27mr696278wei.80.1336027167649; Wed, 02 May 2012 23:39:27 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-144.as13285.net. [2.102.217.144]) by mx.google.com with ESMTPS id n20sm379878wiw.5.2012.05.02.23.39.25 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 23:39:26 -0700 (PDT) Message-ID: <4FA22814.6020309@gmail.com> Date: Thu, 03 May 2012 07:39:16 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Roy T. Fielding" References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> <4F9F9A8D.8080004@gmx.de> <9452079D1A51524AA5749AD23E003928107DBB@exch-mbx901.corp.cloudmark.com> <4FA03F4D.3050606@gmx.de> <9452079D1A51524AA5749AD23E00392810A6F1@exch-mbx901.corp.cloudmark.com> <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> In-Reply-To: <35987DD9-06A7-4C71-90FA-8FA88427DDB8@gbiv.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 04 May 2012 09:56:27 -0700 Cc: Julian Reschke , IETF WebSec WG , IETF Apps Discuss Subject: Re: [websec] [apps-discuss] ABNF references (was RE: AppsDir review of 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: Thu, 03 May 2012 06:39:30 -0000 Roy, On 2012-05-02 20:32, Roy T. Fielding wrote: > On May 2, 2012, at 10:48 AM, Murray S. Kucherawy wrote: >> 2) There's a common axiom that says it's safer to refer to a definition rather than to copy it. > > I think we should recognize that as a false axiom and move on. > > We should refer to orthogonal definitions that are subject to > independent change control -- e.g., protocol elements that are > defined in another spec because they change at a different > rate than the referring spec or are used by multiple specs. > > We should copy a definition by value if the referring spec > depends on the definition (does not allow the parser to change > even if some other spec were to define it and later extend it). But that is contrary to the general principle in the IETF of using normative references and *not* replicating normative material, to avoid mistakes. Both approaches have their advantages and disadvantages, but making ABNF an exception seems problematic, or at least a decision that can't be taken at Area level. > My preference is to not use prose definitions at all -- I used > them as a crutch when I first started writing IETF specs in 1994, > and they burned me every time. > > And if we go down the slippery slope, I would love to have a > formal definition of set reduction, as in > > ALPHA = ALPHANUM - DIGIT > > since I very commonly need rules that only differ by one or two > characters being removed from the allowed set. Would you call that "disinheritance" ? Brian From Jeff.Hodges@KingsMountain.com Fri May 4 09:57:28 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 643C621F85BD for ; Fri, 4 May 2012 09:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.098 X-Spam-Level: X-Spam-Status: No, score=-100.098 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR6P1WkkOGjC for ; Fri, 4 May 2012 09:57:27 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 7749F21F8483 for ; Fri, 4 May 2012 09:57:27 -0700 (PDT) Received: (qmail 20979 invoked by uid 0); 4 May 2012 16:57:25 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 4 May 2012 16:57:25 -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=cfYn5y9aOBmQJeHZkvRtEAqDzK/2xfQ+OGeBtfcieFw=; b=H6zu61O5KKZcQ25IIURxVaay02vF+WICV1BRv+zHpNChMMOm0H47G9o8YJ/oAG9f/lAKhVk3KnRdHyA71tR/tcWVRcdsXCO/EVZnhwd3sb4yW/VLYppE9eoWzqaZRmAt; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.90]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SQLoq-0003GZ-RR; Fri, 04 May 2012 10:57:24 -0600 Message-ID: <4FA40A76.2000503@KingsMountain.com> Date: Fri, 04 May 2012 09:57:26 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Alexey Melnikov , Peter Saint-Andre 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] IDNA Dependency and Migration text (was: Review of draft-ietf-websec-strict-transport-sec-06.txt) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 16:57:28 -0000 Alexey states: > > On 3 May 2012, at 20:40, Peter Saint-Andre wrote: > >> On 5/2/12 1:45 PM, =JeffH wrote: >> >>>> 13. Internationalized Domain Names for Applications (IDNA): Dependency >>>> and Migration >>>> >>>> IDNA2008 obsoletes IDNA2003, but there are differences between the >>>> two specifications, and thus there can be differences in processing >>>> (e.g., converting) domain name labels that have been registered under >>>> one from those registered under the other. There will be a >>>> transition period of some time during which IDNA2003-based domain >>>> name labels will exist in the wild. User agents SHOULD implement >>>> IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of >>>> [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. >>>> >>>> I might be kicking a dead horse here, but MAY sounds a bit weak. >>>> I especially dislike having the choice between 2 incompatible specs, >>>> I think this might cause some interop problems. >>> >>> As far as I can tell, having had fairly extensive discussions with IDNA >>> folk both privately and on various lists such as idna-update@, the above >>> relects the the unfortunate state of the world at this time. For >>> instance, Pete Resnick signed off on the language in the spec in this >>> message to websec@... >>> >>> Re: [websec] wrt IDN processing-related security considerations for >>> draft-ietf-websec-strict-transport-sec >>> https://www.ietf.org/mail-archive/web/websec/current/msg01015.html >>> >>> we should probably fork off any further discussion on this topic to that >>> thread. >> >> Unfortunately, I think the text that Jeff produced is about the best >> we're going to do > > We are setting ourselves up for some interop problems. We should bite the > bullet and through RFC 5894 or UTS 46 out. These overall topics have been discussed in the past on.. idna-update@alvestrand.no ..and it seems to me this particular discussion should probably be taken over to that list. some pointers to likely pertinent prior threads below. HTH, =JeffH ------ Past threads on the idna-update@ list that I'm aware of that are specifically pertinent to the above include (there may also be others, see also further below).. referencing IDNA2008 (and IDNA2003?) http://www.alvestrand.no/pipermail/idna-update/2010-October/006757.html RFC5895 and UTS46 ? http://www.alvestrand.no/pipermail/idna-update/2010-October/006821.html IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec http://www.alvestrand.no/pipermail/idna-update/2011-September/007140.html wrt IDNA2008 migration (was: IDN processing-related... http://www.alvestrand.no/pipermail/idna-update/2011-September/007152.html wrt IDNA2003->IDNA2008 transitionn (was: IDN processing-related... http://www.alvestrand.no/pipermail/idna-update/2011-October/007170.html Older threads re IDNA2003 - IDNA2008 transition (there also are definitely (many) other relevant threads)... Another Transition Plan Proposal http://www.alvestrand.no/pipermail/idna-update/2009-December/006255.html An idea for transition principles (see next thread for plain text doc version; but there were replies in this thread too) http://www.alvestrand.no/pipermail/idna-update/2009-December/006330.html Re-sending TXT form of Proposed IDNA2008 Transition Idea http://www.alvestrand.no/pipermail/idna-update/2009-December/006339.html PostWG IDNA2008 implementation, transition and deployment document preparation http://www.alvestrand.no/pipermail/idna-update/2009-December/006374.html --- end From stpeter@stpeter.im Fri May 4 10:00:24 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6335C21F85D5 for ; Fri, 4 May 2012 10:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 qfyFY33ZPD-C for ; Fri, 4 May 2012 10:00:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B68CC21F85D1 for ; Fri, 4 May 2012 10:00:23 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4EF2B40058; Fri, 4 May 2012 11:15:28 -0600 (MDT) Message-ID: <4FA40B26.7000808@stpeter.im> Date: Fri, 04 May 2012 11:00:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4FA18EF1.9040206@KingsMountain.com> <4FA2DF3B.7000506@stpeter.im> <8E815A59-6F8C-404B-B88C-E8C7CFA1CB1C@isode.com> In-Reply-To: <8E815A59-6F8C-404B-B88C-E8C7CFA1CB1C@isode.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 17:00:24 -0000 On 5/4/12 2:47 AM, Alexey Melnikov wrote: > On 3 May 2012, at 20:40, Peter Saint-Andre wrote: > >> On 5/2/12 1:45 PM, =JeffH wrote: >> >>>> 13. Internationalized Domain Names for Applications (IDNA): Dependency >>>> and Migration >>>> >>>> IDNA2008 obsoletes IDNA2003, but there are differences between the >>>> two specifications, and thus there can be differences in processing >>>> (e.g., converting) domain name labels that have been registered under >>>> one from those registered under the other. There will be a >>>> transition period of some time during which IDNA2003-based domain >>>> name labels will exist in the wild. User agents SHOULD implement >>>> IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of >>>> [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. >>>> >>>> I might be kicking a dead horse here, but MAY sounds a bit weak. >>>> I especially dislike having the choice between 2 incompatible specs, >>>> I think this might cause some interop problems. >>> >>> As far as I can tell, having had fairly extensive discussions with IDNA >>> folk both privately and on various lists such as idna-update@, the above >>> relects the the unfortunate state of the world at this time. For >>> instance, Pete Resnick signed off on the language in the spec in this >>> message to websec@... >>> >>> Re: [websec] wrt IDN processing-related security considerations for >>> draft-ietf-websec-strict-transport-sec >>> https://www.ietf.org/mail-archive/web/websec/current/msg01015.html >>> >>> we should probably fork off any further discussion on this topic to that >>> thread. >> >> Unfortunately, I think the text that Jeff produced is about the best >> we're going to do > > We are setting ourselves up for some interop problems. We should bite the bullet and through RFC 5894 or UTS 46 out. Jeff's point is that we already have interop problems but we need to be realistic about the state of the browsers. From reports we've received, some of them will be stuck on IDNA2003 for a long time... Peter -- Peter Saint-Andre https://stpeter.im/ From Jeff.Hodges@KingsMountain.com Fri May 4 10:13:31 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 A814521F8616 for ; Fri, 4 May 2012 10:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.131 X-Spam-Level: X-Spam-Status: No, score=-100.131 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyuFKkD7wzSE for ; Fri, 4 May 2012 10:13:31 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id B371121F8615 for ; Fri, 4 May 2012 10:13:30 -0700 (PDT) Received: (qmail 8043 invoked by uid 0); 4 May 2012 17:13:30 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 4 May 2012 17:13:30 -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=eoGk6zfVp3lWnGLKzhWpjd1K9NMXWRBiDaTGozYcKwM=; b=1de2LK61WFENj0WJ8JRXvCTi/LmLMQ+ciNPv18IJcHAES9X0TzYVw2LyI01J2bF08o8sgnq22oFr0TubmjMkGcPBO+1K1+wqMz9PLZMFRgeM3YBXGewPdyuL6lIjEZ85; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.90]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SQM4P-0001wR-W2 for websec@ietf.org; Fri, 04 May 2012 11:13:30 -0600 Message-ID: <4FA40E3B.6020608@KingsMountain.com> Date: Fri, 04 May 2012 10:13:31 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Frame-Options: Why a header and not a CSP directive? 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, 04 May 2012 17:13:31 -0000 > On Fri, May 4, 2012 at 12:11 AM, Julian Reschke wrote: >> On 2012-05-04 01:58, Adam Barth wrote: >>> In http://tools.ietf.org/html/draft-gondrom-frame-options-02 we're >>> introducing a new HTTP header called Frame-Options. Is there a >>> particular reason to create yet-another-HTTP-header for carrying this >>> security policy? Rather than inventing a new HTTP header, we can use >>> the extensible Content-Security-Policy header. >>> ... >> >> Well, the header field already exists as "x-frame-options", so the only >> thing new here is that there's a spec, and that it's promoting a prefix-less >> name. >> >> I have no opinion on whether it should be a CSP directive, but a goal should >> be to document what's out there, even if we don't like it. In *particular* >> if it is related to security, and used in practice. > > Yes, I agree that we should document the existing X-Frame-Options > header. However, the Frame-Options header doesn't yet exist. Rather > than introduce it, I wonder if we'd be better off making the > "unprefixed" version a CSP directive rather than an HTTP header. To hopefully clarify here, there's indeed an intended Informational track draft regarding the "x-frame-options" header field such that it's documented in a referenceable spec (rather than only a blog post).. https://tools.ietf.org/html/draft-gondrom-x-frame-options-00 And then there's the "frame-options" draft which is proposing (as Adam notes) a new header field along with some functionality that's beyond the existing "x-frame-options" mechanism.. http://tools.ietf.org/html/draft-gondrom-frame-options-02 It's w.r.t. this latter draft that Adam is wondering whether we could simply specify a new directive for the content security policy header (CSP) rather than invent yet another header field. Also note that as of 24-Apr, both of the above drafts are accepted as WG drafts, but it seems they haven't yet been re-issued with new filenames (see msg from Alexey to websec@ on Tue, 24 Apr 2012 18:29:13 +0100) =JeffH From msk@cloudmark.com Fri May 4 12:23:31 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 A1EA221F85F1 for ; Fri, 4 May 2012 12:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 KdP4Pe1G9LnK for ; Fri, 4 May 2012 12:23:31 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3471D21F85F0 for ; Fri, 4 May 2012 12:23:31 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Fri, 4 May 2012 12:21:02 -0700 From: "Murray S. Kucherawy" To: IETF WebSec WG Thread-Topic: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 Thread-Index: AQHNKg/DIK8xOP6K90aK+FVnv+njq5a6AbjQ Date: Fri, 4 May 2012 19:21:02 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392810E5C7@exch-mbx901.corp.cloudmark.com> References: <4FA3FE5A.70405@KingsMountain.com> In-Reply-To: <4FA3FE5A.70405@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 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, 04 May 2012 19:23:31 -0000 > -----Original Message----- > From: =3DJeffH [mailto:Jeff.Hodges@KingsMountain.com] > Sent: Friday, May 04, 2012 9:06 AM > To: Murray S. Kucherawy > Cc: IETF WebSec WG > Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-07 >=20 > yes, as well as Section 2 of [RFC2616], as noted in S 6.1 of > -strict-transport-sec-07 (and prior revs).. >=20 > The ABNF syntax for the STS header field is given below. It is based > on the Generic Grammar defined in Section 2 of [RFC2616] (which > includes a notion of "implied linear whitespace", also known as > "implied *LWS"). Yep, mea culpa, although I suspect I won't be the last person to run into t= his given all of my ABNF work to date doesn't include this special context. -MSK From trac+websec@trac.tools.ietf.org Wed May 9 13:45:48 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0791311E80D0 for ; Wed, 9 May 2012 13:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3z7VkrgqzFt for ; Wed, 9 May 2012 13:45:47 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFEB11E80CA for ; Wed, 9 May 2012 13:45:43 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SSDlC-0003m7-BO; Wed, 09 May 2012 16:45:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Wed, 09 May 2012 20:45:21 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/45 Message-ID: <070.9239929b63486d786104bf07dca8f63e@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120509204547.7EFEB11E80CA@ietfa.amsl.com> Resent-Date: Wed, 9 May 2012 13:45:43 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #45: HSTS: Alexey's editorial comments on -06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 20:45:48 -0000 #45: HSTS: Alexey's editorial comments on -06 See.. Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt https://www.ietf.org/mail-archive/web/websec/current/msg01173.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: websec From Jeff.Hodges@KingsMountain.com Wed May 9 13:53:53 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4870211E80BB for ; Wed, 9 May 2012 13:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.13 X-Spam-Level: X-Spam-Status: No, score=-100.13 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8lejwFPzJDv for ; Wed, 9 May 2012 13:53:52 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 8446611E8080 for ; Wed, 9 May 2012 13:53:52 -0700 (PDT) Received: (qmail 15996 invoked by uid 0); 9 May 2012 20:53:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 9 May 2012 20:53: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:CC:To:MIME-Version:From:Date:Message-ID; bh=Jhw2RAuwCgGiWw8IdlKSiL5Ji2j6J+E4w5ZGpyd1gF0=; b=rITXziAI5aCN62L8EINiTsUZZOj+KeriCo78NPgY0vO+KpuhfKnezFo5+Pjk2T1UEQ45nOlu3FTk+h/IYiHYnhHqkWJUn9cfcVIp3h0wWKNXoU2ZuYOHrKK4fHZun9Ao; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.90]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SSDtO-0002q8-4r; Wed, 09 May 2012 14:53:50 -0600 Message-ID: <4FAAD960.8010502@KingsMountain.com> Date: Wed, 09 May 2012 13:53:52 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 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] Review of draft-ietf-websec-strict-transport-sec-06.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 20:53:53 -0000 Hi, I've filed issue ticket #45 encompassing the items in your message I'm replying to, and will address them in -08 (underway). > On 02/05/2012 20:45, =JeffH wrote: >> [ resent with correct Subject: ] >> >> Hi Alexey, thanks for the review, apologies for latency. > Hi Jeff, >> > The two directives defined in this specification are described >> below. >> > The overall requirements for directives are: >> > >> > o The order of appearance of directives is not significant. >> > >> > o All directives MUST appear only once in an STS header field. >> > >> > o Directive names are case-insensitive. >> > >> > o UAs MUST ignore any STS header fields containing directives that >> > do not conform to their ABNF definition. >> > >> > Should this list also say something about how unrecognized directives >> > should be treated? I.e. are they ignored by default, is the whole >> > STS header field ignored, etc. >> >> Does the last bullet item above not address those questions? >> > No. The last bullet is talking about recognized, but invalid data. I am > asking about unrecognized data. So how about this re-write of that last bullet item.. o UAs MUST ignore any STS header fields containing directives, or other header field value data, that does not conform to the syntax defined in this specification. ..? >> > Additional directives extending the semantic functionality of >> the STS >> > header field may be defined in other specifications (which "update" >> > this specification), >> > >> > Is this a requirement on future extensions? >> > (In general "updating" this specification using Updates: in the header >> > of the relevant RFC >> > is a) a heavy weight mechanism (it prevents Experimental extensions) >> and >> > b) this seems >> > like a wrong mechanism anyway, as Updates usually means that the >> > document being >> > updated can't be implemented without the document which updates it.) >> >> We can place in the above para whatever we/you/ourADs wish. >> Suggestions welcome. > > It is not about the location of this sentence. I did not say anything about the location of the sentence. > I think you need to > strike "(which "update" this specification)". works for me. done in my -08 working copy. >> Re: [websec] wrt IDN processing-related security considerations for >> draft-ietf-websec-strict-transport-sec >> https://www.ietf.org/mail-archive/web/websec/current/msg01015.html >> >> we should probably fork off any further discussion on this topic to >> that thread. >> >> >> > Also, does "in order to facilitate their IDNA transition" apply >> > to the second reference or to both references? >> >> It applies to both. One may implement [RFC5895] /or/ [UTS46] to >> facilitate one's IDNA transition (as I understand it). > > Can you please move "in order to facilitate their IDNA transition" to > the beginning of the sentence? I think this will make it clearer. sure, done in my -08 working copy. =JeffH From internet-drafts@ietf.org Thu May 17 09:49:17 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D741421F86D5; Thu, 17 May 2012 09:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 tpOtj8SQ-kEJ; Thu, 17 May 2012 09:49:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6650421F869F; Thu, 17 May 2012 09:49:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120517164917.4096.1540.idtracker@ietfa.amsl.com> Date: Thu, 17 May 2012 09:49:17 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-strict-transport-sec-08.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, 17 May 2012 16:49:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IET= F. Title : HTTP Strict Transport Security (HSTS) Author(s) : Jeff Hodges Collin Jackson Adam Barth Filename : draft-ietf-websec-strict-transport-sec-08.txt Pages : 46 Date : 2012-05-17 This specification defines a mechanism enabling Web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by Web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-= 08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-0= 8.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ From Jeff.Hodges@KingsMountain.com Thu May 17 13:33:18 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEFD21F875C for ; Thu, 17 May 2012 13:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.097 X-Spam-Level: X-Spam-Status: No, score=-100.097 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4mRAX0mt41z for ; Thu, 17 May 2012 13:33:17 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 7DD6421F8740 for ; Thu, 17 May 2012 13:33:17 -0700 (PDT) Received: (qmail 733 invoked by uid 0); 17 May 2012 20:33:16 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 17 May 2012 20:33:16 -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=pkzLc3rP/G7kehZvXXuG6CUekvZjmsWfj72wZpcNC8U=; b=oRArkyOfQpnirIteV/vMltss1KViQMTxFFwse3daUiYwQEM7E9bK5UCwGWiXe6lRWvvC5h1A+phnFG4BEp9uDKFplgCZUkxBqu72h2iA585Jy0E9e6NAE2m/A7aJrlGL; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.83]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SV7Ns-0007om-BW for websec@ietf.org; Thu, 17 May 2012 14:33:16 -0600 Message-ID: <4FB5608E.60409@KingsMountain.com> Date: Thu, 17 May 2012 13:33:18 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] new rev: draft-ietf-websec-strict-transport-sec-08 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, 17 May 2012 20:33:18 -0000 New rev: https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-08 full issue ticket list for strict-transport-sec: Redline spec diff from previous rev: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-websec-strict-transport-sec-08.txt side-by-side diff from previous rev: https://tools.ietf.org/rfcdiff?url2=draft-ietf-websec-strict-transport-sec-08.txt Change Log is below. =JeffH ============================================================== Appendix D. Change Log [RFCEditor: please remove this section upon publication as an RFC.] Changes are grouped by spec revision listed in reverse issuance order. D.1. For draft-ietf-websec-strict-transport-sec Changes from -07 to -08: 1. Clarified requirement #4 for STS header field directives in Section 6.1, and removed "(which "update" this specification)". Also added explicit "max-age=0" to Section 6.1.1. Reworked final sentence in 2nd para of Section 13. This addresses issue ticket #45. Changes from -06 to -07: 1. Various minor/modest editorial tweaks throughout as I went through it pursuing the below issue tickets. Viewing a visual diff against -06 revision recommended. 2. fixed some minor editorial issues noted in review by Alexey, fixes noted in here: 3. Addressed ABNF exposition issues, specifically inclusion of quoted-string syntax for directive values. Fix STS header ABNF such that a leading ";" isn't required. Add example of quoted-string-encoded max-age-value. This addresses (re- opened) issue ticket #33. 4. Reworked sections 8.1 through 8.3 to ensure matching algorithm and resultant HSTS Policy application is more clear, and that it is explicitly stipulated to not muck with attributes of superdomain matching Known HSTS Hosts. This addresses issue ticket #37. 5. Added reference to [I-D.ietf-dane-protocol], pared back extraneous discussion in section 2.2, and updated discussion in 10.2 to accomodate TLSA (nee DANE). This addresses issue ticket #39. 6. Addressed various editorial items from issue ticket #40. 7. Loosened up the language regarding redirecting "http" requests to "https" in section 7.2 such that future flavors of permanent redirects are accommodated. This addresses issue ticket #43. 8. Reworked the terminology and language in Section 9, in particular defining the term "putative domain name string" to replace "valid Unicode-encoded string-serialized domain name". This addresses issue ticket #44. Changes from -05 to -06: . . . . --- end From alexey.melnikov@isode.com Thu May 31 07:17:48 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6869A21F869E for ; Thu, 31 May 2012 07:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 OBHq0wqvBR9S for ; Thu, 31 May 2012 07:17:48 -0700 (PDT) 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 B121521F866B for ; Thu, 31 May 2012 07:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338473866; d=isode.com; s=selector; i=@isode.com; bh=BAA4Kk/e6n2UsoPv3I5uF1508g3D+6gQYPqeJJQOEzM=; 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=Bvh8dmGXOLtv045jcM/NbTefLW17nftiuGlfhSQDO2F7W23dhb43SJuaZYinp8YFwM/UF/ SMF2ePKzVkquhfW9MfzjdicjUP6Fb67WcoQzLOUBeCR4NISZRKmBrOyttI6jAbhKdaDm3y UtXWZJXphw0ym0GXqmwkhhidDLiWt6I=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 31 May 2012 15:17:46 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FC77D89.1070508@isode.com> Date: Thu, 31 May 2012 15:17:45 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: =JeffH References: <4FB5608E.60409@KingsMountain.com> In-Reply-To: <4FB5608E.60409@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] new rev: draft-ietf-websec-strict-transport-sec-08 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, 31 May 2012 14:17:48 -0000 Most of my issues were addressed in the latest version, except for this one: > 6.1. Strict-Transport-Security HTTP Response Header Field > > 4. UAs MUST ignore any STS header fields containing directives, or > other header field value data, that does not conform to the > syntax defined in this specification. So this is saying that syntactically invalid STS header fields are to be ignored. This still doesn't say if unrecognized directives are to be ignored or not. (Because they can comply with the generic syntax for directives, so they would be syntactically valid, albeit unrecognized). So can you please add an explicit sentence about that? From Jeff.Hodges@KingsMountain.com Thu May 31 11:03:04 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B2421F86DE for ; Thu, 31 May 2012 11:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koltgVtRaUBI for ; Thu, 31 May 2012 11:03:03 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 177D721F86DA for ; Thu, 31 May 2012 11:02:58 -0700 (PDT) Received: (qmail 17957 invoked by uid 0); 31 May 2012 18:02:58 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 31 May 2012 18:02:58 -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=woW75SHtA/YcWOWMy+gK3kT4B0joQ7GvAB+HtYd5FbQ=; b=0ViKDa+JIYqviRUfswYB2xMFvFvmugG1N9If46Au9jljK3MUaaNfZOXUmQMHykrKaSij8y/IapY1mvnCZ3rWLtdaM8ZpT7EePfXClkfcPQAvB6CbztnFNNox5qVORJAr; Received: from [216.113.168.128] (port=54371 helo=[10.244.137.233]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sa9i5-0004dn-DC for websec@ietf.org; Thu, 31 May 2012 12:02:57 -0600 Message-ID: <4FC7B252.1010305@KingsMountain.com> Date: Thu, 31 May 2012 11:02:58 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-08 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, 31 May 2012 18:03:05 -0000 Alexey said: > > Most of my issues were addressed in the latest version, except for this one: > > > 6.1. Strict-Transport-Security HTTP Response Header Field > > > > 4. UAs MUST ignore any STS header fields containing directives, or > > other header field value data, that does not conform to the > > syntax defined in this specification. > > So this is saying that syntactically invalid STS header fields are > to be ignored. This still doesn't say if unrecognized directives are to > be ignored or not. (Because they can comply with the generic syntax for > directives, so they would be syntactically valid, albeit unrecognized). > So can you please add an explicit sentence about that? will do. =JeffH From trac+websec@trac.tools.ietf.org Thu May 31 14:06:00 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D60C21F851A for ; Thu, 31 May 2012 14:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-s7nauDgu6W for ; Thu, 31 May 2012 14:05:56 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A6DB121F8516 for ; Thu, 31 May 2012 14:05:56 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SaCYm-0002IU-Vm; Thu, 31 May 2012 17:05:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Thu, 31 May 2012 21:05:32 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/45#comment:1 Message-ID: <085.3e27247b08e46020bc6bf5ee253c0a2e@trac.tools.ietf.org> References: <070.9239929b63486d786104bf07dca8f63e@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <070.9239929b63486d786104bf07dca8f63e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120531210556.A6DB121F8516@ietfa.amsl.com> Resent-Date: Thu, 31 May 2012 14:05:56 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #45: HSTS: Alexey's editorial comments on -06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 21:06:00 -0000 #45: HSTS: Alexey's editorial comments on -06 Comment (by jeff.hodges@…): Alexey notes that all his issues were addressed in rev -08 except for needing to explicitly state that "unrecognized directives are to be ignored" where they are defined as "syntactically valid but undefined in the specfication" (my interpretation of how to state what he means). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Thu May 31 14:06:28 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 3517E21F8518 for ; Thu, 31 May 2012 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YDrUu6SzjO3 for ; Thu, 31 May 2012 14:06:27 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF7721F8516 for ; Thu, 31 May 2012 14:06:27 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SaCZZ-0002a3-5z; Thu, 31 May 2012 17:06:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Thu, 31 May 2012 21:06:21 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/45#comment:2 Message-ID: <085.857ce04c2a3e9f14286844a73de9a694@trac.tools.ietf.org> References: <070.9239929b63486d786104bf07dca8f63e@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <070.9239929b63486d786104bf07dca8f63e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120531210627.9FF7721F8516@ietfa.amsl.com> Resent-Date: Thu, 31 May 2012 14:06:27 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #45: HSTS: Alexey's editorial comments on -06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 21:06:28 -0000 #45: HSTS: Alexey's editorial comments on -06 Comment (by jeff.hodges@…): alexey's feedback referred to above is here: https://www.ietf.org/mail-archive/web/websec/current/msg01185.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From paul.hoffman@vpnc.org Thu May 31 16:20:18 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD39421F856D for ; Thu, 31 May 2012 16:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.483, 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 LHNauNCnpWE2 for ; Thu, 31 May 2012 16:20:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DE28F21F84DE for ; Thu, 31 May 2012 16:20:16 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q4VNKFUx058412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2012 16:20:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FB5608E.60409@KingsMountain.com> Date: Thu, 31 May 2012 16:20:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B93B689-D98A-4E98-B8D8-27D02BD8AB8B@vpnc.org> References: <4FB5608E.60409@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1278) Cc: IETF WebSec WG Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-08 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, 31 May 2012 23:20:19 -0000 I didn't send a message between -06 and -07, but -07 (and thus -08) = fixed all the issues I care about. It's looking great. --Paul Hoffman= From asteingruebl@paypal-inc.com Thu May 31 18:11:17 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4EB11E80C1 for ; Thu, 31 May 2012 18:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.116 X-Spam-Level: X-Spam-Status: No, score=-9.116 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 H4e0PywC9FQS for ; Thu, 31 May 2012 18:11:16 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 07ADE11E8080 for ; Thu, 31 May 2012 18:11:15 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:x-ems-proccessed: x-ems-stamp:Content-Type:MIME-Version:X-CFilter; b=bOs76IVf5JCGHonAQpYlH3f3Sf0hUQLkiSKkQ4hCnQuruLVA07ClFXil VfXMGJMDCsqCcjQpnzv6O7TOmLbpPgJuMU7jt/CG5NGlNe371HVA8D53n Rce7bhu+KhuCov9; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1338513076; x=1370049076; h=from:to:subject:date:message-id:mime-version; bh=4OQwLujhwLSdwHaeXQH/GklPZGsdzb6AbHnYri2JoBY=; b=q3B3RP/Lgv4U6iaEHxpQwHfzzCqW5fv9kSSmCkXGj+6UxxKwBas+CmLL 3ZNDeGHsNyHfA1xx2Es79rygjM6YZWU/piq2WeThVTjJUhpdIVGldv04N rZXI1/37Ivx7d4u; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.75,695,1330934400"; d="scan'208,217";a="8346031" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 31 May 2012 18:11:16 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-001.corp.ebay.com ([fe80::345e:2420:7d3d:208d%13]) with mapi id 14.01.0339.001; Thu, 31 May 2012 19:11:14 -0600 From: "Steingruebl, Andy" To: "websec@ietf.org" Thread-Topic: Firefox looking to add preloaded HSTS support Thread-Index: Ac0/kyzq8sD3V6/XSJux72sx8/L87Q== Date: Fri, 1 Jun 2012 01:11:14 +0000 Message-ID: <1DFCCAFE421024488073B74EEA0173E10F8A69@DEN-EXDDA-S12.corp.ebay.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.242] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: vOzo4x7Mrg/Cd0lmw4Ea5Q== Content-Type: multipart/alternative; boundary="_000_1DFCCAFE421024488073B74EEA0173E10F8A69DENEXDDAS12corpeb_" MIME-Version: 1.0 X-CFilter: Scanned Subject: [websec] Firefox looking to add preloaded HSTS support 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, 01 Jun 2012 01:11:17 -0000 --_000_1DFCCAFE421024488073B74EEA0173E10F8A69DENEXDDAS12corpeb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, this feature request popped up today. https://bugzilla.mozilla.org/show_bug.cgi?id=3D760307 Encouraging news from my perspective. -- Andy Steingruebl Sr. Manager, Internet Standards and Governance PayPal Information Risk Management (408) 967-4650 --_000_1DFCCAFE421024488073B74EEA0173E10F8A69DENEXDDAS12corpeb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, this feature request popped up today.

 

https://bugzilla.mozilla.org/show_bug.cgi?id=3D760307

 

Encouraging news from = my perspective.

 

--

Andy Steingruebl<= /o:p>

Sr. Manager, Internet = Standards and Governance

PayPal Information Ris= k Management

(408) 967-4650

 

--_000_1DFCCAFE421024488073B74EEA0173E10F8A69DENEXDDAS12corpeb_--