From alexey.melnikov@isode.com Wed Apr 4 04:50:32 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A54721F86D6 for ; Wed, 4 Apr 2012 04:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.607 X-Spam-Level: X-Spam-Status: No, score=-101.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 MXUCYRUwsWSE for ; Wed, 4 Apr 2012 04:50:31 -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 6378C21F86B6 for ; Wed, 4 Apr 2012 04:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1333540229; d=isode.com; s=selector; i=@isode.com; bh=O6vu+kTgCDClhlcQBTeSKC8KJvx0Ti+dqoTi+doJm54=; 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=UDqeLh2f/9dQuWwSb1z075YgB9z2UTj7abrjXjNSZ1FDWF2s14OiKFyjQNQ8XV0BE5W4Mr fLVsvDFT3cjYji9O37MWJhYx5bSKO/RjFnnpn0lsb5cnOU16sfcKsCRnq0ezwmYEKHckjQ 4R9eFAQDQEfQxOyHeiit6G+p9HpbrXI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Apr 2012 12:50:29 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F7B5D18.1040407@isode.com> Date: Tue, 03 Apr 2012 21:27:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: IETF WebSec WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Review of draft-ietf-websec-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, 04 Apr 2012 11:50:32 -0000 Hi, Below is my WGLC review of the draft: 6.1. Strict-Transport-Security HTTP Response Header Field The Strict-Transport-Security HTTP response header field (STS header field) indicates to a UA that it MUST enforce the HSTS Policy in regards to the host emitting the response message containing this header field. The ABNF syntax for the STS header field is: Strict-Transport-Security = "Strict-Transport-Security" ":" *( ";" [ directive ] ) As already noted by other reviewers, this effectively requires a leading ";" which is not what was intended here. 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. 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.) using the STS directive extension point. 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. 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. 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. Also, does "in order to facilitate their IDNA transition" apply to the second reference or to both references? If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003. In Section 14.5: NTP needs an Informative Reference. 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 From paul.hoffman@vpnc.org Wed Apr 4 05:38: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 04E8521F8656 for ; Wed, 4 Apr 2012 05:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 e-f5aq13r5dF for ; Wed, 4 Apr 2012 05:38:33 -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 882A121F864F for ; Wed, 4 Apr 2012 05:38:29 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q34CcRue045484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2012 05:38:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F7B5D18.1040407@isode.com> Date: Wed, 4 Apr 2012 05:38:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D4DE4DF-DAF6-4C91-B699-BC71FC4C36B0@vpnc.org> References: <4F7B5D18.1040407@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1257) Cc: IETF WebSec WG Subject: [websec] Showing errors in HSTS 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, 04 Apr 2012 12:38:34 -0000 On Apr 3, 2012, at 1:27 PM, Alexey Melnikov wrote: > 8.3. Errors in Secure Transport Establishment >=20 > 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]. >=20 > 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. Disagree. There are plenty of things that are not prohibited by this (or = any other) protocol that go unmentioned. I don't see anything in this = paragraph that indicates that such messages are even discouraged, so the = proposed addition is unnecessary. It might be confusing, in that it will = be the only place where optional messages are allowed. --Paul Hoffman From Jeff.Hodges@KingsMountain.com Thu Apr 5 15:40:22 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 5FA6521F871C for ; Thu, 5 Apr 2012 15:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.988 X-Spam-Level: X-Spam-Status: No, score=-97.988 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyishE+zJJu0 for ; Thu, 5 Apr 2012 15:40:21 -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 8BE7D21F86DE for ; Thu, 5 Apr 2012 15:40:21 -0700 (PDT) Received: (qmail 22422 invoked by uid 0); 5 Apr 2012 22:40:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 5 Apr 2012 22:40:20 -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=JPR25WSBTCNlIPoRGoraiJViu5D9PWGRPd8ZgbMzBBk=; b=YYlT8AIKTihcMq6fTZpKIGA6fCOeuVIAlUnGPEeNEo4WwF2YYhte7g5TiFmVl5nvGMO7a+jfjEriAocgH7qitepfhbP/GiQuXq5BJ24K1k5RqNTMvwezRFH377sAPGDu; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SFvLn-0006oQ-NC; Thu, 05 Apr 2012 16:40:19 -0600 Message-ID: <4F7E1F51.9040002@KingsMountain.com> Date: Thu, 05 Apr 2012 15:40:17 -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: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04 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, 05 Apr 2012 22:40:22 -0000 Thanks for the feedback, proposed edits, and hacked xml2rfc source. > So this > > - states that the given ABNF applies to the value after q-s processing > (when needed) > - changes the ABNF to specify only the *value* Ok. so you suggested.. 6.1.1. The max-age Directive The REQUIRED max-age directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host, from whom the message was received, as a Known HSTS Host (see also Section 8.1.1 "Noting a HSTS Host", below). The syntax of the max-age directive's value (after potential applying quoted-string unescaping) is: max-age-v = delta-seconds delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> Note: A max-age value of zero signals the UA to cease regarding the host as a Known HSTS Host. ..and I presently am polishing that to be.. 6.1.1. The max-age Directive The REQUIRED "max-age" directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host, from whom the message was received, as a Known HSTS Host (see also Section 8.1.1 "Noting a HSTS Host", below). The max-age directive value has the following syntax (after quoted-string unescaping, if necessary): max-age-value = delta-seconds delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> Note: A max-age value of zero signals the UA to cease regarding the host as a Known HSTS Host. I'm a little concerned that without an explicit syntax declaration such as.. max-age = "max-age" "=" max-age-value ..we'll confuse some readers ("what do i actually put in the STS header for this directive??"), but hopefully the examples in section 6.2, as well as putting the directive name in quotes in the first paragraph, will address this. thx, =JeffH From Jeff.Hodges@KingsMountain.com Thu Apr 5 15:54: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 42D3C21F8645 for ; Thu, 5 Apr 2012 15:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.035 X-Spam-Level: X-Spam-Status: No, score=-98.035 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYtRQ3HZQjKy for ; Thu, 5 Apr 2012 15:54:12 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id D148B21F85E5 for ; Thu, 5 Apr 2012 15:54:08 -0700 (PDT) Received: (qmail 10446 invoked by uid 0); 5 Apr 2012 22:54:07 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 5 Apr 2012 22:54:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=CFQeNcoMlIRD7VTYdZVQuSoIMv4Q4l3WzPzfunRzZA4=; b=sSxAKTIxQQxm89hKCM+wBhFtvBdigIhW1O3ziRJGoRQakyly4XG25izvbK1wY9KiY4DiBhT6OSVd1gqwmeVeCHLazKdZwyqFSlqcUTh3dfeMQP9zwEhVfg9Rt9YCwnsw; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SFvZ9-0002Pp-DO; Thu, 05 Apr 2012 16:54:07 -0600 Message-ID: <4F7E228D.3020508@KingsMountain.com> Date: Thu, 05 Apr 2012 15:54:05 -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: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04 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, 05 Apr 2012 22:54:13 -0000 Julian had sent to me.. > > 6.2. Examples > > > Section 6.2., paragraph 2: > OLD: > > Strict-Transport-Security: max-age=31536000 > > NEW: > > Strict-Transport-Security: max-age="31536000" > > (changed one example to use q-s) I'll actually add a separate example for illustrating use of quoted-string, because I don't think we want to necessarily encourage it's use. thx, =JeffH From julian.reschke@gmx.de Fri Apr 6 00:25:55 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 8C70021F8576 for ; Fri, 6 Apr 2012 00:25:55 -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 2VrrsF-dTQBU for ; Fri, 6 Apr 2012 00:25:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 81DF421F8559 for ; Fri, 6 Apr 2012 00:25:54 -0700 (PDT) Received: (qmail invoked by alias); 06 Apr 2012 07:25:52 -0000 Received: from p57A6D85B.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.216.91] by mail.gmx.net (mp020) with SMTP; 06 Apr 2012 09:25:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1996aIvX2R9RS5/AhZDWBQWRy3eVImnLzLCH3UhqX qTTsoRxQPHdn10 Message-ID: <4F7E9A81.6030805@gmx.de> Date: Fri, 06 Apr 2012 09:25:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =JeffH References: <4F7E1F51.9040002@KingsMountain.com> In-Reply-To: <4F7E1F51.9040002@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04 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, 06 Apr 2012 07:25:55 -0000 On 2012-04-06 00:40, =JeffH wrote: > Thanks for the feedback, proposed edits, and hacked xml2rfc source. > > > So this > > > > - states that the given ABNF applies to the value after q-s processing > > (when needed) > > - changes the ABNF to specify only the *value* > > Ok. so you suggested.. > > 6.1.1. The max-age Directive > > The REQUIRED max-age directive specifies the number of seconds, after > the reception of the STS header field, during which the UA regards > the host, from whom the message was received, as a Known HSTS Host > (see also Section 8.1.1 "Noting a HSTS Host", below). > > The syntax of the max-age directive's value (after potential > applying quoted-string unescaping) is: > > max-age-v = delta-seconds > delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> > > Note: A max-age value of zero signals the UA to cease regarding the > host as a Known HSTS Host. > > > > ..and I presently am polishing that to be.. > > > 6.1.1. The max-age Directive > > The REQUIRED "max-age" directive specifies the number of seconds, > after the reception of the STS header field, during which the UA > regards the host, from whom the message was received, as a Known HSTS > Host (see also Section 8.1.1 "Noting a HSTS Host", below). > > The max-age directive value has the following syntax > (after quoted-string unescaping, if necessary): > > max-age-value = delta-seconds > delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> > > Note: A max-age value of zero signals the UA to cease regarding the > host as a Known HSTS Host. Looks good to me. > I'm a little concerned that without an explicit syntax declaration such > as.. > > max-age = "max-age" "=" max-age-value > > ..we'll confuse some readers ("what do i actually put in the STS header > for this directive??"), but hopefully the examples in section 6.2, as > well as putting the directive name in quotes in the first paragraph, > will address this. Noted. And yes, if we optimize for people not reading the spec "properly", the best way to address this is to add examples. Best regards, Julian From tobias.gondrom@gondrom.org Mon Apr 9 03:35: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 704EB21F8609 for ; Mon, 9 Apr 2012 03:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6kN07n5q7VE for ; Mon, 9 Apr 2012 03:35:52 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7887A21F864D for ; Mon, 9 Apr 2012 03:35:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Hv42WUu1gANvPxkwFz+tinELKsoeoRN0dkZE0S3WhvyLCLwmoQ+yAwUwFG4TwgOjbbj2OuJv3P4pBKwYPWneG+glfJxtBumIix/r4IvnptIck36c8XSxaCvOjY3CbB5T; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 19558 invoked from network); 9 Apr 2012 12:35:42 +0200 Received: from n2028211917.imsbiz.com (HELO ?10.65.1.73?) (202.82.119.17) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Apr 2012 12:35:41 +0200 Message-ID: <4F82BB79.5050706@gondrom.org> Date: Mon, 09 Apr 2012 18:35:37 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: paul.hoffman@vpnc.org References: <4F7B5D18.1040407@isode.com> <9D4DE4DF-DAF6-4C91-B699-BC71FC4C36B0@vpnc.org> In-Reply-To: <9D4DE4DF-DAF6-4C91-B699-BC71FC4C36B0@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Showing errors in HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 10:35:52 -0000 I agree with Paul, no need to specify more clearly here what is not prohibited. Best regards, Tobias On 04/04/12 20:38, Paul Hoffman wrote: > On Apr 3, 2012, at 1:27 PM, Alexey Melnikov wrote: > >> 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. > Disagree. There are plenty of things that are not prohibited by this (or any other) protocol that go unmentioned. I don't see anything in this paragraph that indicates that such messages are even discouraged, so the proposed addition is unnecessary. It might be confusing, in that it will be the only place where optional messages are allowed. > > --Paul Hoffman > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From alexey.melnikov@isode.com Tue Apr 10 04:32:40 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 CE7DD21F850D for ; Tue, 10 Apr 2012 04:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.866 X-Spam-Level: X-Spam-Status: No, score=-101.866 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 XAdbzLxMYvcZ for ; Tue, 10 Apr 2012 04:32:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 13F6421F846A for ; Tue, 10 Apr 2012 04:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334057525; d=isode.com; s=selector; i=@isode.com; bh=cXXD58AiFRHcL5/H2kD0Gl1MzUhPxN130Wh5xzI5Hko=; 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=oHMf1CsGx1OQoV7IFHWAgYMZoLIYupO3NUro1Aa3MX2J8q1qW3mU7wSDXF1fsRXTwgslmY EgGSNaWFM2Nkr4xPb89yiKihUGVAFusEPHYrWo+F0HgEJAJ/h74UT7+KU9fIWXsGYxTsGZ QFpNm3Wq9sg6DwrmpZURh+eBnpkGUFk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Apr 2012 12:32:05 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F82C6F9.1070007@isode.com> Date: Mon, 09 Apr 2012 12:24:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Paul Hoffman References: <4F7B5D18.1040407@isode.com> <9D4DE4DF-DAF6-4C91-B699-BC71FC4C36B0@vpnc.org> In-Reply-To: <9D4DE4DF-DAF6-4C91-B699-BC71FC4C36B0@vpnc.org> 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] Showing errors in HSTS 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, 10 Apr 2012 11:32:40 -0000 On 04/04/2012 13:38, Paul Hoffman wrote: > On Apr 3, 2012, at 1:27 PM, Alexey Melnikov wrote: >> 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. > Disagree. There are plenty of things that are not prohibited by this (or any other) protocol that go unmentioned. I don't see anything in this paragraph that indicates that such messages are even discouraged, so the proposed addition is unnecessary. It might be confusing, in that it will be the only place where optional messages are allowed. I am not a big fan of "things unmentioned are Ok", especially after the topic was explicitly discussed in Paris. I think we will make a service to implementors by being explicit on this. From alexey.melnikov@isode.com Mon Apr 16 03:54:38 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 8E16721F873E for ; Mon, 16 Apr 2012 03:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.885 X-Spam-Level: X-Spam-Status: No, score=-101.885 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 m6buRnHZJa43 for ; Mon, 16 Apr 2012 03:54:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1741E21F872E for ; Mon, 16 Apr 2012 03:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334573586; d=isode.com; s=selector; i=@isode.com; bh=lBokWeLoocNog1vk4sg6ozhBJC1jJED3CJ5kL6bkMVk=; 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=r4TQB9I1h9UIDoOzIZaqUEf1Q20Y4j4xFNORvWEwNCyvlvD9nIXuO8XfJfT9qEGOTFI83b LdbRtwns8L9ZaSOW+4gnym3lV5bc7RoFHTyh4RdNET6G3t7tUHgrG7nDEXSC/A8MITRtRS O1Zg6GwIbe+nNKpvblQ6tDBvQzcgmhc=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 16 Apr 2012 11:53:06 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F8B39B9.3060304@isode.com> Date: Sun, 15 Apr 2012 22:12:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: IETF WebSec WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Acceptance of draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt as WebSec WG documents X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:54:38 -0000 Dear WG participants, draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt (and their earlier version) were discussed in a couple of WG face-to-face meetings. I believe both of the documents are in scope for the WG Charter and I think there is support for working on them. As both of these documents are co-edited by Tobias, I will be judging consensus on them. draft-gondrom-frame-options is targeted to become a Proposed Standard, while draft-gondrom-x-frame-options will be an Informational document (as it documents existing header field). So I would like to start a one week acceptance call for these documents as WebSec WG documents. Please send me your objections or statements of support directly to me or to the mailing list before midnight GMT+1 on April 23rd. Thank you, Alexey, as a WebSec co-chair From stpeter@stpeter.im Mon Apr 16 10:11:25 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4827121F85D2 for ; Mon, 16 Apr 2012 10:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 nlRj9GwR4vAm for ; Mon, 16 Apr 2012 10:11:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3211E80DB for ; Mon, 16 Apr 2012 10:11:18 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9A2834005B; Mon, 16 Apr 2012 11:25:25 -0600 (MDT) Message-ID: <4F8C52B5.60809@stpeter.im> Date: Mon, 16 Apr 2012 11:11:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4F8B39B9.3060304@isode.com> In-Reply-To: <4F8B39B9.3060304@isode.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] Acceptance of draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt as WebSec WG documents X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:11:25 -0000 On 4/15/12 3:12 PM, Alexey Melnikov wrote: > Dear WG participants, > draft-gondrom-frame-options-02.txt and > draft-gondrom-x-frame-options-00.txt (and their earlier version) were > discussed in a couple of WG face-to-face meetings. I believe both of the > documents are in scope for the WG Charter and I think there is support > for working on them. > > As both of these documents are co-edited by Tobias, I will be judging > consensus on them. draft-gondrom-frame-options is targeted to become a > Proposed Standard, while draft-gondrom-x-frame-options will be an > Informational document (as it documents existing header field). So I > would like to start a one week acceptance call for these documents as > WebSec WG documents. Please send me your objections or statements of > support directly to me or to the mailing list before midnight GMT+1 on > April 23rd. +1. Let's get these done. Peter -- Peter Saint-Andre https://stpeter.im/ From chris@lookout.net Mon Apr 16 11:07:30 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 03D8321F86C4 for ; Mon, 16 Apr 2012 11:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7q7nNvPU0zN for ; Mon, 16 Apr 2012 11:07:29 -0700 (PDT) Received: from n06.mail01.mtsvc.net (mailout08.mail01.mtsvc.net [216.70.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4900721F8623 for ; Mon, 16 Apr 2012 11:07:29 -0700 (PDT) Received: from [174.136.108.2] (port=40161 helo=[0.0.0.0]) by n06.mail01.mtsvc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SJqKm-0003PR-6P; Mon, 16 Apr 2012 14:07:28 -0400 Message-ID: <4F8C5FD9.50005@lookout.net> Date: Mon, 16 Apr 2012 11:07:21 -0700 From: Chris Weber User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: IETF WebSec WG References: <4F8B39B9.3060304@isode.com> <4F8C52B5.60809@stpeter.im> In-Reply-To: <4F8C52B5.60809@stpeter.im> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: 882879 chris@lookout.net Subject: Re: [websec] Acceptance of draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt as WebSec WG documents X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 18:07:30 -0000 On 4/15/12 3:12 PM, Alexey Melnikov wrote: >> Dear WG participants, >> draft-gondrom-frame-options-02.txt and >> draft-gondrom-x-frame-options-00.txt (and their earlier version) were >> discussed in a couple of WG face-to-face meetings. I believe both of the >> documents are in scope for the WG Charter and I think there is support >> for working on them. >> >> As both of these documents are co-edited by Tobias, I will be judging >> consensus on them. draft-gondrom-frame-options is targeted to become a >> Proposed Standard, while draft-gondrom-x-frame-options will be an >> Informational document (as it documents existing header field). So I >> would like to start a one week acceptance call for these documents as >> WebSec WG documents. Please send me your objections or statements of >> support directly to me or to the mailing list before midnight GMT+1 on >> April 23rd. I have one nit with this document - the way it brings Cross Site Request Forgery (CSRF) into the discussion and positions X-Frame-Options as a "sometimes" mitigation for CSRF. We could probably agree that wording such as "In some forms of Clickjacking and CSRF an attacker tricks a user into clicking..." sufficiently limits the scope of the context. However I feel that CSRF in general is just completely out of scope - there are many attacks that might leverage framing after all. I also worry that some people may be led to believe that the X-Frame-Options header provides general protection from CSRF when that's absolutely not the case. When Microsoft released this functionality with IE8, it was positioned as a protection against framing attacks, or Clickjacking, and not CSRF. I believe that's how many of us in the security community still view it - it's only a protection against CSRF in cases where framing is required to execute the CSRF attack. The two (Clickjacking and CSRF) can only be linked in that and similar contexts. I suggest that references to CSRF protection be removed to avoid confusion or that the wording reflect this narrow scope of the CSRF-protection (preferably the former). After all, CSRF is just one example of many other attacks that could leverage framing - e.g. we could include answering CAPTCHAs, certain forms of self-side XSS, and even information disclosure as equivalent forms of attack (like CSRF) that might leverage framing. Can we keep the document focused on the primary design goal - controlling/preventing framing - and avoid lumping in other forms of attack that might piggyback on such framing? Best regards, Chris Weber From stpeter@stpeter.im Mon Apr 16 11:14:35 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 E9D0E11E80AB for ; Mon, 16 Apr 2012 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 2NY3iDERwchY for ; Mon, 16 Apr 2012 11:14:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4623A11E8093 for ; Mon, 16 Apr 2012 11:14:34 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 408954005B; Mon, 16 Apr 2012 12:28:42 -0600 (MDT) Message-ID: <4F8C6189.1090006@stpeter.im> Date: Mon, 16 Apr 2012 12:14:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Chris Weber References: <4F8B39B9.3060304@isode.com> <4F8C52B5.60809@stpeter.im> <4F8C5FD9.50005@lookout.net> In-Reply-To: <4F8C5FD9.50005@lookout.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] Acceptance of draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt as WebSec WG documents X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 18:14:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/16/12 12:07 PM, Chris Weber wrote: > Can we keep the document focused on the primary design goal - > controlling/preventing framing - and avoid lumping in other forms > of attack that might piggyback on such framing? Chris, just to be clear, are you objecting to acceptance of these documents as starting points for progression within the working group (i.e., do you think they are fatally flawed or not within the charter), or are you providing technical feedback on the assumption that they'll be accepted as working group items? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+MYYkACgkQNL8k5A2w/vwmvQCglGJ8xp9AFFeKB63jxtGbVbuf qhwAoMLyg4tuDx12C/z/Apelb7MI7c9h =Dk8r -----END PGP SIGNATURE----- From chris@lookout.net Mon Apr 16 11:49:33 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 AE11511E809D for ; Mon, 16 Apr 2012 11:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 vcu2GYIfi1fp for ; Mon, 16 Apr 2012 11:49:33 -0700 (PDT) Received: from n06.mail01.mtsvc.net (mailout08.mail01.mtsvc.net [216.70.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA2311E809A for ; Mon, 16 Apr 2012 11:49:33 -0700 (PDT) Received: from [174.136.108.2] (port=40189 helo=[0.0.0.0]) by n06.mail01.mtsvc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SJqzU-0005ZL-Ll; Mon, 16 Apr 2012 14:49:32 -0400 Message-ID: <4F8C69BB.5040409@lookout.net> Date: Mon, 16 Apr 2012 11:49:31 -0700 From: Chris Weber User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F8B39B9.3060304@isode.com> <4F8C52B5.60809@stpeter.im> <4F8C5FD9.50005@lookout.net> <4F8C6189.1090006@stpeter.im> In-Reply-To: <4F8C6189.1090006@stpeter.im> X-Enigmail-Version: 1.4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: 882879 chris@lookout.net Cc: IETF WebSec WG Subject: Re: [websec] Acceptance of draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt as WebSec WG documents X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 18:49:33 -0000 On 4/16/2012 11:14 AM, Peter Saint-Andre wrote:
> Chris, just to be clear, are you objecting to acceptance of these
> documents as starting points for progression within the working group
> (i.e., do you think they are fatally flawed or not within the
> charter), or are you providing technical feedback on the assumption
> that they'll be accepted as working group items?

I think frame-options is flawed by even discussing itself as a protection against CSRF when it's primary function is to control and prevent framing.  However I do believe this is within charter, so I'm merely providing feedback on the assumption that they'll be accepted.

Best regards,
Chris Weber


From Jeff.Hodges@KingsMountain.com Wed Apr 18 16:53:44 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB84F21F84DE for ; Wed, 18 Apr 2012 16:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.006 X-Spam-Level: X-Spam-Status: No, score=-99.006 tagged_above=-999 required=5 tests=[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 O72Xsa60K6+c for ; Wed, 18 Apr 2012 16:53:40 -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 A80A421F84F0 for ; Wed, 18 Apr 2012 16:53:40 -0700 (PDT) Received: (qmail 27949 invoked by uid 0); 18 Apr 2012 23:53:40 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 18 Apr 2012 23:53:40 -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=gQRUJKJvwiArdNk94FATdbIwDwzwYZ8dhhCVmWc/VOY=; b=dCaxycf92vtUhFf6e27/AvPKzq18aD6+QsWw+at5Glsxt8vBa4+0CGtYFwdH3J7ZrbgC5Lpzjscg+WZpELOzXcgb3DSSDvXd0OjF0U8CYZq6vmTWns+LjYkgbRcmTABu; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.216]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SKegt-0001lF-Tu for websec@ietf.org; Wed, 18 Apr 2012 17:53:39 -0600 Message-ID: <4F8F5404.8020406@KingsMountain.com> Date: Wed, 18 Apr 2012 16:53:40 -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] Acceptance of draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt as WebSec WG documents 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, 18 Apr 2012 23:53:45 -0000 +1 to acceptance of both I-Ds. =JeffH From chris@lookout.net Wed Apr 18 17:27:50 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 2053B21F8460 for ; Wed, 18 Apr 2012 17:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77fX2WA51fiQ for ; Wed, 18 Apr 2012 17:27:49 -0700 (PDT) Received: from n06.mail01.mtsvc.net (mailout08.mail01.mtsvc.net [216.70.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 989D121F845C for ; Wed, 18 Apr 2012 17:27:49 -0700 (PDT) Received: from [174.136.108.2] (port=53328 helo=[0.0.0.0]) by n06.mail01.mtsvc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SKfDw-0006uK-Fk for websec@ietf.org; Wed, 18 Apr 2012 20:27:48 -0400 Message-ID: <4F8F5C05.8010904@lookout.net> Date: Wed, 18 Apr 2012 17:27:49 -0700 From: Chris Weber User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: websec X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: 882879 chris@lookout.net Subject: [websec] comments on -frame-options and -x-frame-options drafts 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, 19 Apr 2012 00:27:50 -0000 Sending this with a new subject as I think my comments could have been better placed. I have one nit with these documents - the way they bring Cross Site Request Forgery (CSRF) into the discussion and positions X-Frame-Options as a "sometimes" mitigation for CSRF. We could probably agree that wording such as "In some forms of Clickjacking and CSRF an attacker tricks a user into clicking..." sufficiently limits the scope of the context. However I feel that CSRF in general is just completely out of scope - there are many attacks that might leverage framing after all. I also worry that some people may be led to believe that the X-Frame-Options header provides general protection from CSRF when that's absolutely not the case. When Microsoft released this functionality with IE8, it was positioned as a protection against framing attacks, or Clickjacking, and not CSRF. I believe that's how many of us in the security community still view it - it's only a protection against CSRF in cases where framing is required to execute the CSRF attack. The two (Clickjacking and CSRF) can only be linked in that and similar contexts. I suggest that references to CSRF protection be removed to avoid confusion or that the wording reflect this narrow scope of the CSRF-protection (preferably the former). After all, CSRF is just one example of many other attacks that could leverage framing - e.g. we could include answering CAPTCHAs, certain forms of self-side XSS, and even information disclosure as equivalent forms of attack (like CSRF) that might leverage framing. Can we keep the documents focused on the primary design goal - controlling/preventing framing - and avoid lumping in other forms of attack that might piggyback on such framing? Best regards, Chris Weber From chris@lookout.net Wed Apr 18 17:28:14 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1165421F8469 for ; Wed, 18 Apr 2012 17:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92lcQzwdeWcU for ; Wed, 18 Apr 2012 17:28:10 -0700 (PDT) Received: from n06.mail01.mtsvc.net (mailout08.mail01.mtsvc.net [216.70.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 13D2621F845C for ; Wed, 18 Apr 2012 17:28:10 -0700 (PDT) Received: from [174.136.108.2] (port=53330 helo=[0.0.0.0]) by n06.mail01.mtsvc.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SKfEH-00078N-Eh; Wed, 18 Apr 2012 20:28:09 -0400 Message-ID: <4F8F5C19.3040007@lookout.net> Date: Wed, 18 Apr 2012 17:28:09 -0700 From: Chris Weber User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =JeffH References: <4F8F5404.8020406@KingsMountain.com> In-Reply-To: <4F8F5404.8020406@KingsMountain.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: 882879 chris@lookout.net Cc: IETF WebSec WG Subject: Re: [websec] Acceptance of draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt as WebSec WG documents 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, 19 Apr 2012 00:28:14 -0000 +1 from me too On 4/18/2012 4:53 PM, =JeffH wrote: > +1 to acceptance of both I-Ds. > > =JeffH > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From Jeff.Hodges@KingsMountain.com Fri Apr 20 10:50:56 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 3C4D321F85C5 for ; Fri, 20 Apr 2012 10:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.937 X-Spam-Level: X-Spam-Status: No, score=-99.937 tagged_above=-999 required=5 tests=[AWL=0.558, 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 QzdLJCTyWLmL for ; Fri, 20 Apr 2012 10:50:55 -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 41CA721F85D0 for ; Fri, 20 Apr 2012 10:50:52 -0700 (PDT) Received: (qmail 7913 invoked by uid 0); 20 Apr 2012 17:50:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 20 Apr 2012 17:50:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=YMK4Vn7HLrvnF8ScbUPQjz9Z19WOcfk3kNXtKybaXPU=; b=Jk1GMUIjOa7h/CpnmYPMloDaWI97fwINUcM0HjTIjrV3hxfORUf0yaDiB1ZvM7nrw7P1is7qKxAIEeMToq/nChksNsIR2kDqzeocEGobNO/KcX1sPR/+HzWnuwdsWVpa; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.216]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SLHyr-0001oX-SL; Fri, 20 Apr 2012 11:50:49 -0600 Message-ID: <4F91A1F8.4090501@KingsMountain.com> Date: Fri, 20 Apr 2012 10:50:48 -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: Paul Hoffman , IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] #39: appropriately acknowlege and accommodate DANE 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, 20 Apr 2012 17:50:56 -0000 > #39: appropriately acknowlege and accommodate DANE http://trac.tools.ietf.org/wg/websec/trac/ticket/39 fyi & comment, the text I presently have in my working copy of -07 is.. . . . 2.2. HTTP Strict Transport Security Policy Effects The effects of the HTTP Strict Transport Security (HSTS) Policy, as applied by a UA in interactions with a web resource host wielding such policy (known as a HSTS Host), are summarized as follows: . . 2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings, including those caused by a web application presenting a certificate matching a trusted certificate association as denoted via the DANE protocol [I-D.ietf-dane-protocol], or any other form of self-signed certificate that does not chain to a trust anchor in the UA or operating system CA root certificate store. . . . 10.2. Using HSTS in conjunction with self-signed public-key certificates If a web site/organization/enterprise is generating their own secure transport public-key certificates for web sites, and that organization's root certification authority (CA) certificate is not typically embedded by default in browser and/or operating system CA certificate stores, and if HSTS Policy is enabled on a host identifying itself using a certificate signed by the organization's CA (i.e., a "self-signed certificate"), and this certificate does not match a trusted certificate association (as denoted via the DANE protocol [I-D.ietf-dane-protocol]), then secure connections to that site will fail, per the HSTS design. This is to protect against various active attacks, as discussed above. However, if said organization strongly wishes to employ self-signed certificates, and their own CA in concert with HSTS, they can do so by deploying their root CA certificate to their users' browsers or operating system CA root certificate stores. They can also, in addition or instead, distribute to their users' browsers the end- entity certificate(s) for specific hosts. There are various ways in which this can be accomplished (details are out of scope for this specification). Once their root CA certificate is installed in the browsers, they may employ HSTS Policy on their site(s). Alternately, that organization can deploy the DANE protocol; all browsers that also use DANE will then be able to trust the certificates identified by trusted certificate associations as denoted via DANE. Note: Interactively distributing root CA certificates to users, e.g., via email, and having the users install them, is arguably training the users to be susceptible to a possible form of phishing attack, see Section 14.6 "Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack". Thus care should be taken in the manner in which such certificates are distributed and installed on users' systems and browsers. . . . --- end From paul.hoffman@vpnc.org Fri Apr 20 11:49:06 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 BFA5721F8652 for ; Fri, 20 Apr 2012 11:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 dPo9ZH3+j1RQ for ; Fri, 20 Apr 2012 11:49:06 -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 2A31F21F864F for ; Fri, 20 Apr 2012 11:49:06 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3KIn4Cg049289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 11:49:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F91A1F8.4090501@KingsMountain.com> Date: Fri, 20 Apr 2012 11:49:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5508DE4C-67E1-48F0-8B85-686741E6C0BA@vpnc.org> References: <4F91A1F8.4090501@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1257) Cc: IETF WebSec WG Subject: Re: [websec] #39: appropriately acknowlege and accommodate DANE 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, 20 Apr 2012 18:49:06 -0000 On Apr 20, 2012, at 10:50 AM, =3DJeffH wrote: > > #39: appropriately acknowlege and accommodate DANE > http://trac.tools.ietf.org/wg/websec/trac/ticket/39 >=20 >=20 > fyi & comment, the text I presently have in my working copy of -07 = is.. >=20 > . > . > . > 2.2. HTTP Strict Transport Security Policy Effects >=20 > The effects of the HTTP Strict Transport Security (HSTS) Policy, as > applied by a UA in interactions with a web resource host wielding > such policy (known as a HSTS Host), are summarized as follows: > . > . > 2. The UA terminates any secure transport connection attempts upon > any and all secure transport errors or warnings, including those > caused by a web application presenting a certificate matching a > trusted certificate association as denoted via the DANE protocol > [I-D.ietf-dane-protocol], or any other form of self-signed > certificate that does not chain to a trust anchor in the UA or > operating system CA root certificate store. I don't think this is what you meant. It sounds like that using DANE is = considered a transport error or warning. Proposed fix: 2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings, including those caused by a web application presenting self-signed certificates that do not chain to a trust anchor in the UA or operating system CA root certificate store, except when the self-signed = certificate is part of a validated certificate association as defined in [I-D.ietf-dane-protocol]. --Paul Hoffman From Jeff.Hodges@KingsMountain.com Fri Apr 20 14:18: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 70AA421F8552 for ; Fri, 20 Apr 2012 14:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.048 X-Spam-Level: X-Spam-Status: No, score=-100.048 tagged_above=-999 required=5 tests=[AWL=0.447, 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 5lQu1GIg2ZH8 for ; Fri, 20 Apr 2012 14:18:58 -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 96B3B21F854D for ; Fri, 20 Apr 2012 14:18:58 -0700 (PDT) Received: (qmail 2629 invoked by uid 0); 20 Apr 2012 21:18:58 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 20 Apr 2012 21:18: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=hY8sCqxCtPUdxQ12rVx+p6krdeywH2jZt+sHSevnCUc=; b=66a3COr55p5fUOiQCeMkgamBvs14YTSSfIwe2mMa74LG6Xk0JutKfZjm0iBeUHU1p13+H/bskrXn41N70ztmJ+MxWkIqDS7LeWP9dpRJUq7LWEiibZqUcG4mK/lA79rS; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.216]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SLLEH-0002Cp-6q; Fri, 20 Apr 2012 15:18:57 -0600 Message-ID: <4F91D2BE.7050305@KingsMountain.com> Date: Fri, 20 Apr 2012 14:18:54 -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: Paul Hoffman , IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] #39: appropriately acknowlege and accommodate DANE 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, 20 Apr 2012 21:18:59 -0000 Paul Hoffman noted: > On Apr 20, 2012, at 10:50 AM, =JeffH wrote: > >> > #39: appropriately acknowlege and accommodate DANE >> http://trac.tools.ietf.org/wg/websec/trac/ticket/39 >> >> >> fyi & comment, the text I presently have in my working copy of -07 is.. >> >> . >> . >> . >> 2.2. HTTP Strict Transport Security Policy Effects >> >> The effects of the HTTP Strict Transport Security (HSTS) Policy, as >> applied by a UA in interactions with a web resource host wielding >> such policy (known as a HSTS Host), are summarized as follows: >> . >> . >> 2. The UA terminates any secure transport connection attempts upon >> any and all secure transport errors or warnings, including those >> caused by a web application presenting a certificate matching a >> trusted certificate association as denoted via the DANE protocol >> [I-D.ietf-dane-protocol], or any other form of self-signed >> certificate that does not chain to a trust anchor in the UA or >> operating system CA root certificate store. > > I don't think this is what you meant. It sounds like that using DANE is considered a transport error or warning. Proposed fix: > > 2. The UA terminates any secure transport connection attempts upon > any and all secure transport errors or warnings, including those > caused by a web application presenting self-signed certificates > that do not chain to a trust anchor in the UA or operating system > CA root certificate store, except when the self-signed certificate > is part of a validated certificate association as defined in > [I-D.ietf-dane-protocol]. thanks. hm... In looking at this section, which is attempting to only (non-normatively) summarize the effects of the HSTS policy, it occurs to me it should be streamlined down to.. 2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings. ..because section 10.2 now addresses details wrt "self-signed certs" and such. Section 2.2 in my working copy is now.. ### 2.2. HTTP Strict Transport Security Policy Effects The effects of the HTTP Strict Transport Security (HSTS) Policy, as applied by a conformant UA in interactions with a web resource host wielding such policy (known as a HSTS Host), are summarized as follows: 1. UAs transform insecure URI references to a HSTS Host into secure URI references before dereferencing them. 2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings. ### =JeffH From paul.hoffman@vpnc.org Fri Apr 20 14:32:32 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A7021F8573 for ; Fri, 20 Apr 2012 14:32:32 -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 iGU0fNYajjVl for ; Fri, 20 Apr 2012 14:32:32 -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 DEF1621F856D for ; Fri, 20 Apr 2012 14:32:31 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3KLWTC6055000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2012 14:32:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F91D2BE.7050305@KingsMountain.com> Date: Fri, 20 Apr 2012 14:32:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F91D2BE.7050305@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1257) Cc: IETF WebSec WG Subject: Re: [websec] #39: appropriately acknowlege and accommodate DANE 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, 20 Apr 2012 21:32:32 -0000 On Apr 20, 2012, at 2:18 PM, =3DJeffH wrote: > In looking at this section, which is attempting to only = (non-normatively) summarize the effects of the HSTS policy, it occurs to = me it should be streamlined down to.. >=20 >=20 > 2. The UA terminates any secure transport connection attempts upon > any and all secure transport errors or warnings. >=20 >=20 > ..because section 10.2 now addresses details wrt "self-signed certs" = and such. That would be *much* better for section 2. Any "such as" will fool = implementers into thinking you have a complete list. --Paul Hoffman From alexey.melnikov@isode.com Tue Apr 24 10:29: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 ADE8A21F8832 for ; Tue, 24 Apr 2012 10:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 Sn+UAmmCtFwi for ; Tue, 24 Apr 2012 10:29:00 -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 BDBB521F8830 for ; Tue, 24 Apr 2012 10:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335288538; d=isode.com; s=selector; i=@isode.com; bh=amSlCBdWfHqqzbm1l7w2b30OyfoF8Od8Z4VZ8Sx6ytM=; 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=dkzLNIWVqeZOS3gb89mWSywr7NScbARKWdA5DRwBnkeLGpYsuril49RLvI8rxBdFDMoiPp uWi9gYhDqvNTA+i9/KzV+s0t31EcvP2ODtBttu7csXkWvLWMW3ob5ZiGU7ccdUt1Mx/W42 cE03dcyn0ps8bvhTNwPZHp3kkZcmYq4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 24 Apr 2012 18:28:58 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F96E2E9.5050008@isode.com> Date: Tue, 24 Apr 2012 18:29:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: IETF WebSec WG References: <4F8B39B9.3060304@isode.com> In-Reply-To: <4F8B39B9.3060304@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] Acceptance of draft-gondrom-frame-options-02.txt and draft-gondrom-x-frame-options-00.txt as WebSec WG documents 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, 24 Apr 2012 17:29:00 -0000 On 15/04/2012 22:12, Alexey Melnikov wrote: > Dear WG participants, > draft-gondrom-frame-options-02.txt and > draft-gondrom-x-frame-options-00.txt (and their earlier version) were > discussed in a couple of WG face-to-face meetings. I believe both of > the documents are in scope for the WG Charter and I think there is > support for working on them. > > As both of these documents are co-edited by Tobias, I will be judging > consensus on them. draft-gondrom-frame-options is targeted to become a > Proposed Standard, while draft-gondrom-x-frame-options will be an > Informational document (as it documents existing header field). So I > would like to start a one week acceptance call for these documents as > WebSec WG documents. Please send me your objections or statements of > support directly to me or to the mailing list before midnight GMT+1 on > April 23rd. The deadline has passed and I haven't seen any objections, so these documents are now accepted as WebSec WG documents.Thank you, > Alexey, as a WebSec co-chair From julian.reschke@gmx.de Wed Apr 25 23:54: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 3A76021F87CF for ; Wed, 25 Apr 2012 23:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 yJTwrpF0GFDy for ; Wed, 25 Apr 2012 23:54:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 64C0D21F888F for ; Wed, 25 Apr 2012 23:54:11 -0700 (PDT) Received: (qmail invoked by alias); 26 Apr 2012 05:54:10 -0000 Received: from 178-83-198-62.dynamic.hispeed.ch (EHLO [192.168.1.103]) [178.83.198.62] by mail.gmx.net (mp072) with SMTP; 26 Apr 2012 07:54:10 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/MkPVsSSDMDGYXkDPqRbL8EzkzuzK7AiWH0LNQlA aMkcP6QLmyIscM Message-ID: <4F98E300.3040808@gmx.de> Date: Thu, 26 Apr 2012 07:54:08 +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: Robin Berjon References: <8DBE093F-71A7-4AF0-8FC5-DF67F9CF19DD@berjon.com> In-Reply-To: <8DBE093F-71A7-4AF0-8FC5-DF67F9CF19DD@berjon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Philippe Le Hegaret , Mark Nottingham , websec , "www-tag@w3.org List" Subject: Re: [websec] ACTION-686: Sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 06:54:13 -0000 On 2012-04-25 21:26, Robin Berjon wrote: > Hi all, > > I was given the action item to check up on where content sniffing is at and who's editing it. > > I can confirm that the proper reference document is this one http://mimesniff.spec.whatwg.org/ and that Adam Barth is editing it. > > I guess that that would make for a better reference than the I-D that expired, maybe the Widget Rec should be edited in place to reflect that (but that's an issue for WebApps to worry about). > > I don't think that the TAG has any business applying itself to specification engineering issues such as unstable references; doubly so since this one is already covered by common practice (which also means no AB involvement since it's custom and not law). The spec is still mentioned as a deliverable of the IEF Websec Working Group: It appears coordination is needed. Best regards, Julian From msk@cloudmark.com Sun Apr 29 00:11:46 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 279D721F849C for ; Sun, 29 Apr 2012 00:11:46 -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.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmAfAMn3ArFM for ; Sun, 29 Apr 2012 00:11:44 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEE021F844B for ; Sun, 29 Apr 2012 00:11:44 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 3jBi1j0010as01C01jBi3Q; Sun, 29 Apr 2012 00:11:45 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=K4ag7lqI c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=avgx2eInZzkA:10 a=-w2GM7y7aYgA:10 a=zutiEJmiVI4A:10 a=WoLjiF6ve7AA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=TDYAGFK6AAAA:8 a=A1X0JdhQAAAA:8 a=YLdlEpOvAAAA:8 a=_0Nle5OOUZlvcOWdENMA:9 a=3TrdVEZvrVe5i4CMYjUA:7 a=CjuIK1q_8ugA:10 a=vYwTUIGbb5EA:10 a=Hn6JTXX_6TUA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=6xKn5IHmBtXPfkRWwCUA:9 a=Q3ccDL5MLOD-0PAdZzoA:7 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=KWZX7jh02wsA:10 a=WNhuW-6je1UA: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; Sun, 29 Apr 2012 00:11:19 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "websec@ietf.org" , "draft-ietf-websec-strict-transport-sec@tools.ietf.org" Thread-Topic: AppsDir review of draft-ietf-websec-strict-transport-sec Thread-Index: Ac0l10W9SlaETdSSRZWdVKRKL9Sksw== Date: Sun, 29 Apr 2012 07:11:18 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.158] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E003928106147exchmbx901corpclo_" MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1335683505; bh=1wfW6vtGHAxRPLbEdKUy+G1EqpPiwbwzD+K8umLlwBE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=WCG5IvbomSCvLpnjSAh/Q6UExXXsX+jxblY+z4j7XytfTc9+/P4uwFmne8tHVUwCD rbOXOPYLFl5AcLXqBwwF11Nri0hWlQ1AJCgy2WAxF6jvME65bxUbXwGFko5Mj6iZH4 upS2ConI/7F9MyDKLfC9qDEvIUyv+wMeo69s6x+g= Subject: [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: Sun, 29 Apr 2012 07:11:46 -0000 --_000_9452079D1A51524AA5749AD23E003928106147exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft. (For background on appsdir, please see http://trac.tools.ietf.org/= area/app/trac/wiki/ApplicationsAreaDirectorate). [NOTE: This is a pre-Last Call review requested by the Applications Area Di= rectors. Please disregard any boilerplate indicating otherwise.] Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD be= fore posting a new version of the draft. Document: draft-ietf-websec-strict-transport-sec-06 Title: HTTP Strict Transport Security (HSTS) Reviewer: Murray S. Kucherawy Review Date: April 28, 2012 IETF Last Call Date: n/a IESG Telechat Date: n/a Summary: This draft is almost ready for publication as a Standards Track RF= C, but has a few issues that should be fixed before publication. Reviewer Synopsis: The document specifies methods by which providers of web= -based services can signal to users (and their web clients) that their serv= ices should only be accessed via secure mechanisms. It also gives a detail= ed treatment of the threat model leading to the proposal it contains. This is one of the more well-written drafts I've reviewed in some time. It= 's clear and very complete in terms of presenting the background, which is = very helpful to readers (and reviewers!) not expert in this area. MAJOR ISSUES: None. MINOR ISSUES: Section 2.3.2: Your Security Considerations section should probably include= a pointer to this section. Section 3: Are the latter two paragraphs really necessary? I only find suc= h statements useful when minimum conformance is not the same thing as full = conformance. Section 4, HTTP Strict Transport Security Host: Should this say "for all we= b pages it serves" or similar? Section 4: Expand ABNF on first use, and include a reference to RFC5234. (= The reference could instead go in Section 6.) Section 6.1: The ABNF you have there requires a leading semi-colon. Based = on your examples, I think instead you want: Strict-Transport-Security =3D "Strict-Transport-Security" ":" directive *( ";" [directive] ) Note that this also allows: Strict-Transport-Security: foobar;;;;;;;;;;;; Is that okay? Section 6.1: What's "the STS directive extension point"? Section 6.1.1: I think the "delta-seconds" should be: delta-seconds =3D 1*DIGIT ; defined in Section 3.3.2 of [RFC2616] The angle-bracket notation you have there doesn't seem to be normal. Section 6.2: The second example isn't strictly correct because no space is = allowed around the semi-colon in the ABNF in Section 6.1. It looks like yo= u'll need to add optional whitespace at various points in the ABNF, or corr= ect the example. Section 8.1: The "Note:" includes stuff that should be normative, and thus = is not appropriate for a side discussion note. It doesn't quite jive with = how you've defined use of "Note:" as a document convention. Section 8.2: The "Note that..." at the end threw me for a loop. How does w= hat's said in 8.2 imply what's stated here? For example, what does it say = about SMTP or FTP? Section 10.1: This discussion got me wondering why an absolute time for HST= S Policy expiration isn't used instead of a delta. Perhaps that could be e= xplained somewhere like Appendix A. (Yes, I know about time synchronizatio= n, but this text gave me pause.) Section 10.3: "example-ca.com" is not a reserved domain name for use in exa= mples. Suggest "ca.example.com" or "ca.example". Same issue with "example= -ca-services.net". Section 14.2: The "but the attacker has established somewhere" clause doesn= 't parse for me. What's it trying to say? NITS (mostly trying to save the RFC Editor some work here): There are so many important references to [ForceHTTPS] that I think it migh= t be helpful to include page or section numbers for those. Section 1: The Abstract uses "Web" as a proper noun, but this section inclu= des uses of it that are all lowercase. I believe it should be used one way= or the other throughout the document. Section 1: "Section", when referring to a section of a document, should be = capitalized. (Also occurs in a few other places.) Section 2.2: s/known as a HSTS Host/known as an HSTS Host/ Section 2.2, bullet 1: s/to be/such that they are replaced by/ Section 2.2, bullet 3: s/to a HSTS Host/to an HSTS Host/ Section 2.3.1.1: Define or provide a reference for what Firefox is, in case= it's somehow not in common use at the time some future reader gets this. Section 2.3.1.2: Define or expand "CA" on first use. For that matter, woul= d it be possible to reference something that talks about the difference bet= ween self-signed and CA-signed certificates, and why they get different tre= atment? Section 2.3.1.3: Define or expand "SWF" on first use. Section 2.3.1.3: s/by injecting script/by injecting a script/ Section 2.4.1.1, bullet 1: s/interacted with/accessed/ Section 2.4.1.1, bullet 3: s/to persistently remember/to retain persistent = data about/ Section 2.4.1.1, ending Note: The last "," should be a ";", or a period fol= lowed by a new sentence. Section 4: Suggest ending terms with ":" so that you don't get things like = how "domain name label" looks in this version of the draft. Section 4, "HTTP Strict Transport Security Host": s/policy/Policy/, so it's= clear we're using your definition. Section 4, "HTTP Strict Transport Security Policy": Is "Policy" right here?= Isn't it really a "Protocol"? Section 4, "HTTP Strict Transport Security Policy": s/specified/defined/ (s= o as to avoid "specified in this specification") Section 4, "Known HSTS Host": s/a HSTS/an HSTS/; two instances Section 4, "Local policy": Why is "configuration settings" quoted? Section 4, "unknown HSTS Host": s/a HSTS/an HSTS/ Section 5 and beyond: You define "HSTS Policy" and "HSTS Host" (note capita= lization), but use "HSTS policy" and "HSTS host" in numerous places. Best = to be consistent, so it's clear you're referring to the defined term. Section 5, second paragraph: All-lowercase "may" should probably be "MAY". Section 6.1.2: s/which/that/ Section 7: s/facets:/facets,/; s/the second/and the second/ Section 7.1: s/a STS header/an STS header/; two instances Section 7.1: s/difficult to uniformly emit STS header fields/difficult to e= mit STS header fields uniformly/ Section 7.2, second bullet: Add a matching "--" after "components". Section 8.1: s/a STS header/an STS header/; s/field, /field / Section 8.1.1: s/a HSTS Host/an HSTS Host/ Section 8.1.1: s/that the host responded to/to which the host responded/ Section 8.1.1: That last paragraph is one big long sentence. Suggest break= ing it up. Section 8.5: The "For example, ..." is a sentence fragment. Section 9, bullet 2: Remove the "," after "label". Section 9, bullet 2: s/latter,/latter;/ Section 9, bullet 3: The (".") should come after the hex. Section 10: "This section is non-normative." (cringe; I'm still of the opi= nion that a section is implicitly non-normative if it has no normative text= in it, an d these notations are extraneous) Section 10.1, fourth paragraph: This is another sentence fragment. Section 10.2: s/their own/its own/ (the noun is singular, the verb has to a= gree) Section 10.2, second paragraph: s/certificates, and their own/certificates = and its own/; various other "their/they" to "its/it", because "organization= " isn't plural Section 10.2, note: s/attack, see/attack. See/ Section 10.3: s/implications -- for/implications. For/ Section 10.3, second paragraph: s/which/that/ Section 10.3: s/HSTS, and that have/HSTS that have/; s/application, would/a= pplication would/ Section 11: (cringe) Section 11: You variably spell it "implementors" and "implementers". I'm p= retty sure the latter is correct, but either way, some of them are not. :-= ) Section 11.1: s/Establishment"),/Establishment")/ Section 11.2: s/a HSTS Host/an HSTS Host/ Section 11.2, Note: s/basis -- see/basis. See/ Section 11.2, Note: s/is independent of/is independent of,/ Section 11.2: Opens with a non-sentence. Section 11.3: Opens with a non-sentence. Section 11.4: Opens with a non-sentence. Section 11.4, Note: s/to more clearly define the term(s)/to define the term= (s) more clearly/ Section 11.5: Opens with a non-sentence. Section 12: All lowercase MUST here. Section 12.2: Seriously nitty here: The "host, and the port (if present)" d= oesn't make it clear if the separating colon is included. Section 14.1, first bullet: Missing close parenthesis. Section 14.1, second bullet: s/to no longer be regarded/to cease being rega= rded/ Section 14.1: s/And even if the risk/Even if the risk/ Section 14.1: s/as a HSTS Host. Thus as/as an HSTS Host. Thus, as/ Section 14.1: s/But once/Once/ Section 14.2: s/to adequately protect/to provide adequate protection for/ Section 14.3: s/to manually configure HSTS Policy/to configure HSTS Policy = manually/ Section 14.3, third "*" bullet: Contains two sentence fragments. Section 14.3, final paragraph: s/to automatically regard/to regard automati= cally/ Section 14.5: Expand NTP on first use, and provide a reference. Section 14.6: Opens with a sentence fragment. -MSK --_000_9452079D1A51524AA5749AD23E003928106147exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area Direct= orate reviewer for this draft.  (For background on appsdir, please see= http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= .

 

[NOTE: This is a pre-Last Call review requested by t= he Applications Area Directors.  Please disregard any boilerplate indi= cating otherwise.]

 

Please resolve these comments along with any other L= ast Call comments you may receive.  Please wait for direction from you= r document shepherd or AD before posting a new version of the draft.

 

Document: draft-ietf-websec-strict-transport-sec-06<= o:p>

Title: HTTP Strict Transport Security (HSTS)

Reviewer: Murray S. Kucherawy

Review Date: April 28, 2012

IETF Last Call Date: n/a

IESG Telechat Date: n/a

 

Summary: This draft is almost ready for publication = as a Standards Track RFC, but has a few issues that should be fixed before = publication.

 

Reviewer Synopsis: The document specifies methods by= which providers of web-based services can signal to users (and their web c= lients) that their services should only be accessed via secure mechanisms.&= nbsp; It also gives a detailed treatment of the threat model leading to the proposal it contains.

 

This is one of the more well-written drafts I've rev= iewed in some time.  It's clear and very complete in terms of presenti= ng the background, which is very helpful to readers (and reviewers!) not ex= pert in this area.

 

MAJOR ISSUES:

 

None.

 

MINOR ISSUES:

 

Section 2.3.2: Your Security Considerations section = should probably include a pointer to this section.

 

Section 3: Are the latter two paragraphs really nece= ssary?  I only find such statements useful when minimum conformance is= not the same thing as full conformance.

 

Section 4, HTTP Strict Transport Security Host: Shou= ld this say "for all web pages it serves" or similar?<= /p>

 

Section 4: Expand ABNF on first use, and include a r= eference to RFC5234.  (The reference could instead go in Section 6.)

 

Section 6.1: The ABNF you have there requires a lead= ing semi-colon.  Based on your examples, I think instead you want:

 

        Strict-Tr= ansport-Security =3D "Strict-Transport-Security" ":"

        &nbs= p;            &= nbsp;           &nbs= p;  directive *( ";" [directive] )

 

Note that this also allows:

 

        Strict-Tr= ansport-Security: foobar;;;;;;;;;;;;

 

Is that okay?

 

Section 6.1: What's "the STS directive extensio= n point"?

 

Section 6.1.1: I think the "delta-seconds"= should be:

 

        delta-sec= onds =3D 1*DIGIT

        &nbs= p;             = ; defined in Section 3.3.2 of [RFC2616]

 

The angle-bracket notation you have there doesn't se= em to be normal.

 

Section 6.2: The second example isn't strictly corre= ct because no space is allowed around the semi-colon in the ABNF in Section= 6.1.  It looks like you'll need to add optional whitespace at various= points in the ABNF, or correct the example.

 

Section 8.1: The "Note:" includes stuff th= at should be normative, and thus is not appropriate for a side discussion n= ote.  It doesn't quite jive with how you've defined use of "Note:= " as a document convention.

 

Section 8.2: The "Note that..." at the end= threw me for a loop.  How does what's said in 8.2 imply what's stated= here?  For example, what does it say about SMTP or FTP?

 

Section 10.1: This discussion got me wondering why a= n absolute time for HSTS Policy expiration isn't used instead of a delta.&n= bsp; Perhaps that could be explained somewhere like Appendix A.  (Yes,= I know about time synchronization, but this text gave me pause.)

 

Section 10.3: "example-ca.com" is not a re= served domain name for use in examples.  Suggest "ca.example.com&= quot; or "ca.example".  Same issue with "example-ca-ser= vices.net".

 

Section 14.2: The "but the attacker has establi= shed somewhere" clause doesn't parse for me.  What's it trying to= say?

 

NITS (mostly trying to save the RFC Editor some work= here):

 

There are so many important references to [ForceHTTP= S] that I think it might be helpful to include page or section numbers for = those.

 

Section 1: The Abstract uses "Web" as a pr= oper noun, but this section includes uses of it that are all lowercase.&nbs= p; I believe it should be used one way or the other throughout the document= .

 

Section 1: "Section", when referring to a = section of a document, should be capitalized.  (Also occurs in a few o= ther places.)

 

Section 2.2: s/known as a HSTS Host/known as an HSTS= Host/

 

Section 2.2, bullet 1: s/to be/such that they are re= placed by/

 

Section 2.2, bullet 3: s/to a HSTS Host/to an HSTS H= ost/

 

Section 2.3.1.1: Define or provide a reference for w= hat Firefox is, in case it's somehow not in common use at the time some fut= ure reader gets this.

 

Section 2.3.1.2: Define or expand "CA" on = first use.  For that matter, would it be possible to reference somethi= ng that talks about the difference between self-signed and CA-signed certif= icates, and why they get different treatment?

 

Section 2.3.1.3: Define or expand "SWF" on= first use.

 

Section 2.3.1.3: s/by injecting script/by injecting = a script/

 

Section 2.4.1.1, bullet 1: s/interacted with/accesse= d/

 

Section 2.4.1.1, bullet 3: s/to persistently remembe= r/to retain persistent data about/

 

Section 2.4.1.1, ending Note: The last ","= should be a ";", or a period followed by a new sentence.

 

Section 4: Suggest ending terms with ":" s= o that you don't get things like how "domain name label" looks in= this version of the draft.

 

Section 4, "HTTP Strict Transport Security Host= ": s/policy/Policy/, so it's clear we're using your definition.

 

Section 4, "HTTP Strict Transport Security Poli= cy": Is "Policy" right here?  Isn't it really a "P= rotocol"?

 

Section 4, "HTTP Strict Transport Security Poli= cy": s/specified/defined/ (so as to avoid "specified in this spec= ification")

 

Section 4, "Known HSTS Host": s/a HSTS/an = HSTS/; two instances

 

Section 4, "Local policy": Why is "co= nfiguration settings" quoted?

 

Section 4, "unknown HSTS Host": s/a HSTS/a= n HSTS/

 

Section 5 and beyond: You define "HSTS Policy&q= uot; and "HSTS Host" (note capitalization), but use "HSTS po= licy" and "HSTS host" in numerous places.  Best to be c= onsistent, so it's clear you're referring to the defined term.

 

Section 5, second paragraph: All-lowercase "may= " should probably be "MAY".

 

Section 6.1.2: s/which/that/

 

Section 7: s/facets:/facets,/; s/the second/and the = second/

 

Section 7.1: s/a STS header/an STS header/; two inst= ances

 

Section 7.1: s/difficult to uniformly emit STS heade= r fields/difficult to emit STS header fields uniformly/

 

Section 7.2, second bullet: Add a matching "--&= quot; after "components".

 

Section 8.1: s/a STS header/an STS header/; s/field,= /field /

 

Section 8.1.1: s/a HSTS Host/an HSTS Host/

 

Section 8.1.1: s/that the host responded to/to which= the host responded/

 

Section 8.1.1: That last paragraph is one big long s= entence.  Suggest breaking it up.

 

Section 8.5: The "For example, ..." is a s= entence fragment.

 

Section 9, bullet 2: Remove the "," after = "label".

 

Section 9, bullet 2: s/latter,/latter;/

 

Section 9, bullet 3: The (".") should come= after the hex.

 

Section 10: "This section is non-normative.&quo= t;  (cringe; I'm still of the opinion that a section is implicitly non= -normative if it has no normative text in it, an

d these notations are extraneous)

 

