Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04

Julian Reschke <> Mon, 26 March 2012 07:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CCB521F84F7 for <>; Mon, 26 Mar 2012 00:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.219
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4qA5v-3lodSf for <>; Mon, 26 Mar 2012 00:38:57 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 3015421F84FF for <>; Mon, 26 Mar 2012 00:38:56 -0700 (PDT)
Received: (qmail invoked by alias); 26 Mar 2012 07:38:54 -0000
Received: from (EHLO [IPv6:::1]) [] by (mp012) with SMTP; 26 Mar 2012 09:38:54 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX190uqQmxfp0VnnpGghCG8cgvvyD+dAb+lzgCm4S7S zenq2GsmAVcspA
Message-ID: <>
Date: Mon, 26 Mar 2012 09:38:42 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: =JeffH <>
References: <>
In-Reply-To: <>
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-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, 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:

or the "Prefer" I-D:

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 

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 

> And so you're hoping both that existing parsers get updated to follow
> the general guidelines in "3.1 Considerations for Creating Header
> Fields"
> <>,
> 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