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

[Bjoern Hoehrmann]

* Julian Reschke wrote:
>On 2012-01-09 01:25, Adam Barth wrote:
>> On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann  wrote:
>>> It seems to me that all headers defined in RFC 2616 that allow para-
>>> meteter lists of the `;name=value` form allow the value to be a quoted
>>> string.
>>
>> This header isn't defined in RFC 2616 and many headers defined outside
>> of RFC 2616 don't use quoted-string.
>> ...
>
>In name/value pairs? Example?
>
>(As a matter of fact, not all header fields in 2616 are as consistent as 
>they should, but that's not an excuse for not trying to do better with 
>new header fields)

(FWIW, when I wrote my comment, I picked the RFCs that match /rfc2616/
and then filtered the remaining ones for /";"/ and then quickly scanned
through the remaining ones, and only the `Cookie` RFCs stood out as ex-
amples where this is not the case; not all headers are defined in RFCs,
and my ad-hoc method would not necessarily find all instances in RFCS,
but there were a number that matched RFC2616 in this, so I found it
reasonable to make the argument. And no counter-examples have been pro-
vided since, so it is probably fair to assume that this is the dominant
pattern.)
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2012-01-16 06:38, Marsh Ray wrote:

On 01/05/2012 11:50 AM, Anne van Kesteren wrote:

On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman 
wrote:


"We invented a header that your message-producing software must
special-case" is not a good way to get security.


If the header-consuming software works that way, it might be the only
way. What the right way to go here is kind of depends on how header
field values are typically implemented in practice. I suspect it to be
rather messy.


How about: servers generating the header MUST use quoted-string whenever
quoted-string is necessary, otherwise they SHOULD use the token
production on Mondays, Wednesdays, and Fridays and they SHOULD use
quoted-string on Tuesday, Thursday, Saturday, and Sunday.

Yes, I'm joking. But only half-way. I have a deep suspicion that
something like that might actually yield the best interoperability
overall. One thing worse than having arbitrarily-chosen redundant code
paths is having protocol grammar that's never ever used - until it's
needed.
...


Indeed.

Test cases!

Examples! (Section 5.2 really needs an example of a header field where 
an extension parameter using q-s is used)


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

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

[Marsh Ray]

On 01/05/2012 11:50 AM, Anne van Kesteren wrote:

On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman 
wrote:


"We invented a header that your message-producing software must
special-case" is not a good way to get security.


If the header-consuming software works that way, it might be the only
way. What the right way to go here is kind of depends on how header
field values are typically implemented in practice. I suspect it to be
rather messy.


How about: servers generating the header MUST use quoted-string whenever 
quoted-string is necessary, otherwise they SHOULD use the token 
production on Mondays, Wednesdays, and Fridays and they SHOULD use 
quoted-string on Tuesday, Thursday, Saturday, and Sunday.


Yes, I'm joking. But only half-way. I have a deep suspicion that 
something like that might actually yield the best interoperability 
overall. One thing worse than having arbitrarily-chosen redundant code 
paths is having protocol grammar that's never ever used - until it's needed.


Meredith Patterson, Sergey Bratus, et al. have been talking about the 
deep logical connections between lanugage expressive power, 
generator/parser differences, and ... working exploits.

http://www.cs.dartmouth.edu/~sergey/langsec/

28c3: The Science of Insecurity
http://www.youtube.com/watch?v=3kEfedtQVOY
Worth watching.

And of course: Occupy Babel!
http://www.cs.dartmouth.edu/~sergey/langsec/occupy/

:-)

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

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

[Julian Reschke]

On 2012-01-09 01:39, Julian Reschke wrote:

On 2012-01-09 01:25, Adam Barth wrote:

On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann
wrote:

* Tobias Gondrom wrote:


as it seems there is disagreement on how to resolve this, with only
very
few people having spoken out so far, I would like to invite comments

>from other working group members on this topic to see whether we might

have missed something.


It seems to me that all headers defined in RFC 2616 that allow para-
meteter lists of the `;name=value` form allow the value to be a quoted
string.


This header isn't defined in RFC 2616 and many headers defined outside
of RFC 2616 don't use quoted-string.
...


In name/value pairs? Example?

(As a matter of fact, not all header fields in 2616 are as consistent as
they should, but that's not an excuse for not trying to do better with
new header fields)
...


I note you didn't supply examples.

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

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

[Paul Hoffman]

On Jan 8, 2012, at 4:25 PM, Adam Barth wrote:

> This header isn't defined in RFC 2616 and many headers defined outside
> of RFC 2616 don't use quoted-string.


I haven't completely kept up on new headers, but I think "many" may be an 
overstatement (but am happy to be proven wrong). The fact that one or two got 
it wrong shouldn't guide us: security robustness should.

--Paul Hoffman

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

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

[Julian Reschke]

On 2012-01-09 01:25, Adam Barth wrote:

On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann  wrote:

* Tobias Gondrom wrote:


as it seems there is disagreement on how to resolve this, with only very
few people having spoken out so far, I would like to invite comments

>from other working group members on this topic to see whether we might

have missed something.


It seems to me that all headers defined in RFC 2616 that allow para-
meteter lists of the `;name=value` form allow the value to be a quoted
string.


This header isn't defined in RFC 2616 and many headers defined outside
of RFC 2616 don't use quoted-string.
...


In name/value pairs? Example?

(As a matter of fact, not all header fields in 2616 are as consistent as 
they should, but that's not an excuse for not trying to do better with 
new header fields)


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

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

[Adam Barth]

On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann  wrote:
> * Tobias Gondrom wrote:
>>
>>as it seems there is disagreement on how to resolve this, with only very
>>few people having spoken out so far, I would like to invite comments
>>from other working group members on this topic to see whether we might
>>have missed something.
>
> It seems to me that all headers defined in RFC 2616 that allow para-
> meteter lists of the `;name=value` form allow the value to be a quoted
> string.

This header isn't defined in RFC 2616 and many headers defined outside
of RFC 2616 don't use quoted-string.

Adam


> If the Working Group wishes to disallow quoted strings, then
> it should use a format that's very different from the existing syntax,
> like `name=value&name=other%20value` or JSON or whatever. "Similar but
> slightly different" always translate into bugs.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Bjoern Hoehrmann]

* Tobias Gondrom wrote:
>
>as it seems there is disagreement on how to resolve this, with only very 
>few people having spoken out so far, I would like to invite comments 
>from other working group members on this topic to see whether we might 
>have missed something.

It seems to me that all headers defined in RFC 2616 that allow para-
meteter lists of the `;name=value` form allow the value to be a quoted
string. If the Working Group wishes to disallow quoted strings, then
it should use a format that's very different from the existing syntax,
like `name=value&name=other%20value` or JSON or whatever. "Similar but
slightly different" always translate into bugs.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2012-01-05 21:22, Anne van Kesteren wrote:

On Thu, 05 Jan 2012 19:06:42 +0100, Julian Reschke
 wrote:

It is indeed messy. And I think one of the reasons it is that there
are too many different formats, and too many special cases within a
single format; thus my proposal to allow token/quoted-string for all
parameters, and not only some.


Is there some kind of overview of the formats in use and indication of
convergence? It seems you have a particular vision and it may be the
right one, but without some kind of data it's hard to see where we are.


Work-in-progress:





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

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

[Anne van Kesteren]

On Thu, 05 Jan 2012 19:06:42 +0100, Julian Reschke   
wrote:
It is indeed messy. And I think one of the reasons it is that there are  
too many different formats, and too many special cases within a single  
format; thus my proposal to allow token/quoted-string for all  
parameters, and not only some.


Is there some kind of overview of the formats in use and indication of  
convergence? It seems you have a particular vision and it may be the right  
one, but without some kind of data it's hard to see where we are.



