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

[Julian Reschke]

On 2012-04-06 00:40, =JeffH wrote:

Thanks for the feedback, proposed edits, and hacked xml2rfc source.

 > So this
 >
 > - states that the given ABNF applies to the value after q-s processing
 > (when needed)
 > - changes the ABNF to specify only the *value*

Ok. so you suggested..

6.1.1. The max-age Directive

The REQUIRED max-age directive specifies the number of seconds, after
the reception of the STS header field, during which the UA regards
the host, from whom the message was received, as a Known HSTS Host
(see also Section 8.1.1 "Noting a HSTS Host", below).

The syntax of the max-age directive's value (after potential
applying quoted-string unescaping) is:

max-age-v = delta-seconds
delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

Note: A max-age value of zero signals the UA to cease regarding the
host as a Known HSTS Host.



..and I presently am polishing that to be..


6.1.1. The max-age Directive

The REQUIRED "max-age" directive specifies the number of seconds,
after the reception of the STS header field, during which the UA
regards the host, from whom the message was received, as a Known HSTS
Host (see also Section 8.1.1 "Noting a HSTS Host", below).

The max-age directive value has the following syntax
(after quoted-string unescaping, if necessary):

max-age-value = delta-seconds
delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

Note: A max-age value of zero signals the UA to cease regarding the
host as a Known HSTS Host.


Looks good to me.


I'm a little concerned that without an explicit syntax declaration such
as..

max-age = "max-age" "=" max-age-value

..we'll confuse some readers ("what do i actually put in the STS header
for this directive??"), but hopefully the examples in section 6.2, as
well as putting the directive name in quotes in the first paragraph,
will address this.


Noted. And yes, if we optimize for people not reading the spec 
"properly", the best way to address this is to add examples.


Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[=JeffH]

Julian had sent to me..
>
>   6.2.  Examples
>
>
> Section 6.2., paragraph 2:
> OLD:
>
>Strict-Transport-Security: max-age=31536000
>
> NEW:
>
>Strict-Transport-Security: max-age="31536000"
>
> (changed one example to use q-s)


I'll actually add a separate example for illustrating use of quoted-string, 
because I don't think we want to necessarily encourage it's use.


thx,

=JeffH





___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[=JeffH]

Thanks for the feedback, proposed edits, and hacked xml2rfc source.

> So this
>
> - states that the given ABNF applies to the value after q-s processing
> (when needed)
> - changes the ABNF to specify only the *value*

Ok.  so you suggested..

6.1.1. The max-age Directive

The REQUIRED max-age directive specifies the number of seconds, after
the reception of the STS header field, during which the UA regards
the host, from whom the message was received, as a Known HSTS Host
(see also Section 8.1.1 "Noting a HSTS Host", below).

The syntax of the max-age directive's value (after potential
applying quoted-string unescaping) is:

 max-age-v = delta-seconds
 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

Note:  A max-age value of zero signals the UA to cease regarding the
   host as a Known HSTS Host.



..and I presently am polishing that to be..


6.1.1. The max-age Directive

The REQUIRED "max-age" directive specifies the number of seconds,
after the reception of the STS header field, during which the UA
regards the host, from whom the message was received, as a Known HSTS
Host (see also Section 8.1.1 "Noting a HSTS Host", below).

The max-age directive value has the following syntax
(after quoted-string unescaping, if necessary):

 max-age-value = delta-seconds
 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

Note:  A max-age value of zero signals the UA to cease regarding the
   host as a Known HSTS Host.



I'm a little concerned that without an explicit syntax declaration such as..

 max-age   = "max-age" "=" max-age-value

..we'll confuse some readers ("what do i actually put in the STS header for 
this directive??"), but hopefully the examples in section 6.2, as well as 
putting the directive name in quotes in the first paragraph, will address this.


thx,

=JeffH




___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

Here's the promised concrete change proposal:

Section 6.1., paragraph 3:
OLD:

 Strict-Transport-Security = "Strict-Transport-Security" ":"
 *( ";" [ directive ] )

NEW:

 Strict-Transport-Security = "Strict-Transport-Security" ":"
 [ directive ] *( ";" [ directive ] )


(fixes the leading ";" problem)

Section 6.1., paragraph 12:
OLD:

   Additional directives extending the semantic functionality of the STS
   header field may be defined in other specifications (which "update"
   this specification), using the STS directive extension point.

NEW:

   Additional directives extending the semantic functionality of the STS
   header field can be defined in other specifications (which "update"
   this specification).

(the extension directive extension point was removed earlier on when the 
ABNF was simplified)


Section 6.1.1., paragraph 2:
OLD:

   The syntax of the max-age directive is defined as:

NEW:

   The syntax of the max-age directive's value (after potential quoted-
   string when applicable) is defined as:


Section 6.1.1., paragraph 3:
OLD:

