Re: [websec] Strict-Transport-Security syntax redux

[Adam Barth <[e-mail]>]

On Sat, Oct 29, 2011 at 11:50 AM, Adam Barth <[e-mail]> wrote:
> On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke <[e-mail]> wrote:
>> On 2011-10-29 10:21, Adam Barth wrote:
>>> ...
>>>>
>>>> What I was trying to understand whether there's something special with
>>>> respect to quoted-string?
>>>
>>> Quoted string is particularly bad because it's hard to know what to do
>>> with unbalanced quotation marks.
>>> ...
>>
>> So your points were about quoted-string in general, not the question of
>> allowing them for max-age, right?
>>
>> I'm asking because due the possible presence of extension parameters,
>> recipients need to deal with quoted-string anyway, no matter whether they
>> are allowed for max-age.
>
> I'm saying we shouldn't use quoted-string anywhere in the grammar
> because it makes the error-handling ill-defined.
>
> Here's the code I wrote to parse the header:
>
> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state.cc?revision=106333&view=markup
>
> TransportSecurityState::ParseHeader
>
> I'm happy to change that code to allow the parameters to appear in any
> order and to allow other semi-colin separated fields.  Here's the
> parsing algorithm I'm willing to implement:
>
> 1) Split the header field value on ";".
> 2) Process each substring in sequence:
>  a) Remove leading and trailing LWS from the substring.
>  b) If the substring is a case-insensitive match for
> "includeSubDomains", set the include-subdomains flag and continue to
> the next substring.
>  c) If the substring contains at least one "=", let the characters
> before the first "=" be the parameter-name and let the characters
> after the first "=" be the parameter-value:
>    i) Strip leading and trailing LWS from both the parameter-name and
> the parameter-value.
>    ii) If the parameter-name is a case insensitive match for
> "max-age" and the parameter-value is non-empty and consists entirely
> of digits:
>      A) Let the max-age be the number represented by the digits and
> continue to the next substring.
>  d) Continue to the next substring.
>
> Notice that this algorithm defines behavior for all inputs and doesn't
> balance quotation marks in extension parameters.  Here's a
> representation of that algorithm in ABNF:
>
> value = paramater *(";" parameter)
> paramater = "includeSubDomains" / "max-age" "=" 1*DIGIT *LWS / extension
> extension = <any character aside from ";">

Sorry,

extension = *<any character aside from ";">

of course.

> If you want the specification to match the code, you need to take into
> account the desires of implementors.  In particular, you need to take
> into account the fact that implementations need to do something for
> every possible input and that browser implementors wish to be
> instructed how to handle every possible input.
>
> The net-net of this discussion is that's what the code is going to do.
>  If you'd like the specification to match the code, I'd recommend
> against adding aspirational quoted-strings to the grammar.
>
> Adam
>