--
Anne van Kesteren
http://annevankesteren.nl/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2012-01-05 18:50, Anne van Kesteren wrote:

On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman 
wrote:

FWIW, I'm with Julian on this, particularly:


- principle of least surprise and consistency - if quoted-string
works in other header fields with param syntax, why not here?


"We invented a header that your message-producing software must
special-case" is not a good way to get security.


If the header-consuming software works that way, it might be the only
way. What the right way to go here is kind of depends on how header
field values are typically implemented in practice. I suspect it to be
rather messy.


It is indeed messy. And I think one of the reasons it is that there are 
too many different formats, and too many special cases within a single 
format; thus my proposal to allow token/quoted-string for all 
parameters, and not only some.


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

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

[Anne van Kesteren]

On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman   
wrote:

FWIW, I'm with Julian on this, particularly:

- principle of least surprise and consistency - if quoted-string works  
in other header fields with param syntax, why not here?


"We invented a header that your message-producing software must  
special-case" is not a good way to get security.


If the header-consuming software works that way, it might be the only way.  
What the right way to go here is kind of depends on how header field  
values are typically implemented in practice. I suspect it to be rather  
messy.



--
Anne van Kesteren
http://annevankesteren.nl/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Paul Hoffman]

FWIW, I'm with Julian on this, particularly:

> - principle of least surprise and consistency - if quoted-string works in 
> other header fields with param syntax, why not here?


"We invented a header that your message-producing software must special-case" 
is not a good way to get security.

--Paul Hoffman

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

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

[Julian Reschke]

On 2012-01-05 09:20, Anne van Kesteren wrote:

On Thu, 05 Jan 2012 05:55:10 +0100, Tobias Gondrom
 wrote:

as it seems there is disagreement on how to resolve this, with only
very few people having spoken out so far, I would like to invite
comments from other working group members on this topic to see whether
we might have missed something.


I don't really get what the advantage of allowing quoted string here is.
If we can use a simpler production, what is wrong with using that?


The advantages are:

- you can express values that you can't express with token syntax; if 
future extensions need non-token characters they will need invent yet 
another escaping syntax


- principle of least surprise and consistency - if quoted-string works 
in other header fields with param syntax, why not here?


etc.

On the other hand, I haven't seen convincing arguments for not allowing 
q-s. Yes, it adds to the complexity of the parser, but this has been 
implemented many times before already.



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

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

[Anne van Kesteren]

On Thu, 05 Jan 2012 05:55:10 +0100, Tobias Gondrom  
 wrote:
as it seems there is disagreement on how to resolve this, with only very  
few people having spoken out so far, I would like to invite comments  
from other working group members on this topic to see whether we might  
have missed something.


I don't really get what the advantage of allowing quoted string here is.  
If we can use a simpler production, what is wrong with using that?



--
Anne van Kesteren
http://annevankesteren.nl/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Tobias Gondrom]

Hello websec fellows,


as it seems there is disagreement on how to resolve this, with only very 
few people having spoken out so far, I would like to invite comments 
from other working group members on this topic to see whether we might 
have missed something.


Best regards, Tobias


On 30/12/11 18:37, Adam Barth wrote:

It seems we're not in agreement.  We can repeat the same arguments
over and over again, but it's not clear that would be productive.

Adam


On Fri, Dec 30, 2011 at 2:00 AM, Julian Reschke  wrote:

On 2011-12-30 10:13, Adam Barth wrote:

Using quoted-string in the extension directive is the wrong thing to
do.  Because none of the actual directives use quoted-string, folks
are likely to write parsers that don't handle all the complexities of
quoted-string (which are legion).  That means when we go to actually
use quoted-string in a future directive, it won't actually work in
many user agents.


Unless we clarify the syntax, allow q-s everywhere, and have test cases.



On the other hand, if we spec the extension directives without
quoted-string, future extensions will work even if folks mistakenly
implement quote-string (because DQUOTE is forbidden in the extension
syntax I suggested above, so we'll never trigger the mistaken
quoted-string parsing code).  Everyone lives a happy life.


Absolutely not.

First of all, some implementations will parse q-s, because that's consistent
with other header fields. Also, not having q-s makes certain values
impossible to send, in which case you'll need to invent yet another escaping
syntax.



Anyway, it's all somewhat of a moot point because the above will
happen regardless of what we write in the spec.  Even if we write
quoted-string, when folks attempt to use these extension directives in
the future, they'll find that they don't work and they'll update the
syntax not to use quoted-string.


Why would they find that? Implementations can be fixed.

Or is this argument based on the fact that you *currently* "own" one
implementation and claim it can't be fixed? That would be a very strange
thing to do in the context of an IETF WG trying to reach consensus.

Best regards, Julian

PS: I note that we are in violent agreement that the syntax should be the
same for all directives, predefined or extension. We just come to different
conclusions about what that syntax should be.

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


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

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

[Adam Barth]

It seems we're not in agreement.  We can repeat the same arguments
over and over again, but it's not clear that would be productive.

Adam


On Fri, Dec 30, 2011 at 2:00 AM, Julian Reschke  wrote:
> On 2011-12-30 10:13, Adam Barth wrote:
>>
>> Using quoted-string in the extension directive is the wrong thing to
>> do.  Because none of the actual directives use quoted-string, folks
>> are likely to write parsers that don't handle all the complexities of
>> quoted-string (which are legion).  That means when we go to actually
>> use quoted-string in a future directive, it won't actually work in
>> many user agents.
>
>
> Unless we clarify the syntax, allow q-s everywhere, and have test cases.
>
>
>> On the other hand, if we spec the extension directives without
>> quoted-string, future extensions will work even if folks mistakenly
>> implement quote-string (because DQUOTE is forbidden in the extension
>> syntax I suggested above, so we'll never trigger the mistaken
>> quoted-string parsing code).  Everyone lives a happy life.
>
>
> Absolutely not.
>
> First of all, some implementations will parse q-s, because that's consistent
> with other header fields. Also, not having q-s makes certain values
> impossible to send, in which case you'll need to invent yet another escaping
> syntax.
>
>
>> Anyway, it's all somewhat of a moot point because the above will
>> happen regardless of what we write in the spec.  Even if we write
>> quoted-string, when folks attempt to use these extension directives in
>> the future, they'll find that they don't work and they'll update the
>> syntax not to use quoted-string.
>
>
> Why would they find that? Implementations can be fixed.
>
> Or is this argument based on the fact that you *currently* "own" one
> implementation and claim it can't be fixed? That would be a very strange
> thing to do in the context of an IETF WG trying to reach consensus.
>
> Best regards, Julian
>
> PS: I note that we are in violent agreement that the syntax should be the
> same for all directives, predefined or extension. We just come to different
> conclusions about what that syntax should be.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2011-12-30 10:13, Adam Barth wrote:

Using quoted-string in the extension directive is the wrong thing to
do.  Because none of the actual directives use quoted-string, folks
are likely to write parsers that don't handle all the complexities of
quoted-string (which are legion).  That means when we go to actually
use quoted-string in a future directive, it won't actually work in
many user agents.


Unless we clarify the syntax, allow q-s everywhere, and have test cases.


On the other hand, if we spec the extension directives without
quoted-string, future extensions will work even if folks mistakenly
implement quote-string (because DQUOTE is forbidden in the extension
syntax I suggested above, so we'll never trigger the mistaken
quoted-string parsing code).  Everyone lives a happy life.


Absolutely not.

First of all, some implementations will parse q-s, because that's 
consistent with other header fields. Also, not having q-s makes certain 
values impossible to send, in which case you'll need to invent yet 
another escaping syntax.



Anyway, it's all somewhat of a moot point because the above will
happen regardless of what we write in the spec.  Even if we write
quoted-string, when folks attempt to use these extension directives in
the future, they'll find that they don't work and they'll update the
syntax not to use quoted-string.


