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

[websec] An alternative approach to Security Policy

[Phillip Hallam-Baker]

I submitted a version of this document last week but wanted to get some
additional examples in using the new ni URI proposal before raising it on
the list. This has now been done:

http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt

This is related to the 'Must use TLS', CA-Pinning and Strict Security work
here but separates the security policy framework from the mode of
distribution completely.


We have been discussing security policy in IETF for quite some time. There
seem to be two major technical issues that cause problems:

1) Choice of distribution mechanism
2) False positives due to badly administered systems


I think I have found the solution to the first: It does not need to be a
choice. There are advantages and disadvantages to each approach. DNS is the
authoritative source for statements on the DNS but DNSSEC will not be ready
for prime time for many, many years. HTTP headers are expedient but only
give security after first contact. And DNS and HTTP headers both suffer from
the problem of what to do when the attacker blocks access to the online
confirmation mechanism completely. Meanwhile pushing out blocklists of 'hot
sites' provides effective security but does not scale'

Why choose? Each approach has advantages and disadvantages. So why not have
a single language for policy statements that is strictly limited to
restrictive statements that can be used to create statements that can be
carried over any available transport?


The false positives problem is a much bigger problem conceptually than in
practice. In theory DKIM policy should be causing all sorts of legitimate
mail to be refused delivery. What saves the system is the fact that DKIM
statements are only one input into anti-spam filters and is only given the
weight the data justifies.

I see security policy being applied in HTTP and similar cases in the same
way. Statements made by domain name owners will in the first instance serve
as advice to companies that provide Internet safety products who will
combine the data in the security policy statements with data from other
sources to arrive at security decisions.

Every attack has a human intelligence in there somewhere. Expecting to have
effective security without any human intelligence in the defense is probably
a mistake.


The second approach to overcoming the 'false positives' issue is to observe
that reporting a policy violation has much more value than blocking sites.
Blocking sites only protects the users who have the security policy
capability configured and enabled. Reporting a policy violation enables
remediation that can protect the whole Internet community.


Next Steps:

This particular draft is intentionally targeted at use in a static
interchange format. This would be used for defining local security policies
(e.g. configuring all the web browsers at bigcorp.com to impose a particular
policy for corporate servers) and to be used for emergency, data-driven
response.

Clearly this should converge with the Google Policy proposal for HTTP. I
don't think that there are major differences and would be astonished if this
was incompatible. But a general purpose format designed to support more
protocols than HTTP will look a little different to one that is designed to
tackle the problem at a higher level.

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