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

From: Tobias Gondrom <[email-masked]>
Date: Thu, 05 Jan 2012 04:55:10 +0000

Hello websec fellows,

<hat="chair>
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<[email-masked]>  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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 05 Jan 2012 09:20:27 +0100

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

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/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Jan 2012 09:54:43 +0100

On 2012-01-05 09:20, Anne van Kesteren 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.
>

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Jan 2012 07:59:58 -0800

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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 05 Jan 2012 18:50:01 +0100

On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman <[email-masked]>  
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.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Jan 2012 19:06:42 +0100

On 2012-01-05 18:50, Anne van Kesteren wrote:
>>> - principle of least surprise and consistency - if quoted-string
>>> works in other header fields with param syntax, why not here?
>>
> 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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 05 Jan 2012 21:22:07 +0100

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Jan 2012 21:25:57 +0100

On 2012-01-05 21:22, Anne van Kesteren wrote:
> On Thu, 05 Jan 2012 19:06:42 +0100, Julian Reschke
> <[email-masked]> 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
> 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:

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/266>

<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HeaderFieldTypes>

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 09 Jan 2012 01:10:16 +0100

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

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:[email-masked] · 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/

---

From: Adam Barth <[email-masked]>
Date: Sun, 8 Jan 2012 16:25:31 -0800

On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann <[email-masked]> wrote:
> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jan 2012 01:39:07 +0100

On 2012-01-09 01:25, Adam Barth wrote:
> On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann<[email-masked]>  wrote:
>> * Tobias Gondrom wrote:
>>> <hat="chair>
> ...

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Jan 2012 18:17:29 -0800

> 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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 15 Jan 2012 23:30:59 +0100

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

I note you didn't supply examples.

Best regards, Julian

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Jan 2012 23:38:10 -0600

> field values are typically implemented in practice. I suspect it to be

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 16 Jan 2012 09:26:34 +0100

> paths is having protocol grammar that's never ever used - until it's

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 21 Jan 2012 00:49:25 +0100

>they should, but that's not an excuse for not trying to do better with 

(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:[email-masked] · 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/