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

[Julian Reschke <[e-mail]>]

On 2011-10-29 04:36, =JeffH wrote:
>  >> Strict-Transport-Security = "Strict-Transport-Security" ":"
>  >> directive *( ";" [ directive ] )
>  >>
>  >> STS directives:
>  >>
>  >> directive = max-age | includeSubDomains | STS-d-ext
>  >>
>  >> max-age = "max-age" "=" delta-seconds
>  >
>  > What happens with
>  >
>  > max-age="1"
>  >
>  > ?
>  >
>  > Do you expect all recipients to reject this? Depending on the parsing
>  > API they use they might not even know that the value was quoted on
> the wire.
>
> Offhand, I'm not super sure, but after thinking about it while
> researching/writing the below, I'm thinking "yes", max-age="1" is
> invalid according to the ABNF and we should do whatever we do in error
> cases (which is a separate open question). But implementors' parsing API
> and its problems are out-of-scope for a spec such as this.

They are out-of-scope in that we don't specify them. But we still should 
consider what's likely to be implemented, and the cost of not being able 
to re-use a generic parser.

> This obviously isn't the first HTTP response header field with such a
> syntax and thus these potential issues (this one with a delta-seconds
> value, and the issue you note below wrt "includeSubDomains"), yes?

Indeed. It's just I've been paying more attention to these kinds of 
issues recently :-)

>  > > includeSubDomains = "includeSubDomains"
>  >
>  > There's a tiny risk that some implementations will handle value-less
>  > parameters the same way as parameters with empty values, such as
>  >
>  > includeSubDomains=
>  >
>  > or
>  >
>  > includeSubDomains=""
>  >
>  > but maybe I'm over-engineering here.
>
> Yes, I'm wondering if this might be over-engineering -- I note that in
> RFC 6266 you didn't distinguish/address this sort of case for "inline"
> or "attachment" -- are you feeling now that you should have, and thus we
> ought to do so going forward?
> ...

That case is a bit different as this is a stand-alone token, and there 
do not seem to be any header fields that are similar to C-D but allow a 
quoted-string in the first position.

Also see <http://greenbytes.de/tech/tc2231/#inlonlyquoted> -- some 
recipients reject it, some don't. This is not a big issue per se, unless 
those you reject it are forced to follow suite because senders start to 
rely on it.

> ...

Best regards, Julian