max-age   = "max-age" "=" delta-seconds

NEW:

max-age-value = delta-seconds

(We just define the parameter value ABNF)

Section 6.2., paragraph 0:
OLD:

   The syntax of the includeSubDomains directive is defined as:

 includeSubDomains = "includeSubDomains"

 6.2.  Examples

NEW:

(text removed, as the directive is value-less)


 6.2.  Examples


Section 6.2., paragraph 2:
OLD:

  Strict-Transport-Security: max-age=31536000

NEW:

  Strict-Transport-Security: max-age="31536000"

(changed one example to use q-s)

Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2012-03-26 10:29, =JeffH wrote:

 >> 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

I would appreciate it if you would just plain propose the grammar you
believe we should have.


The base grammar in Section 6 is fine (except for the nit about the 
leading ";" we were already discussing).


For the predefined directives, for example, change:

6.1.1. The max-age Directive


   The REQUIRED max-age directive specifies the number of seconds, after
   the reception of the STS header field, during which the UA regards
   the host, from whom the message was received, as a Known HSTS Host
   (see also Section 8.1.1 "Noting a HSTS Host", below).  The delta-
   seconds production is specified in [RFC2616].

   The syntax of the max-age directive is defined as:

max-age   = "max-age" "=" delta-seconds

delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

   Note:  A max-age value of zero signals the UA to cease regarding the
  host as a Known HSTS Host.

to

6.1.1. The max-age Directive

   The REQUIRED max-age directive specifies the number of seconds, after
   the reception of the STS header field, during which the UA regards
   the host, from whom the message was received, as a Known HSTS Host
   (see also Section 8.1.1 "Noting a HSTS Host", below).

   The syntax of the max-age directive's value (after potential
   applying quoted-string unescaping) is:

max-age-v = delta-seconds
delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

   Note:  A max-age value of zero signals the UA to cease regarding the
  host as a Known HSTS Host.

So this

- states that the given ABNF applies to the value after q-s processing 
(when needed)

- changes the ABNF to specify only the *value*
- also we can remove the prose statement about delta-seconds; having it 
in the ABNF is sufficient


Finally, examples should show both variants of the syntax.

Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[=JeffH]

>> 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

I would appreciate it if you would just plain propose the grammar you believe 
we should have.


thanks,

=JeffH


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

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"
,
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 mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[=JeffH]

>>  >> 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.


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?


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.


=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.


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.





___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2012-03-09 17:02, =JeffH wrote:

...
Well, i'm not terribly convinced about this, especially given my code
reconnaissance in Firefox and Chrome. The spec clearly states what the


When you checked Firefox, did it support quoted-string for extension 
directives? See?


Speaking of which: do you have a test suite, or at least a big 
repertoire of examples?



syntax is for those directives and it doesn't encompass quoted-string
variants of the values for max-age and delta-seconds. I think adding
something like that will needlessly complicate the spec, so I
respectfully decline to make such a change.
...


I believe both the spec and implementations will be simpler if the 
syntax of a parameter does not depend on the parameter name.


Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[=JeffH]

> On 2012-03-09 00:41, =JeffH wrote:
>> Thanks for the review Julian,
>>
>>  > The ABNF now is:
>>  >
>>  > Strict-Transport-Security = "Strict-Transport-Security" ":"
>>  > directive *( ";" [ directive ] )
>>  >
>>  >
>>  > directive = token [ "=" ( token | quoted-string ) ]
>>  >
>>  > ...and I think this is almost right.
>>  >
>>  > It does allow empty directives (thus repeated or trailing semicolons),
>>  > but not leading semicolons.
>>  >
>>  > So
>>  >
>>  > STS: foo ;
>>  >
>>  > parses, but
>>  >
>>  > STS: ; foo
>>  >
>>  > does not.
>>
>> well, I guess a question is whether we want "STS: ; foo " to "parse" ?
>>
>> I'm not sure we do, but can be convinced otherwise.
>
> Well, either be permissive with respect to superfluous delimiters or
> don't; but allowing them in once place but not the other?

yeah, seems fine, I'll make that change. the language describing the specifics 
of the presently defined directives addresses their cardinality and 
required/optional presence.


>>  > For 6.1.1 and 6.1.2, we still need to decide whether a) quoted-string
>>  > should be legal here (I understand that's
>>  > )
>>
>> 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. The spec clearly states what the syntax 
is for those directives and it doesn't encompass quoted-string variants of the 
values for max-age and delta-seconds. I think adding something like that will 
needlessly complicate the spec, so I respectfully decline to make such a change.


best regards,

=JeffH




___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2012-03-09 00:41, =JeffH wrote:

Thanks for the review Julian,

 > The ABNF now is:
 >
 > Strict-Transport-Security = "Strict-Transport-Security" ":"
 > directive *( ";" [ directive ] )
 >
 >
 > directive = token [ "=" ( token | quoted-string ) ]
 >
 > ...and I think this is almost right.
 >
 > It does allow empty directives (thus repeated or trailing semicolons),
 > but not leading semicolons.
 >
 > So
 >
 > STS: foo ;
 >
 > parses, but
 >
 > STS: ; foo
 >
 > does not.

well, I guess a question is whether we want "STS: ; foo " to "parse" ?

I'm not sure we do, but can be convinced otherwise.

Part of the intention of the above ABNF is that the STS header must have
at least one directive (i.e. max-age - given the constraints in the
prose following the ABNF)

I suppose what you're trying to say is that all of the below ought to
"parse" successfully...

STS: max-age=nn

STS: max-age=nn

STS: max-age=nn ;

STS: max-age=nn ; ; ;

STS: ; max-age=nn

STS: ; ; ; max-age=nn

STS: ; ; ; max-age=nn ; ; ;

?


Well, either be permissive with respect to superfluous delimiters or 
don't; but allowing them in once place but not the other?



 > This could be fixed by saying:
 >
 > Strict-Transport-Security = "Strict-Transport-Security" ":"
 > *( ";" [ directive ] )
 >

Yes, that's allow for the constructions above, along with (at most one
instance of) includeSubDomains being interspersed between any of the
semicolons.



 > I like the subsequent prose about the additional constraints.

good :)



 > For 6.1.1 and 6.1.2, we still need to decide whether a) quoted-string
 > should be legal here (I understand that's
 > )

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.



I conceded to add quoted-string syntax to the generic directive syntax of..

directive = token [ "=" ( token | quoted-string ) ]

..in case someone at some time wishes to add an extension directive
employing quoted-string syntax.

Are you saying that sections 6.1.1 and 6.1.2 need to explicitly declare
non-use of quoted-string ? Presently it's implied by the declared ABNF


The opposite.


...


Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[=JeffH]

Thanks for the review Julian,

> The ABNF now is:
>
>   Strict-Transport-Security = "Strict-Transport-Security" ":"
>  directive *( ";" [ directive ] )
>
>
>   directive = token [ "=" ( token | quoted-string ) ]
>
> ...and I think this is almost right.
>
> It does allow empty directives (thus repeated or trailing semicolons),
> but not leading semicolons.
>
> So
>
>STS: foo ;
>
> parses, but
>
>STS: ; foo
>
> does not.

well, I guess a question is whether we want "STS: ; foo "  to  "parse" ?

I'm not sure we do, but can be convinced otherwise.

Part of the intention of the above ABNF is that the STS header must have at 
least one directive (i.e. max-age - given the constraints in the prose 
following the ABNF)


I suppose what you're trying to say is that all of the below ought to "parse" 
successfully...


   STS: max-age=nn

   STS: max-age=nn

   STS: max-age=nn ;

   STS: max-age=nn ; ; ;

   STS: ; max-age=nn

   STS: ; ; ; max-age=nn

   STS: ; ; ; max-age=nn  ; ; ;

?


> This could be fixed by saying:
>
>   Strict-Transport-Security = "Strict-Transport-Security" ":"
>   *( ";" [ directive ] )
>

Yes, that's allow for the constructions above, along with (at most one instance 
of) includeSubDomains being interspersed between any of the semicolons.




> I like the subsequent prose about the additional constraints.

good :)



> For 6.1.1 and 6.1.2, we still need to decide whether a) quoted-string
> should be legal here (I understand that's
> )

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 conceded to add quoted-string syntax to the generic directive syntax of..

 directive = token [ "=" ( token | quoted-string ) ]

..in case someone at some time wishes to add an extension directive employing 
quoted-string syntax.


Are you saying that sections 6.1.1 and 6.1.2 need to explicitly declare non-use 
of quoted-string ?  Presently it's implied by the declared ABNF syntax for 
those two defined directives..


max-age   = "max-age" "=" delta-seconds

delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

..and..

   includeSubDomains = "includeSubDomains"


thanks again,

=JeffH



___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2012-01-28 01:56, =JeffH wrote:

...


Hi Jeff,

thanks for the update.

The ABNF now is:

 Strict-Transport-Security = "Strict-Transport-Security" ":"
directive *( ";" [ directive ] )


 directive = token [ "=" ( token | quoted-string ) ]

...and I think this is almost right.

It does allow empty directives (thus repeated or trailing semicolons), 
but not leading semicolons.


So

  STS: foo ;

parses, but

  STS: ; foo

does not. This could be fixed by saying:

 Strict-Transport-Security = "Strict-Transport-Security" ":"
 *( ";" [ directive ] )

I like the subsequent prose about the additional constraints.

For 6.1.1 and 6.1.2, we still need to decide whether a) quoted-string 
should be legal here (I understand that's 
), and if it was, 
b) how the syntax should be described.


Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec