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

[Julian Reschke <[e-mail]>]

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