Section 10.1, fourth paragraph: This is another sent= ence fragment.

 

Section 10.2: s/their own/its own/ (the noun is sing= ular, the verb has to agree)

 

Section 10.2, second paragraph: s/certificates, and = their own/certificates and its own/; various other "their/they" t= o "its/it", because "organization" isn't plural

 

Section 10.2, note: s/attack, see/attack.  See/=

 

Section 10.3: s/implications -- for/implications.&nb= sp; For/

 

Section 10.3, second paragraph: s/which/that/

 

Section 10.3: s/HSTS, and that have/HSTS that have/;= s/application, would/application would/

 

Section 11: (cringe)

 

Section 11: You variably spell it "implementors= " and "implementers".  I'm pretty sure the latter is co= rrect, but either way, some of them are not.  :-)

 

Section 11.1: s/Establishment"),/Establishment&= quot;)/

 

Section 11.2: s/a HSTS Host/an HSTS Host/=

 

Section 11.2, Note: s/basis -- see/basis.  See/=

 

Section 11.2, Note: s/is independent of/is independe= nt of,/

 

Section 11.2: Opens with a non-sentence.<= /p>

 

Section 11.3: Opens with a non-sentence.<= /p>

 

Section 11.4: Opens with a non-sentence.<= /p>

 

Section 11.4, Note: s/to more clearly define the ter= m(s)/to define the term(s) more clearly/

 

Section 11.5: Opens with a non-sentence.<= /p>

 

Section 12: All lowercase MUST here.

 

Section 12.2: Seriously nitty here: The "host, = and the port (if present)" doesn't make it clear if the separating col= on is included.

 

Section 14.1, first bullet: Missing close parenthesi= s.

 

Section 14.1, second bullet: s/to no longer be regar= ded/to cease being regarded/

 

Section 14.1: s/And even if the risk/Even if the ris= k/

 

Section 14.1: s/as a HSTS Host.  Thus as/as an = HSTS Host.  Thus, as/

 

Section 14.1: s/But once/Once/

 

Section 14.2: s/to adequately protect/to provide ade= quate protection for/

 

Section 14.3: s/to manually configure HSTS Policy/to= configure HSTS Policy manually/

 

Section 14.3, third "*" bullet: Contains t= wo sentence fragments.

 

Section 14.3, final paragraph: s/to automatically re= gard/to regard automatically/

 

Section 14.5: Expand NTP on first use, and provide a= reference.

 

Section 14.6: Opens with a sentence fragment.

 

-MSK

--_000_9452079D1A51524AA5749AD23E003928106147exchmbx901corpclo_-- From alexey.melnikov@isode.com Mon Apr 30 03:43: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 92D8921F85B5 for ; Mon, 30 Apr 2012 03:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, 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 x8fKPVMxxMgG for ; Mon, 30 Apr 2012 03:43:04 -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 A4A0D21F85AF for ; Mon, 30 Apr 2012 03:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335782581; d=isode.com; s=selector; i=@isode.com; bh=STJugyGHIdtzmc5K5YqnWBXooXLDACAWhREMUziRneg=; 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=aBUh+E8QDgD89oc9EG9DHAzZsAH2gQRQtUViv2jOP6b2zCjOAulw0eBEkQEWIBuNlRMApn bEYxpMBpYUwYQ/Ad/oRssCr2n6/5DcfHdjlC+hD6mngvbSfg/o9hfrbj4+faHc6mcQjwq5 MB2Xxajow/kXYBm4cedBFNJBDw0J4FI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 30 Apr 2012 11:43:01 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F9E6CD3.5020706@isode.com> Date: Mon, 30 Apr 2012 11:43:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: IETF WebSec WG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Minutes for the Paris (IETF 83) meeting X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 10:43:04 -0000 Sorry for being late with this: http://www.ietf.org/proceedings/83/minutes/minutes-83-websec.txt Corrections are welcome, especially for things reported as "missed what he/she said". Special thank you to Richard Barnes for being our jabber scribe in Paris. From trac+websec@trac.tools.ietf.org Mon Apr 30 09:47: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 5EF4821F87A3 for ; Mon, 30 Apr 2012 09:47:59 -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 Jx9nQ-zARLgN for ; Mon, 30 Apr 2012 09:47:58 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DD61921F8796 for ; Mon, 30 Apr 2012 09:47:58 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOtl7-0001qw-F4; Mon, 30 Apr 2012 12:47: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: Mon, 30 Apr 2012 16:47:32 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/43 Message-ID: <070.a272a1155a8eb877ff88d2ef3522188e@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 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: <20120430164758.DD61921F8796@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 09:47:58 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ? 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: Mon, 30 Apr 2012 16:47:59 -0000 #43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ? [ this issue is forked from http://trac.tools.ietf.org/wg/websec/trac/ticket/40 ] > https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter > > Section 7.2 > > Does is make sense to mention that status code 308 might be > appropriate in certain circumstances? See draft-reschke-http-status-308. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: enhancement | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: websec From julian.reschke@gmx.de Mon Apr 30 10:03:23 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 6384221F87E2 for ; Mon, 30 Apr 2012 10:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.161 X-Spam-Level: X-Spam-Status: No, score=-103.161 tagged_above=-999 required=5 tests=[AWL=-0.562, 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 ZXfXidrLRzkI for ; Mon, 30 Apr 2012 10:03:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9321121F8749 for ; Mon, 30 Apr 2012 10:03:20 -0700 (PDT) Received: (qmail invoked by alias); 30 Apr 2012 17:03:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 30 Apr 2012 19:03:18 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18NpVEGLTANJSVuRMcFog+hZCuCbuiyokVIHUvTlJ vCRFms5iVjHdWP Message-ID: <4F9EC5BD.7000404@gmx.de> Date: Mon, 30 Apr 2012 19:02: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> In-Reply-To: <9452079D1A51524AA5749AD23E003928106147@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: Mon, 30 Apr 2012 17:03:23 -0000 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". > ... > The angle-bracket notation you have there doesn't seem to be normal. > ... It's a prose rule; see RFC 5234 prose-val. It's used here to define the ABNF rule "by reference". The reference form in theory is safer because there's only a single definition, so no conflicts are possible. Best regards, Julian PS: we use the prose-val style a lot in HTTPbis for referencing ABNF from other documents, so if there's a problem with that I'd like to learn ASAP about it :-) From trac+websec@trac.tools.ietf.org Mon Apr 30 10:04:07 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1135D21F87F5 for ; Mon, 30 Apr 2012 10:04:06 -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 42l7XpXNyUyo for ; Mon, 30 Apr 2012 10:04:04 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 720DF21F87EA for ; Mon, 30 Apr 2012 10:04:04 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOu0q-0006Cr-Ln; Mon, 30 Apr 2012 13:03:48 -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: Mon, 30 Apr 2012 17:03:48 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/44 Message-ID: <070.91ab9f8dc677f5c51032c93d6182c32d@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 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: <20120430170404.720DF21F87EA@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 10:04:04 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #44: terminology for referring to complete domain name (FQDN) possibly containing IDN labels 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: Mon, 30 Apr 2012 17:04:07 -0000 #44: terminology for referring to complete domain name (FQDN) possibly containing IDN labels [ this issue is forked from http://trac.tools.ietf.org/wg/websec/trac/ticket/40 ] https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter > Section 9 > > The phrase "valid Unicode-encoded string-serialized domain name" seems > a bit strange, because we don't typically refer to Unicode as an > encoding scheme. See RFC 6365 regarding such terminology. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Apr 30 10:08:42 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B3921F8812 for ; Mon, 30 Apr 2012 10:08:42 -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 vl2v8jJhUemC for ; Mon, 30 Apr 2012 10:08:41 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 68B7721F880D for ; Mon, 30 Apr 2012 10:08:41 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOu5U-00070m-Dc; Mon, 30 Apr 2012 13:08:36 -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: Mon, 30 Apr 2012 17:08:36 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/40#comment:1 Message-ID: <085.da3c7e351696b632acd3a06497d33c24@trac.tools.ietf.org> References: <070.2b15f3c9acfbd2014856105820738ee9@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <070.2b15f3c9acfbd2014856105820738ee9@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: <20120430170841.68B7721F880D@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 10:08:41 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #40: Various 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: Mon, 30 Apr 2012 17:08:42 -0000 #40: Various editorial comments on -06 Comment (by jeff.hodges@…): forked two items to their own tickets... > Section 7.2 > > Does is make sense to mention that status code 308 might be > appropriate in certain circumstances? See draft-reschke-http-status-308. forked to Ticket #43 http://trac.tools.ietf.org/wg/websec/trac/ticket/43 > Section 9 > > The phrase "valid Unicode-encoded string-serialized domain name" seems > a bit strange, because we don't typically refer to Unicode as an > encoding scheme. See RFC 6365 regarding such terminology. forked to ticket #44 http://trac.tools.ietf.org/wg/websec/trac/ticket/44 -- -------------------------+------------------------------------------------- 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 Mon Apr 30 10:19:37 2012 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEEE21F8851 for ; Mon, 30 Apr 2012 10:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a5NtWtaSYIl for ; Mon, 30 Apr 2012 10:19:36 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3170E21F8850 for ; Mon, 30 Apr 2012 10:19:35 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOuFt-0005cT-1n; Mon, 30 Apr 2012 13:19: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, julian.reschke@gmx.de X-Trac-Project: websec Date: Mon, 30 Apr 2012 17:19:20 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/43#comment:1 Message-ID: <085.fbb5cb1c16993206d285c5ccc7ea43d0@trac.tools.ietf.org> References: <070.a272a1155a8eb877ff88d2ef3522188e@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <070.a272a1155a8eb877ff88d2ef3522188e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, julian.reschke@gmx.de, 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: <20120430171936.3170E21F8850@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 10:19:35 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ? 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: Mon, 30 Apr 2012 17:19:37 -0000 #43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ? Comment (by julian.reschke@…): In a perfect world yes :-) But 308 is new, experimental, not well supported, and introduces an indirect dependency on HTTPbis. Proposal: rephrase the normative requirement so that sending 308 instead of 301 is *possible* (say "permanent redirect", and list 301 as example). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: enhancement | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From Jeff.Hodges@KingsMountain.com Mon Apr 30 15:26: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 D598E21F86CE for ; Mon, 30 Apr 2012 15:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.176 X-Spam-Level: X-Spam-Status: No, score=-100.176 tagged_above=-999 required=5 tests=[AWL=0.319, 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 7+W6I5jpffnx for ; Mon, 30 Apr 2012 15:26:12 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 13C1B21F86C3 for ; Mon, 30 Apr 2012 15:26:10 -0700 (PDT) Received: (qmail 16900 invoked by uid 0); 30 Apr 2012 22:26:09 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 30 Apr 2012 22:26:09 -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=7CYYsHWmwOymM69czGkIDPgrm5cY9F1xUyLe7GIxSb0=; b=EAWdjhOYL44hBwkWOeyxel6dZtdS+OrAr0y5uY1cCkva37gulXR1W1NcaBGuGR22FMcdlxp86aV+m5+fu80h+Q1XhAnQqXHyCPq+MEuVi7cFc3JX+p4KW2JImVqc7GB+; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.153]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SOz2n-0007Tc-Ji; Mon, 30 Apr 2012 16:26:09 -0600 Message-ID: <4F9F117E.4070906@KingsMountain.com> Date: Mon, 30 Apr 2012 15:26:06 -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: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 22:26:14 -0000 thanks for the review Paul. I noticed I didn't respond to some portions of your message that didn't get transformed into issue tickets. here goes... > Significant: > > This document pretends that the TLSA protocol from the DANE WG will not > exist. this item is captured in and has been discussed in a separate thread.. > Moderate: > > In section 8.1.2, I don't know what "ignoring separator characters" means, > and suspect it will cause pain if left this way. That phrase is simply deleted in my -07 working copy. > [I-D.ietf-tls-ssl-version3] is not a "work in progress". I'll take this up > on the rfc-interest mailing list, and nothing needs to be done here. That is addressed in my working copy via ref of (the recently published) [RFC6101] instead. > RFC 2818 is listed as a normative reference, and yet it is Informational. > This will need to be called out in the PROTO report. Alternately, it can be > called an informative reference, since one does not need to understand it > in order to implement this document. this item was addressed by Alexey in his reply here.. > I have alerted the idna-update mailing list of this WG LC. This might cause > some helicoptered-in comments, but better now than during IETF LC. I had noticed that. I'll followup there once -07 is pub'd. Note that I'd engaged in non-trivial discussions there on idna-update@ about various aspects of -strict-transport-sec back in Sep-2011... ..and I have some hopefull-improved IDNA language in my -07 working copy. > Editorial: > > "annunciate" (used a few times) is a fancy word for "announce". Maybe use > the far more common word instead. > > In section 3.1, "suboptimal downside" is unclear. Is there an optimal > downside? I suggest replacing it with "negative". > > The lead sentences in sections 11.2, 11.4, and 11.5 lack verbs; verbs are > used in 11.1 and 11.3. This should be an easy fix. the above are captured in issue ticket #40 thanks again, =JeffH From msk@cloudmark.com Mon Apr 30 19:55: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 5964521E814E for ; Mon, 30 Apr 2012 19:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 jhUSzi9rRSt7 for ; Mon, 30 Apr 2012 19:55:44 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5A21E80BA for ; Mon, 30 Apr 2012 19:55:44 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id 4SvT1j0010as01C01SvTHj; Mon, 30 Apr 2012 19:55:33 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=T7IOvo2Q c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=ldJM1g7oyCcA:10 a=Pip2rxCYUeAA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=gZYdKlMGs4HJI1Aa6poA:9 a=YStEGMaWOOYe8RdfCE0A:7 a=CjuIK1q_8ugA:10 a=_RhRFcbxBZMA:10 a=lZB815dzVvQA: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; Mon, 30 Apr 2012 19:55:27 -0700 From: "Murray S. Kucherawy" To: Julian Reschke Thread-Topic: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec Thread-Index: Ac0l10W9SlaETdSSRZWdVKRKL9SkswBVntWAAAXqgAA= Date: Tue, 1 May 2012 02:55:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039281075DB@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E003928106147@exch-mbx901.corp.cloudmark.com> <4F9EC5BD.7000404@gmx.de> In-Reply-To: <4F9EC5BD.7000404@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=1335840933; bh=S6mz8zB+L5fF8JFr5cKqQHi3fE6efDPpk2WspI3Et7E=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oEU1SIO0XhaUJ+SBofypfUFvFr8d5+tbyO6ZSIbXG1p9ie0zphde5s6yf/In5MTtB CWR+f5G+Es15hPm4j+oh2fhghijiHJTHmG69fzvxDCr/YUsrG9anxumpVUYTJuJOsm 0nLMiMmET9svLAQaXCIPYp1IInv8lNwK3mEDAGdA= 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 02:55:45 -0000 > -----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-tran= sport-sec@tools.ietf.org > Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transpor= t-sec >=20 > On 2012-04-29 09:11, Murray S. Kucherawy wrote: > > ... > > Section 6.1.1: I think the "delta-seconds" should be: > > > > delta-seconds =3D 1*DIGIT > > > > ; defined in Section 3.3.2 of [RFC2616] ... >=20 > 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]" a= nd leave out the restatement of the ABNF? Then it's truly only specified i= n one place. > > The angle-bracket notation you have there doesn't seem to be normal. > > ... >=20 > It's a prose rule; see RFC 5234 prose-val. It's used here to define the > ABNF rule "by reference". RFC5234 also says it should be used as a "last resort". This is such a sim= ple definition that it doesn't seem to qualify. -MSK