Why would they find that? Implementations can be fixed.

Or is this argument based on the fact that you *currently* "own" one 
implementation and claim it can't be fixed? That would be a very strange 
thing to do in the context of an IETF WG trying to reach consensus.


Best regards, Julian

PS: I note that we are in violent agreement that the syntax should be 
the same for all directives, predefined or extension. We just come to 
different conclusions about what that syntax should be.

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

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

[Adam Barth]

On Fri, Dec 30, 2011 at 12:53 AM, Julian Reschke  wrote:
> On 2011-12-30 09:46, Adam Barth wrote:
>>
>> On Fri, Dec 30, 2011 at 12:18 AM, Julian Reschke
>>  wrote:
>>>
>>> On 2011-12-29 22:45, Adam Barth wrote:

 Chrome does not (and will not) implement quoted-string for the STS
 header for the reasons I've explained previously.  You're welcome to
 file bugs, but I'm just going to close them WONTFIX.
>>>
>>> So your code intentionally is non-compliant with STS.
>>>
>>> I note that you are both a WG member and also listed as one of the
>>> authors
>>> of the spec. Don't you think that this puts you into a strange position?
>>
>> Not really.  IMHO, we should just change the spec.
>
> If you believe that support for quoted-string in extension directives is the
> wrong thing to do, please go ahead and lobby for a change.

Using quoted-string in the extension directive is the wrong thing to
do.  Because none of the actual directives use quoted-string, folks
are likely to write parsers that don't handle all the complexities of
quoted-string (which are legion).  That means when we go to actually
use quoted-string in a future directive, it won't actually work in
many user agents.

On the other hand, if we spec the extension directives without
quoted-string, future extensions will work even if folks mistakenly
implement quote-string (because DQUOTE is forbidden in the extension
syntax I suggested above, so we'll never trigger the mistaken
quoted-string parsing code).  Everyone lives a happy life.

Anyway, it's all somewhat of a moot point because the above will
happen regardless of what we write in the spec.  Even if we write
quoted-string, when folks attempt to use these extension directives in
the future, they'll find that they don't work and they'll update the
syntax not to use quoted-string.

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

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

[Julian Reschke]

On 2011-12-30 09:46, Adam Barth wrote:

On Fri, Dec 30, 2011 at 12:18 AM, Julian Reschke  wrote:

On 2011-12-29 22:45, Adam Barth wrote:

Chrome does not (and will not) implement quoted-string for the STS
header for the reasons I've explained previously.  You're welcome to
file bugs, but I'm just going to close them WONTFIX.


So your code intentionally is non-compliant with STS.

I note that you are both a WG member and also listed as one of the authors
of the spec. Don't you think that this puts you into a strange position?


Not really.  IMHO, we should just change the spec.


If you believe that support for quoted-string in extension directives is 
the wrong thing to do, please go ahead and lobby for a change.


I happen to agree that parsing should be consistent for all directives, 
but my preference is to keep quoted-string, both for what you gain (the 
ability to express certain values that otherwise you can't without 
introducing yet another new way to encode them), and consistency with 
other header fields.


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

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

[Adam Barth]

On Fri, Dec 30, 2011 at 12:18 AM, Julian Reschke  wrote:
> On 2011-12-29 22:45, Adam Barth wrote:
>> Chrome does not (and will not) implement quoted-string for the STS
>> header for the reasons I've explained previously.  You're welcome to
>> file bugs, but I'm just going to close them WONTFIX.
>
> So your code intentionally is non-compliant with STS.
>
> I note that you are both a WG member and also listed as one of the authors
> of the spec. Don't you think that this puts you into a strange position?

Not really.  IMHO, we should just change the spec.

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

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

[Julian Reschke]

On 2011-12-29 22:45, Adam Barth wrote:

...
Chrome does not (and will not) implement quoted-string for the STS
header for the reasons I've explained previously.  You're welcome to
file bugs, but I'm just going to close them WONTFIX.
...


So your code intentionally is non-compliant with STS.

I note that you are both a WG member and also listed as one of the 
authors of the spec. Don't you think that this puts you into a strange 
position?


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

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

[Adam Barth]

On Thu, Dec 29, 2011 at 8:11 PM, Roy T. Fielding  wrote:
> On Dec 29, 2011, at 5:22 PM, Adam Barth wrote:
>> On Thu, Dec 29, 2011 at 5:01 PM, =JeffH  
>> wrote:
>>> Adam Barth noted:
 I would also define the precise requirements for parsing all possible
 input sequences, but I understand that's not fashionable.
>>>
>>> By that, you are suggesting specification of parsing algorithms as done in
>>> RFC6265 "HTTP State Management Mechanism", yes?
>>
>> I actually think what we're doing for CSP is slightly better:
>>
>> http://www.w3.org/TR/CSP/#policies
>
> Hmm, that algorithm breaks on
>
>   foo;;bob
>
> which is allowed by the associated ABNF.  *shrug*

I'm not sure I understand what you think breaks about the algorithm.
I've restricted the loop to non-empty tokens, which hopefully
addresses your concern.

> I don't think I'll ever understand why you keep promoting Ian's
> mantra on specs being written as algorithms.  The algorithms that
> you end up placing in the specs have more bugs than the code
> found in the actual implementations, and they aren't any more
> formal than the ABNF.

The problem is that the ABNF simply doesn't define how to handle error
conditions.  At least with algorithms they define the behavior.  If
the definition is wrong or has bugs, we can fix those bugs.
Eventually the process converges to a correct definition of the
behavior.

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

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

[Roy T. Fielding]

On Dec 29, 2011, at 5:22 PM, Adam Barth wrote:

> On Thu, Dec 29, 2011 at 5:01 PM, =JeffH  wrote:
>> Adam Barth noted:
>>> I would also define the precise requirements for parsing all possible
>>> input sequences, but I understand that's not fashionable.
>> 
>> By that, you are suggesting specification of parsing algorithms as done in
>> RFC6265 "HTTP State Management Mechanism", yes?
> 
> I actually think what we're doing for CSP is slightly better:
> 
> http://www.w3.org/TR/CSP/#policies

Hmm, that algorithm breaks on 

   foo;;bob

which is allowed by the associated ABNF.  *shrug*

I don't think I'll ever understand why you keep promoting Ian's
mantra on specs being written as algorithms.  The algorithms that
you end up placing in the specs have more bugs than the code
found in the actual implementations, and they aren't any more
formal than the ABNF.

Roy

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

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

[Adam Barth]

On Thu, Dec 29, 2011 at 5:01 PM, =JeffH  wrote:
> Adam Barth noted:
>> I would also define the precise requirements for parsing all possible
>> input sequences, but I understand that's not fashionable.
>
> By that, you are suggesting specification of parsing algorithms as done in
> RFC6265 "HTTP State Management Mechanism", yes?

I actually think what we're doing for CSP is slightly better:

http://www.w3.org/TR/CSP/#policies

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

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

[=JeffH]

Adam Barth noted:
>
> I would also define the precise requirements for parsing all possible
> input sequences, but I understand that's not fashionable.

By that, you are suggesting specification of parsing algorithms as done in 
RFC6265 "HTTP State Management Mechanism", yes?


=JeffH

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

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

[Adam Barth]

On Thu, Dec 29, 2011 at 1:38 PM, Julian Reschke  wrote:
> On 2011-12-29 22:32, Adam Barth wrote:
>>
>> On Thu, Dec 29, 2011 at 1:24 PM, Julian Reschke
>>  wrote:
>>>
>>> On 2011-12-29 22:18, Adam Barth wrote:

 On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke
  wrote:
>
> On 2011-12-29 20:50, Adam Barth wrote:
>>
>> As I wrote before, I don't think we should include quoted-string in
>> the grammar.  As far as I know, no one has implemented it and I have
>> no plans to implement quoted-string in Chrome.  Having quoted-string
>> in the grammar only leads to pain.,
>
>
> It would be helpful if you were more precise on the pain it causes,
> considering you need to process extension directives anyway...


 We've been over this several times before.  The problem is the
 requirement to balance DQUOTE and the complexities surrounding the
 error conditions if the DQUOTEs don't balance properly (including
 escaping).
>>>
>>>
>>> Yes, but you are avoiding the question I asked. Are you implementing
>>> quoted-string for extension parameters?
>>
>>
>> No.
>>
>> Here's the grammar I recommend:
>>
>>    Strict-Transport-Security = "Strict-Transport-Security" ":"
>>                                    directive *( ";" [ directive ] )
>>
>>    directive         = max-age | includeSubDomains | STS-d-ext
>>    max-age           = "max-age" "=" delta-seconds
>>    includeSubDomains = "includeSubDomains"
>>    STS-d-ext     = token [ "=" token ]
>>
>> I would also define the precise requirements for parsing all possible
>> input sequences, but I understand that's not fashionable.
>
> Ack. This is at least consistent.
>
> That being said, I disagree. token=quoted-string is widely implemented, and
> if there are clients not getting it right we should fix them.
>
> If you are aware of specific clients having this problem please list them so
> we can open bug reports.

Chrome does not (and will not) implement quoted-string for the STS
header for the reasons I've explained previously.  You're welcome to
file bugs, but I'm just going to close them WONTFIX.

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

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

[Julian Reschke]

On 2011-12-29 22:32, Adam Barth wrote:

On Thu, Dec 29, 2011 at 1:24 PM, Julian Reschke  wrote:

On 2011-12-29 22:18, Adam Barth wrote:

On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke
  wrote:

On 2011-12-29 20:50, Adam Barth wrote:

As I wrote before, I don't think we should include quoted-string in
the grammar.  As far as I know, no one has implemented it and I have
no plans to implement quoted-string in Chrome.  Having quoted-string
in the grammar only leads to pain.,


It would be helpful if you were more precise on the pain it causes,
considering you need to process extension directives anyway...


We've been over this several times before.  The problem is the
requirement to balance DQUOTE and the complexities surrounding the
error conditions if the DQUOTEs don't balance properly (including
escaping).


Yes, but you are avoiding the question I asked. Are you implementing
quoted-string for extension parameters?


No.

Here's the grammar I recommend:

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

directive = max-age | includeSubDomains | STS-d-ext
max-age   = "max-age" "=" delta-seconds
includeSubDomains = "includeSubDomains"
STS-d-ext = token [ "=" token ]

I would also define the precise requirements for parsing all possible
input sequences, but I understand that's not fashionable.


Ack. This is at least consistent.

That being said, I disagree. token=quoted-string is widely implemented, 
and if there are clients not getting it right we should fix them.


If you are aware of specific clients having this problem please list 
them so we can open bug reports.


Best regards, Julian

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

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

[Adam Barth]

On Thu, Dec 29, 2011 at 1:24 PM, Julian Reschke  wrote:
> On 2011-12-29 22:18, Adam Barth wrote:
>> On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke
>>  wrote:
>>> On 2011-12-29 20:50, Adam Barth wrote:
 As I wrote before, I don't think we should include quoted-string in
 the grammar.  As far as I know, no one has implemented it and I have
 no plans to implement quoted-string in Chrome.  Having quoted-string
 in the grammar only leads to pain.,
>>>
>>> It would be helpful if you were more precise on the pain it causes,
>>> considering you need to process extension directives anyway...
>>
>> We've been over this several times before.  The problem is the
>> requirement to balance DQUOTE and the complexities surrounding the
>> error conditions if the DQUOTEs don't balance properly (including
>> escaping).
>
> Yes, but you are avoiding the question I asked. Are you implementing
> quoted-string for extension parameters?

No.

Here's the grammar I recommend:

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

   directive = max-age | includeSubDomains | STS-d-ext
   max-age   = "max-age" "=" delta-seconds
   includeSubDomains = "includeSubDomains"
   STS-d-ext = token [ "=" token ]

I would also define the precise requirements for parsing all possible
input sequences, but I understand that's not fashionable.

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

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

[Julian Reschke]

On 2011-12-29 22:18, Adam Barth wrote:

On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke  wrote:

On 2011-12-29 20:50, Adam Barth wrote:

..-



As I wrote before, I don't think we should include quoted-string in
the grammar.  As far as I know, no one has implemented it and I have
no plans to implement quoted-string in Chrome.  Having quoted-string
in the grammar only leads to pain.,


It would be helpful if you were more precise on the pain it causes,
considering you need to process extension directives anyway...


We've been over this several times before.  The problem is the
requirement to balance DQUOTE and the complexities surrounding the
error conditions if the DQUOTEs don't balance properly (including
escaping).


Yes, but you are avoiding the question I asked. Are you implementing 
quoted-string for extension parameters?




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

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

[Adam Barth]

On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke  wrote:
> On 2011-12-29 20:50, Adam Barth wrote:
>> ..-
>
>> As I wrote before, I don't think we should include quoted-string in
>> the grammar.  As far as I know, no one has implemented it and I have
>> no plans to implement quoted-string in Chrome.  Having quoted-string
>> in the grammar only leads to pain.,
>
> It would be helpful if you were more precise on the pain it causes,
> considering you need to process extension directives anyway...

We've been over this several times before.  The problem is the
requirement to balance DQUOTE and the complexities surrounding the
error conditions if the DQUOTEs don't balance properly (including
escaping).

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

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

[Julian Reschke]

On 2011-12-29 20:50, Adam Barth wrote:
> ..-

As I wrote before, I don't think we should include quoted-string in
the grammar.  As far as I know, no one has implemented it and I have
no plans to implement quoted-string in Chrome.  Having quoted-string
in the grammar only leads to pain.,


It would be helpful if you were more precise on the pain it causes, 
considering you need to process extension directives anyway...


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

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

[Adam Barth]

On Thu, Dec 29, 2011 at 4:39 AM, Julian Reschke  wrote:
> Hi there,
>
> Looking at
> .
>
> I note that the spec doesn't state what ABNF syntax it uses; something like
>  should be
> added.
>
> Now for the actual ABNF
> ():
>
>
>    Strict-Transport-Security = "Strict-Transport-Security" ":"
>                                    directive *( ";" [ directive ] )
>
> This works for me.
>
>
>    directive         = max-age | includeSubDomains | STS-d-ext
>
>    max-age           = "max-age" "=" delta-seconds
>
>    includeSubDomains = "includeSubDomains"
>
>
>    STS-d-ext     = token [ "=" ( token | quoted-string ) ]
>
> I would turn that around; a parser for STS should parse all directives the
> same way, thus:
>
>    directive         = token [ "=" ( token | quoted-string ) ]

As I wrote before, I don't think we should include quoted-string in
the grammar.  As far as I know, no one has implemented it and I have
no plans to implement quoted-string in Chrome.  Having quoted-string
in the grammar only leads to pain.,

Adam


> And then state that this spec defines two directives, and future specs can
> define more (maybe you need to state how to do that; "update" this spec? Add
> registry?)
>
> Then, for max-age and includeSubDomains, define their individual syntax
> separately, and don't forget to describe what to do with things like:
>
>  includeSubDomains="true"
>
> or
>
>  max-age
>
> or
>
>  max-age="10"
>
> Also:
>
>   The max-age directive MUST appear once in the Strict-Transport-
>   Security header field value.  The includeSubDomains directive MAY
>
>   appear once.  The order of appearance of directives in the Strict-
>   Transport-Security header field value is not significant.
>
> It would be better to state that *each* directive (including future ones)
> must appear only once, and that max-age is REQUIRED and includeSubDomains is
> OPTIONAL.
>
> (BTW: wouldn't it make sense to have a default for max-age so it can be made
> OPTIONAL?)
>
>
> Best regards, Julian
>
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

