Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04
Julian Reschke <julian.reschke@gmx.de> Mon, 26 March 2012 07:38 UTC
Return-Path: <julian.reschke@gmx.de>
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 9CCB521F84F7 for <websec@ietfa.amsl.com>; Mon, 26 Mar 2012 00:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.219
X-Spam-Level:
X-Spam-Status: No, score=-104.219 tagged_above=-999 required=5 tests=[AWL=-1.620, 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 4qA5v-3lodSf for <websec@ietfa.amsl.com>; Mon, 26 Mar 2012 00:38:57 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3015421F84FF for <websec@ietf.org>; Mon, 26 Mar 2012 00:38:56 -0700 (PDT)
Received: (qmail invoked by alias); 26 Mar 2012 07:38:54 -0000
Received: from mail.greenbytes.de (EHLO [IPv6:::1]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 26 Mar 2012 09:38:54 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX190uqQmxfp0VnnpGghCG8cgvvyD+dAb+lzgCm4S7S zenq2GsmAVcspA
Message-ID: <4F701D02.1000104@gmx.de>
Date: Mon, 26 Mar 2012 09:38:42 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4F700EF9.5010703@KingsMountain.com>
In-Reply-To: <4F700EF9.5010703@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 <websec@ietf.org>
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 <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2012 07:38:58 -0000
On 2012-03-26 08:38, =JeffH wrote: > >> >> sections 6.1.1 and 6.1.2 describe the syntax particular to > max-age and > >> >> includeSubDomains directives, and neither of those directives employ > >> >> quoted-string, and I don't think they need to or should. > >> > > >> > I think they should, because it's likely that people will write > parses > >> > that allow both, thus you'll have an automated (and totally unneeded) > >> > interoperatility problem. > >> > >> Well, i'm not terribly convinced about this, especially given my code > >> reconnaissance in Firefox and Chrome. > > > > When you checked Firefox, did it support quoted-string for extension > > directives? See? > > I am not sure what you mean by "See?" -- the parsers for STS header in > both firefox and chrome are one-off hand-coded specific parsers, for > better or worse (I'm not sure why they were done that way), and neither > one supports quoted-string for anything in the STS header IIRC. Yes (but I have inspected only the FF code). The reason I asked "See?" is that you can't use the fact that FF doesn't support q-s for the builtin parameters as argument against q-s. Right now it's not using q-s at all; thus, it's currently not conforming to the spec as written anyway and will have to be fixed. If it was fixed to be conforming to the current spec, I would suspect there's a good chance it would start q-s everywhere, instead of special-casing based on the parameter name. > That said, given the present definitions of the STS directives... > > max-age = "max-age" "=" delta-seconds > > delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> > > includeSubDomains = "includeSubDomains" > > > I'm not sure how to cleanly and unambiguously define them in terms of > both token and quoted-string (and retain max-age's basis on > delta-seconds). Perhaps you could propose how to do this? Just define the base grammar for the overall parsing; such as "Expect" in httpbis: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.10.3 or the "Prefer" I-D: http://greenbytes.de/tech/webdav/draft-snell-http-prefer-12.html#rfc.section.2 You can still use ABNF to put additional restrictions on the value, but these constraints then should apply to the parameter value after q-s unescaping. Note that I have a TODO to apply this change to Cache-Control in HTTPbis P6 and haven't done that yet. The problem here is that implementations of Cache-Control in browsers are incredibly broken (see?), so it's not clear how much cleanup is possible at this point. Let's not repeat these mistakes with entirely new header fields. > Also, we need to consciously realize that even if we define it in this > fancier way in the spec, the present HSTS implementations won't match > this, and may never do so. i.e. yes, you can submit bugs and wait and > see what happens. > ... Well, these implementations are non-conforming right now. The interesting question is whether it's harder to change them to use q-s in *some* parameters or to do so in *all* parameters. The former requires that parser to special-case certain parameter names. > =JeffH > > ps... > > >> > I think they should, because it's likely that people will write > parses > >> > that allow both, > > I think "likely" should in reality be "may" in the above. There's a ton > of parsers already written (firefox alone has several different ones > apparently from what I can discern) that don't follow the (relatively > recent) "parse parameter values in both token and quoted string forms" > mantra. There are tons of broken parsers, yes. Some of them in the process of being fixed. For instance, FF now processes q-s in Content-Type and Content-Disposition, and Chrome recently started to do q-s in Content-Disposition. > And so you're hoping both that existing parsers get updated to follow > the general guidelines in "3.1 Considerations for Creating Header > Fields" > <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.3.1>, > and that new ones also adhere to said considerations. I hope that new definitions follow the advice, and that implementations of parsers for existing fields actually conform to what the specification says (see examples about Content-Type and Content-Disposition above). Best regards, Julian
- [websec] STS ABNF, was: new rev: draft-ietf-webse… =JeffH
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… Julian Reschke
- [websec] STS ABNF, was: new rev: draft-ietf-webse… =JeffH
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… Julian Reschke
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… =JeffH
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… Julian Reschke
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… =JeffH
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… Julian Reschke
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… Julian Reschke
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… =JeffH
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… =JeffH
- Re: [websec] STS ABNF, was: new rev: draft-ietf-w… Julian Reschke