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

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Dec 2011 13:39:23 +0100

Hi there,

Looking at 
<http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-03>.

I note that the spec doesn't state what ABNF syntax it uses; something 
like <http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.2.p.2> 
should be added.

Now for the actual ABNF 
(<http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-03#section-5.1>):

     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

---

From: Adam Barth <[email-masked]>
Date: Thu, 29 Dec 2011 11:50:18 -0800

On Thu, Dec 29, 2011 at 4:39 AM, Julian Reschke <[email-masked]> wrote:
> I note that the spec doesn't state what ABNF syntax it uses; something like
> <http://greenbytes.de/tech/webdav/rfc5988.html#rfc.section.2.p.2> should be
> added.
>
> Now for the actual ABNF
> I would turn that around; a parser for STS should parse all directives the
> same way, thus:
>

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?)
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Dec 2011 22:13:08 +0100

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

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

---

From: Adam Barth <[email-masked]>
Date: Thu, 29 Dec 2011 13:18:31 -0800

> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Dec 2011 22:24:44 +0100

On 2011-12-29 22:18, Adam Barth wrote:
> On Thu, Dec 29, 2011 at 1:13 PM, Julian Reschke<[email-masked]>  wrote:

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

---

From: Adam Barth <[email-masked]>
Date: Thu, 29 Dec 2011 13:32:09 -0800

> quoted-string for extension parameters?

No.

Here's the grammar I recommend:

   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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Dec 2011 22:38:29 +0100

On 2011-12-29 22:32, Adam Barth wrote:
> On Thu, Dec 29, 2011 at 1:24 PM, Julian Reschke<[email-masked]>  wrote:

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

---

From: Adam Barth <[email-masked]>
Date: Thu, 29 Dec 2011 13:45:03 -0800

On Thu, Dec 29, 2011 at 1:38 PM, Julian Reschke <[email-masked]> wrote:
> 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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Dec 2011 09:18:46 +0100

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

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

---

From: Adam Barth <[email-masked]>
Date: Fri, 30 Dec 2011 00:46:58 -0800

On Fri, Dec 30, 2011 at 12:18 AM, Julian Reschke <[email-masked]> wrote:
> 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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Dec 2011 09:53:29 +0100

On 2011-12-30 09:46, Adam Barth wrote:
> On Fri, Dec 30, 2011 at 12:18 AM, Julian Reschke<[email-masked]>  wrote:

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

---

From: Adam Barth <[email-masked]>
Date: Fri, 30 Dec 2011 01:13:48 -0800

On Fri, Dec 30, 2011 at 12:53 AM, Julian Reschke <[email-masked]> wrote:
>>> authors
> 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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Dec 2011 11:00:46 +0100

> use quoted-string in a future directive, it won't actually work in

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

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

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

---

From: Adam Barth <[email-masked]>
Date: Fri, 30 Dec 2011 10:37:37 -0800

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