Hi there,

Looking at 
.


I note that the spec doesn't state what ABNF syntax it uses; something 
like  
should be added.


Now for the actual ABNF 
():


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

This works for me.

directive = max-age | includeSubDomains | STS-d-ext

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

includeSubDomains = "includeSubDomains"

STS-d-ext = token [ "=" ( token | quoted-string ) ]

I would turn that around; a parser for STS should parse all directives 
the same way, thus:


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

And then state that this spec defines two directives, and future specs 
can define more (maybe you need to state how to do that; "update" this 
spec? Add registry?)


Then, for max-age and includeSubDomains, define their individual syntax 
separately, and don't forget to describe what to do with things like:


  includeSubDomains="true"

or

  max-age

or

  max-age="10"

Also:

   The max-age directive MUST appear once in the Strict-Transport-
   Security header field value.  The includeSubDomains directive MAY
   appear once.  The order of appearance of directives in the Strict-
   Transport-Security header field value is not significant.

It would be better to state that *each* directive (including future 
ones) must appear only once, and that max-age is REQUIRED and 
includeSubDomains is OPTIONAL.


(BTW: wouldn't it make sense to have a default for max-age so it can be 
made OPTIONAL?)


Best regards, Julian

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

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

[Phillip Hallam-Baker]

I think that the field is going to match the requirements of the HTTP spec:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

   message-header = field-name ":" [ field-value ]
   field-name = token
   field-value= *( field-content | LWS )
   field-content  = 


That takes precedence over the desire to scrape together naive parsers in
my view.

Most people writing code are going to want to skip the need to write a
parser altogether by using existing parser methods built in to their
platform.

This is a standards based specification and so it has to match the format
already defined by the HTTP specification and aspirational or not, any code
that fails to match quoted string is likely to break in future spec
versions.


On Sat, Oct 29, 2011 at 2:50 PM, Adam Barth  wrote:

> On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke 
> 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 = 
>
> 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
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>



-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Bjoern Hoehrmann]

* Julian Reschke 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.

That doesn't matter much really, if you include relevant edge cases in
the specification along with the expected behavior, you are virtually
guaranteed that such issues are discovered quickly as implementers and
testers will start with what is in the specification to find problems,
and it's much less likely that APIs make it very difficult to implement
the right behavior at least compared to telling the difference between
 and  in an XML document using some XML parser API, as far as
my experience with HTTP APIs goes anyway.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Adam Barth]

On Sat, Oct 29, 2011 at 11:50 AM, Adam Barth  wrote:
> On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke  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 = 

Sorry,

extension = *

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

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

[Adam Barth]

On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke  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 = 

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

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

[Phillip Hallam-Baker]

Use of lowercase may is certainly allowed.

But it causes so much hassle as people (1) keep asking if it should be MAY
and (2) 'correct' the draft to use upper case.

It is easier to try using other words instead. Which is not easy since it
tends to crop up all the time in non-normative text.


Probably the best long term solution would be to have an XML2RFC tag that
declared a section as non-normative so that the nits checker can then catch
unintentional uppercasing.


On Sat, Oct 29, 2011 at 2:58 AM, Julian Reschke wrote:

> On 2011-10-29 04:42, =JeffH wrote:
>
>>  >> The max-age directive MUST appear once in the
>> Strict-Transport-Security
>>  >> header field value. The includeSubDomains directive MAY appear once.
>>  >> The order of appearance of directives in the Strict-Transport-Security
>>  >> header field value is not significant.
>>  >>
>>  >> Additional directives extending the the semantic functionality of
>>  >> the Strict-Transport-Security header field may be defined in other
>>  >
>>  > MAY or might ?
>>
>> yes, a good question.
>>
>> I believe that there's examples in other RFCs of the use of the
>> lower-case "may" in situations similar to this (I've seen it discussed
>> many times over the years). I.e., not all instances of "may" in any
>> given RFC are capitalized "MAY"s. In this case, "MAY" isn't appropriate
>> IIRC.
>>
>> And yes, a way to avoid that question/issue is to use a different word
>> such as "might" or "can", which i can do. I just thought a "may" has
>> more correct connotations (but I /knew/ it'd come up as a question :)
>>
>> thanks,
>>
>
> +1 to "can"
>
> __**_
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/**listinfo/websec
>



-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

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.


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

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

[Adam Barth]

On Sat, Oct 29, 2011 at 1:19 AM, Julian Reschke  wrote:
> On 2011-10-29 10:10, Adam Barth wrote:
>>
>> On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschke
>>  wrote:
>>>
>>> On 2011-10-29 05:08, Adam Barth wrote:

 ...
>
> Except for RFC6265, which in the algorithm for parsing "Max-Age=", it
> algorithmically provides for ignoring a value that doesn't match the
> effective value ABNF of..
>
>  ["-"]*DIGIT
>
> ..which would catch the max-age="1" case, but doesn't seem to
> explicitly
> address..
>
>  max-age=

 That's handled by some more general processing rules in the spec.  The
 net result is that it's ignored.

> But in any case, perhaps (additional) browser implementor folk could
> chime
> in here -- do we really need to address such detail-level issues (both
> of
> the examples above and below) in the syntax/grammar we specify in specs
> such
> as these? Or is the new ABNF proposed in the original message in this
> thread
> sufficient?

 Generally, we prefer to be instructed exactly how to behave for every
 possible input (even illegal ones).  There's a long history of
 quoted-string not being implemented correctly by browsers.  I spec
 this as just splitting the string on ; and then processing each
 substring separately, ignoring bogus/future ones.  I know Julian has a
 dream that all HTTP headers will be parsed the same, but quoted-string
 is sufficiently ill-defined w.r.t. error handling that I prefer to
 avoid it.
 ...
>>>
>>> - when discussing generic parsing, we need to distinguish between legacy
>>> cases like cookies, and new headers, where we can do better
>>>
>>> - standardizing handling of broken headers is one thing (and in general I
>>> prefer not to), but that doesn't mean that when defining a new header
>>> field
>>> we shouldn't minimize the things a sender can get wrong; if we know that
>>> some recipients will accept both token and quoted-string anyway, then it
>>> seems like a good thing to simply allow them both, reducing the number of
>>> special-cases in parsing
>>>
>>> - not sure what you mean by "ill-defined w.r.t. error handling"; it's
>>> defined just like most other syntax elements in HTTP -- is there
>>> something
>>> *specific* to quoted-string you have in mind?
>>
>> Most of HTTP is ill-defined w.r.t. error handling.  We muddle through
>> with reverse engineering.
>> ...
>
> It's not ill-defined, but undefined (by design) - see
> .
>
> 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.

Anyway, I'm resigned to lose this argument in this forum.  It just
means we'll need to clean up the mess later in another forum.

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

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

[Julian Reschke]

On 2011-10-29 10:10, Adam Barth wrote:

On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschke  wrote:

On 2011-10-29 05:08, Adam Barth wrote:


...


Except for RFC6265, which in the algorithm for parsing "Max-Age=", it
algorithmically provides for ignoring a value that doesn't match the
effective value ABNF of..

  ["-"]*DIGIT

..which would catch the max-age="1" case, but doesn't seem to explicitly
address..

  max-age=


That's handled by some more general processing rules in the spec.  The
net result is that it's ignored.


But in any case, perhaps (additional) browser implementor folk could
chime
in here -- do we really need to address such detail-level issues (both of
the examples above and below) in the syntax/grammar we specify in specs
such
as these? Or is the new ABNF proposed in the original message in this
thread
sufficient?


Generally, we prefer to be instructed exactly how to behave for every
possible input (even illegal ones).  There's a long history of
quoted-string not being implemented correctly by browsers.  I spec
this as just splitting the string on ; and then processing each
substring separately, ignoring bogus/future ones.  I know Julian has a
dream that all HTTP headers will be parsed the same, but quoted-string
is sufficiently ill-defined w.r.t. error handling that I prefer to
avoid it.
...


- when discussing generic parsing, we need to distinguish between legacy
cases like cookies, and new headers, where we can do better

- standardizing handling of broken headers is one thing (and in general I
prefer not to), but that doesn't mean that when defining a new header field
we shouldn't minimize the things a sender can get wrong; if we know that
some recipients will accept both token and quoted-string anyway, then it
seems like a good thing to simply allow them both, reducing the number of
special-cases in parsing

- not sure what you mean by "ill-defined w.r.t. error handling"; it's
defined just like most other syntax elements in HTTP -- is there something
*specific* to quoted-string you have in mind?


Most of HTTP is ill-defined w.r.t. error handling.  We muddle through
with reverse engineering.
...


It's not ill-defined, but undefined (by design) - see 
.


What I was trying to understand whether there's something special with 
respect to quoted-string?


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

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

[Adam Barth]

On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschke  wrote:
> On 2011-10-29 05:08, Adam Barth wrote:
>>
>> ...
>>>
>>> Except for RFC6265, which in the algorithm for parsing "Max-Age=", it
>>> algorithmically provides for ignoring a value that doesn't match the
>>> effective value ABNF of..
>>>
>>>  ["-"]*DIGIT
>>>
>>> ..which would catch the max-age="1" case, but doesn't seem to explicitly
>>> address..
>>>
>>>  max-age=
>>
>> That's handled by some more general processing rules in the spec.  The
>> net result is that it's ignored.
>>
>>> But in any case, perhaps (additional) browser implementor folk could
>>> chime
>>> in here -- do we really need to address such detail-level issues (both of
>>> the examples above and below) in the syntax/grammar we specify in specs
>>> such
>>> as these? Or is the new ABNF proposed in the original message in this
>>> thread
>>> sufficient?
>>
>> Generally, we prefer to be instructed exactly how to behave for every
>> possible input (even illegal ones).  There's a long history of
>> quoted-string not being implemented correctly by browsers.  I spec
>> this as just splitting the string on ; and then processing each
>> substring separately, ignoring bogus/future ones.  I know Julian has a
>> dream that all HTTP headers will be parsed the same, but quoted-string
>> is sufficiently ill-defined w.r.t. error handling that I prefer to
>> avoid it.
>> ...
>
> - when discussing generic parsing, we need to distinguish between legacy
> cases like cookies, and new headers, where we can do better
>
> - standardizing handling of broken headers is one thing (and in general I
> prefer not to), but that doesn't mean that when defining a new header field
> we shouldn't minimize the things a sender can get wrong; if we know that
> some recipients will accept both token and quoted-string anyway, then it
> seems like a good thing to simply allow them both, reducing the number of
> special-cases in parsing
>
> - not sure what you mean by "ill-defined w.r.t. error handling"; it's
> defined just like most other syntax elements in HTTP -- is there something
> *specific* to quoted-string you have in mind?

Most of HTTP is ill-defined w.r.t. error handling.  We muddle through
with reverse engineering.

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

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

[Julian Reschke]

On 2011-10-29 05:08, Adam Barth wrote:

...

Except for RFC6265, which in the algorithm for parsing "Max-Age=", it
algorithmically provides for ignoring a value that doesn't match the
effective value ABNF of..

  ["-"]*DIGIT

..which would catch the max-age="1" case, but doesn't seem to explicitly
address..

  max-age=


That's handled by some more general processing rules in the spec.  The
net result is that it's ignored.


But in any case, perhaps (additional) browser implementor folk could chime
in here -- do we really need to address such detail-level issues (both of
the examples above and below) in the syntax/grammar we specify in specs such
as these? Or is the new ABNF proposed in the original message in this thread
sufficient?


Generally, we prefer to be instructed exactly how to behave for every
possible input (even illegal ones).  There's a long history of
quoted-string not being implemented correctly by browsers.  I spec
this as just splitting the string on ; and then processing each
substring separately, ignoring bogus/future ones.  I know Julian has a
dream that all HTTP headers will be parsed the same, but quoted-string
is sufficiently ill-defined w.r.t. error handling that I prefer to
avoid it.
...


- when discussing generic parsing, we need to distinguish between legacy 
cases like cookies, and new headers, where we can do better


- standardizing handling of broken headers is one thing (and in general 
I prefer not to), but that doesn't mean that when defining a new header 
field we shouldn't minimize the things a sender can get wrong; if we 
know that some recipients will accept both token and quoted-string 
anyway, then it seems like a good thing to simply allow them both, 
reducing the number of special-cases in parsing


- not sure what you mean by "ill-defined w.r.t. error handling"; it's 
defined just like most other syntax elements in HTTP -- is there 
something *specific* to quoted-string you have in mind?


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

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

[Julian Reschke]

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

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

[Julian Reschke]

On 2011-10-29 04:42, =JeffH wrote:

 >> The max-age directive MUST appear once in the Strict-Transport-Security
 >> header field value. The includeSubDomains directive MAY appear once.
 >> The order of appearance of directives in the Strict-Transport-Security
 >> header field value is not significant.
 >>
 >> Additional directives extending the the semantic functionality of
 >> the Strict-Transport-Security header field may be defined in other
 >
 > MAY or might ?

yes, a good question.

I believe that there's examples in other RFCs of the use of the
lower-case "may" in situations similar to this (I've seen it discussed
many times over the years). I.e., not all instances of "may" in any
given RFC are capitalized "MAY"s. In this case, "MAY" isn't appropriate
IIRC.

And yes, a way to avoid that question/issue is to use a different word
such as "might" or "can", which i can do. I just thought a "may" has
more correct connotations (but I /knew/ it'd come up as a question :)

thanks,


+1 to "can"
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Adam Barth]

On Fri, Oct 28, 2011 at 7:36 PM, =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.
>
> 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?
>
> In doing a quick grep on RFCs for delta-seconds, I note that some of the
> specs using it (I didn't look at them all) appear to not directly address
> the case above.
>
> Except for RFC6265, which in the algorithm for parsing "Max-Age=", it
> algorithmically provides for ignoring a value that doesn't match the
> effective value ABNF of..
>
>  ["-"]*DIGIT
>
> ..which would catch the max-age="1" case, but doesn't seem to explicitly
> address..
>
>  max-age=

That's handled by some more general processing rules in the spec.  The
net result is that it's ignored.

> But in any case, perhaps (additional) browser implementor folk could chime
> in here -- do we really need to address such detail-level issues (both of
> the examples above and below) in the syntax/grammar we specify in specs such
> as these? Or is the new ABNF proposed in the original message in this thread
> sufficient?

Generally, we prefer to be instructed exactly how to behave for every
possible input (even illegal ones).  There's a long history of
quoted-string not being implemented correctly by browsers.  I spec
this as just splitting the string on ; and then processing each
substring separately, ignoring bogus/future ones.  I know Julian has a
dream that all HTTP headers will be parsed the same, but quoted-string
is sufficiently ill-defined w.r.t. error handling that I prefer to
avoid it.

>> > 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?
>
>
>> Also, identifiers "max-age" and "includeSubDomains" are
>> case-insensitive, right? This follows from the ABNF,
>
> yes, and yes.
>
>> but might be worth
>> saying again in prose; in particular because it also needs to be the
>> case for all future extensions.
>
> Agreed. I see how you did it in RFC 6266 and will endeavor to do similarly.
>
> thanks again,
>
> =JeffH
>
>
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[=JeffH]

>>   The max-age directive MUST appear once in the Strict-Transport-Security
>>   header field value. The includeSubDomains directive MAY appear once.
>>   The order of appearance of directives in the Strict-Transport-Security
>>   header field value is not significant.
>>
>>   Additional directives extending the the semantic functionality of
>>   the Strict-Transport-Security header field may be defined in other
>
> MAY or might ?

yes, a good question.

I believe that there's examples in other RFCs of the use of the lower-case 
"may" in situations similar to this (I've seen it discussed many times over the 
years). I.e., not all instances of "may" in any given RFC are capitalized 
"MAY"s. In this case, "MAY" isn't appropriate IIRC.


And yes, a way to avoid that question/issue is to use a different word such as 
"might" or "can", which i can do.  I just thought a "may" has more correct 
connotations (but I /knew/ it'd come up as a question :)


thanks,

=JeffH



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

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

[=JeffH]

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



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?


In doing a quick grep on RFCs for delta-seconds, I note that some of the specs 
using it (I didn't look at them all) appear to not directly address the case above.


Except for RFC6265, which in the algorithm for parsing "Max-Age=", it 
algorithmically provides for ignoring a value that doesn't match the effective 
value ABNF of..


  ["-"]*DIGIT

..which would catch the max-age="1" case, but doesn't seem to explicitly 
address..

  max-age=

But in any case, perhaps (additional) browser implementor folk could chime in 
here -- do we really need to address such detail-level issues (both of the 
examples above and below) in the syntax/grammar we specify in specs such as 
these? Or is the new ABNF proposed in the original message in this thread 
sufficient?



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



> Also, identifiers "max-age" and "includeSubDomains" are
> case-insensitive, right? This follows from the ABNF,

yes, and yes.

> but might be worth
> saying again in prose; in particular because it also needs to be the
> case for all future extensions.

Agreed. I see how you did it in RFC 6266 and will endeavor to do similarly.

thanks again,

=JeffH


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

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

[Adam Barth]

On Thu, Oct 27, 2011 at 11:03 AM, =JeffH  wrote:
> I've been working with Julian on simplifying the STS header field syntax.
> Here's where it's presently at -- thoughts?
>
> thanks again to Julian and Ryan for their earlier feedback.
>
> =JeffH
>
>
> ###
>
> 5.1. Strict-Transport-Security HTTP Response Header Field
>
>   The Strict-Transport-Security HTTP response header field indicates to
>   a UA that it MUST enforce the HSTS Policy in regards to the host
>   emitting the response message containing this header field.
>
>   Note: this specification uses the augmented BNF (ABNF) notation from
>   Section 2 of [RFC2616], including its rules for "implied linear
>   whitespace (LWS)", and case-insensitivity of quoted-string literals.
>
>   The ABNF syntax for the Strict-Transport-Security (STS) HTTP Response
>   Header field is:
>
>
>    Strict-Transport-Security = "Strict-Transport-Security" ":"
>                                directive *( ";" [ directive ] )
>
>
>   STS directives:
>
>    directive         = max-age | includeSubDomains | STS-d-ext
>
>    max-age           = "max-age" "=" delta-seconds
>
>    includeSubDomains = "includeSubDomains"
>
>
>   The max-age directive MUST appear once in the Strict-Transport-Security
>   header field value. The includeSubDomains directive MAY appear once.
>   The order of appearance of directives in the Strict-Transport-Security
>   header field value is not significant.
>
>   Additional directives extending the the semantic functionality of
>   the Strict-Transport-Security header field may be defined in other

MAY or might ?

>   specifications, using the STS directive extension point (STS-d-ext)
>   syntax:
>
>    STS-d-ext     = token [ "=" ( token | quoted-string ) ]
>
>
>   Defined in [RFC2616]:
>
>    delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>
>    token         = 
>    quoted-string = 
>
>
> ###
>
>
>
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2011-10-27 20:03, =JeffH wrote:

I've been working with Julian on simplifying the STS header field
syntax. Here's where it's presently at -- thoughts?

thanks again to Julian and Ryan for their earlier feedback.

=JeffH


That looks much better to me. More inline.


###

5.1. Strict-Transport-Security HTTP Response Header Field

The Strict-Transport-Security HTTP response header field indicates to
a UA that it MUST enforce the HSTS Policy in regards to the host
emitting the response message containing this header field.

Note: this specification uses the augmented BNF (ABNF) notation from
Section 2 of [RFC2616], including its rules for "implied linear
whitespace (LWS)", and case-insensitivity of quoted-string literals.

The ABNF syntax for the Strict-Transport-Security (STS) HTTP Response
Header field is:


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.



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. (To get this right an API will need 
to distinguish between "parameter missing", "parameter present and 
valueless" and "parameter present and having a zero-length value".


Also, identifiers "max-age" and "includeSubDomains" are 
case-insensitive, right? This follows from the ABNF, but might be worth 
saying again in prose; in particular because it also needs to be the 
case for all future extensions.



The max-age directive MUST appear once in the Strict-Transport-Security
header field value. The includeSubDomains directive MAY appear once.
The order of appearance of directives in the Strict-Transport-Security
header field value is not significant.

Additional directives extending the the semantic functionality of
the Strict-Transport-Security header field may be defined in other
specifications, using the STS directive extension point (STS-d-ext)
syntax:

STS-d-ext = token [ "=" ( token | quoted-string ) ]


Defined in [RFC2616]:

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


###


Best regards, Julian

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

[websec] Strict-Transport-Security syntax redux

[=JeffH]

I've been working with Julian on simplifying the STS header field syntax. 
Here's where it's presently at -- thoughts?


thanks again to Julian and Ryan for their earlier feedback.

=JeffH


###

5.1. Strict-Transport-Security HTTP Response Header Field

   The Strict-Transport-Security HTTP response header field indicates to
   a UA that it MUST enforce the HSTS Policy in regards to the host
   emitting the response message containing this header field.

   Note: this specification uses the augmented BNF (ABNF) notation from
   Section 2 of [RFC2616], including its rules for "implied linear
   whitespace (LWS)", and case-insensitivity of quoted-string literals.

   The ABNF syntax for the Strict-Transport-Security (STS) HTTP Response
   Header field is:


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


   STS directives:

directive = max-age | includeSubDomains | STS-d-ext

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

includeSubDomains = "includeSubDomains"


   The max-age directive MUST appear once in the Strict-Transport-Security
   header field value. The includeSubDomains directive MAY appear once.
   The order of appearance of directives in the Strict-Transport-Security
   header field value is not significant.

   Additional directives extending the the semantic functionality of
   the Strict-Transport-Security header field may be defined in other
   specifications, using the STS directive extension point (STS-d-ext)
   syntax:

STS-d-ext = token [ "=" ( token | quoted-string ) ]


   Defined in [RFC2616]:

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


###



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

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

[Julian Reschke]

On 2011-10-08 20:22, Julian Reschke wrote:

...
directive = token( "=" ( token / quoted-string ) )
...


And this should have been...:

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

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

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

[Julian Reschke]

On 2011-10-07 01:23, =JeffH wrote:

...


Trying to summarize my concerns and proposals...

(1) RFC2616-or-HTTPbis

In a perfect world I could give you an exact time-of-arrival for 
HTTPbis. But the world is not perfect; and progress on HTTPbis mainly 
depends on the availability of the editors, and, more importantly, 
people showing up on the HTTPbis mailing list to help in closing issues 
and reviewing the existing text. So help *is* appreciated. -> 



(2) Multiple header instances

Header fields can occur multiple times, even when they were intended not 
to. Examples: Location, Content-Length. When this happens, we usually 
see interop problems because some consumers pick the first, some pick 
the second, and some combine them using a comma, as described in HTTP spec.


This can be dangerous when the repetition makes the message format 
ambiguous (Content-Length, for instance). It also means that it allows 
smuggling, relying on checkers/intermediaries only seeing one of the 
headers.


Note that Chrome and FF have become very strict in checking for this for 
C-L, and FF does even more checks (syntax of C-L, also checks for 
Location and Content-Disposition).


So *if* STS doesn't allow multiple header fields (which would require 
switching to a comma-separated syntax), the spec should be crystal clear 
what to do when multiple instances are encountered; in many cases the 
default should be "ignore the header field" or even "consider the 
message to be broken". Not sure what's best here.


Also note that somebody else may be combining multiple fields into a 
single one, and the recipient will see those concatenated with commas as 
separators. Optimally the format is robust enough to detect things like 
that.


(3) ABNF organization

Any header field that is extensible needs to define the syntax for the 
extension point, so existing code can parse them. Don't make extensions 
different from the builtins with respect to syntax. It just makes the 
parser more complicated.


So just define a single ABNF for STS directives in ABNF.

For instance, using RFC 2616 ABNF and list syntax:

Strict-Transport-Security =
  "Strict-Transport-Security" ":" 1#directive

...or when sticking to semicolon:

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

Then

directive = token( "=" ( token / quoted-string ) )

In prose, add additional constrains, such as "MUST contain FOOBAR 
directive exactly once".


Finally, for each builtin directive state the individual syntax of the 
param *value*, and do not make the ABNF vary based on the directive.


Hope this helps.

Also worth reading: 



Best regards, Julian





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

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

[=JeffH]

Hi Ryan, thanks for the detailed feedback.


Following Julian Reschke's questions, I also had a few questions related
to the draft-02 syntax. I've been basing my understanding on RFC 5234,
which I understand to be the most current/relevant to understanding the
syntax.


First, maxAge and includeSubDomains both include value extension points,
defined as:

maxAge = "max-age"  OWS  "="  OWS  delta-seconds  [ OWS v-ext ]
includeSubDomains =  "includeSubDomains"  [ OWS v-ext ]
v-ext  = value ; STS extension value

However, the rule for OWS is specified as:

OWS   = *( [ CRLF ] WSP )

As written, it would seem that the OWS between either delta-seconds or
"includeSubDomains" can legitimately be omitted before the v-ext. As best
I can tell, this would mean that the following values would still be
valid:

max-age=123.456
includeSubDomainsabc

In the first case ".456" is the v-ext, while in the second, "abc" is. In
both cases, because the OWS is truly optional (valid to have 0
occurrences), only the v-ext is present.


yes, trying to use the OWS construction there is broken as you point out.




To remedy this, I believe some form of explicit delimiter between the
existing values and the v-ext should be defined for the existing headers.
If the intent was to have extension values whitespace separated, then
would the following modification to introduce required whitespace solve
it?

maxAge = "max-age"  OWS  "="  OWS  delta-seconds  [ RWS v-ext ]
includeSubDomains =  "includeSubDomains"  [ RWS v-ext ]
v-ext  = value ; STS extension value
OWS   = *( [ CRLF ] WSP )
RWS   = 1*( [ CRLF ] WSP )


Yes, using a required whitespace (RWS) construction would seem to fix it. 
However, since we've migrated to base the ABNF on RFC2616 and not HTTPbis, we 
should perhaps whole-hog and use the former's LWS (linear whitespace) construct 
which has the "implied whitespace" notion, and get rid of the OWS stuff.




Alternatively, can/should the v-ext be dropped entirely, and extensions to
the STS header be accomplished via defining a new STS-d-ext?


yes, that's a possibility. I put the v-ext thing in there with max-age for 
completeness without a good use case, and maybe it'll just cause more trouble 
than its worth.




Second, as currently specified, extension directives take the form of:

STS-d  = STS-d-cur / STS-d-ext
STS-d-ext  = name  ; STS extension directive
name   = token
token  = 1*tchar
tchar  = "!" / "#" / "$" / "%" / "&" / "'" / "*"
 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
   / DIGIT / ALPHA

As currently written, STS-d-ext doesn't seem to be able to contain name
"=" value pairs such as those used by Evans' and Palmer's pinning draft,
because "=" is not a valid token character. Likewise, it wouldn't be able
to contain "#rule" style lists, because comma is not a valid tchar.


good catch.



Should STS-d-ext be defined as "value" instead, so that it contain a wider
range of characters?


offhand, "value" seems the way to go to me.

Again, thanks much for your review, I'm working on getting new rev out with 
repaired ABNF amongst other things.


=JeffH

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

[websec] Strict-Transport-Security syntax redux

[Ryan Sleevi]

Following Julian Reschke's questions, I also had a few questions related
to the draft-02 syntax. I've been basing my understanding on RFC 5234,
which I understand to be the most current/relevant to understanding the
syntax.


First, maxAge and includeSubDomains both include value extension points,
defined as:

maxAge = "max-age"  OWS  "="  OWS  delta-seconds  [ OWS v-ext ]
includeSubDomains =  "includeSubDomains"  [ OWS v-ext ]
v-ext  = value ; STS extension value

However, the rule for OWS is specified as:

OWS   = *( [ CRLF ] WSP )

As written, it would seem that the OWS between either delta-seconds or
"includeSubDomains" can legitimately be omitted before the v-ext. As best
I can tell, this would mean that the following values would still be
valid:

max-age=123.456
includeSubDomainsabc

In the first case ".456" is the v-ext, while in the second, "abc" is. In
both cases, because the OWS is truly optional (valid to have 0
occurrences), only the v-ext is present. For maxAge in particular, this
can lead to very silly parsing interpretations. Considering the following
value:

max-age=123

If I'm not mistaken, ABNF doesn't specify any sort of greedy matching, so
this could be interpreted as:
delta-seconds = 1 (1DIGIT), v-ext = 23 (0OWS 2tchar)
delta-seconds = 12 (2DIGIT), v-ext = 3 (0OWS 1tchar)

To remedy this, I believe some form of explicit delimiter between the
existing values and the v-ext should be defined for the existing headers.
If the intent was to have extension values whitespace separated, then
would the following modification to introduce required whitespace solve
it?

maxAge = "max-age"  OWS  "="  OWS  delta-seconds  [ RWS v-ext ]
includeSubDomains =  "includeSubDomains"  [ RWS v-ext ]
v-ext  = value ; STS extension value
OWS   = *( [ CRLF ] WSP )
RWS   = 1*( [ CRLF ] WSP )

Alternatively, can/should the v-ext be dropped entirely, and extensions to
the STS header be accomplished via defining a new STS-d-ext?


Second, as currently specified, extension directives take the form of:

STS-d  = STS-d-cur / STS-d-ext
STS-d-ext  = name  ; STS extension directive
name   = token
token  = 1*tchar
tchar  = "!" / "#" / "$" / "%" / "&" / "'" / "*"
 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
   / DIGIT / ALPHA

As currently written, STS-d-ext doesn't seem to be able to contain name
"=" value pairs such as those used by Evans' and Palmer's pinning draft,
because "=" is not a valid token character. Likewise, it wouldn't be able
to contain "#rule" style lists, because comma is not a valid tchar.

Should STS-d-ext be defined as "value" instead, so that it contain a wider
range of characters? Alternatively, if the intent for STS-d-ext was that
it would always include some name, should it be defined as "name [ OWS "="
OWS value ]"?

Either way seems to offer a solution. It seems that if a parser were
written based on the current draft, it would be correct/valid to reject an
STS header that included cert pins, as specified in the current pinning
draft. This would be because the cert pinning draft makes use of "="
within the extension definitions, which is not a legal character for an
STS-d-ext in the base spec.


Best regards,
Ryan


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