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

From: =JeffH <[email-masked]>
Date: Tue, 27 Sep 2011 16:16:56 -0700

thx for the comments Julian.

 > On 2011-09-14 23:08, =JeffH wrote:
 >>  > a few questions about the header field syntax:
 >>  >
 >>  > Strict-Transport-Security =
 >>  > "Strict-Transport-Security" ":" OWS STS-v OWS
 >>  >
 >>  > So the header field is *not* using the RFC2616 list syntax. So you
 >> can have
 >>  >
 >>  > Strict-Transport-Security: a; b
 >>  >
 >>  > but *not*
 >>  >
 >>  > Strict-Transport-Security: a
 >>  > Strict-Transport-Security: b
 >>  >
 >>  > because that would be equivalent to
 >>  >
 >>  > Strict-Transport-Security: a, b
 >>  >
 >>  > (is this intentional?)
 >>
 >> well, it was not necessarily intentional as far as I recall. We either
 >> managed to overlook, or regarded as inappropriate for this header, the
 >> RFC2616 list syntax (i.e., the "#rule"), that defines such implicit
 >> comma-separated lists.
 >> Also, we'd noted that quite a number of header field definitions used
 >> semi-colons as a delimiter, but perhaps hadn't noted that those overall
 >> productions often are embedded within such comma-separated lists.
 >
 > Yes, that's the list-of-parametrized-things format.
 >
 >> However, in thinking about it a little bit, for this particular header
 >> field, as it's presently defined, it doesn't seem appropriate to have it
 >> explicitly be comma-separated repeatable (aka #rule), because only one
 >> instance of "S-T-S: max-age=n" is effective in terms of established the
 >> cached Known HSTS Host in the UA.
 >
 > In that case, as this is security related, you may want to talk about
 > what recipients are to do when (a) they *do* get multiple instances,

that's already done in -websec-strict-transport-sec-02 in S 7.1.

 > and
 > (b) when an intermediate folds multiple headers using the comma syntax.

ah, so an intermediate can/might do that to multiple occurrences of any header 
field in a message ?

 >>  > Also in
 >>  >
 >>  > ; value
 >>  > STS-v = STS-d
 >>  > / STS-d *( OWS ";" OWS STS-d OWS )
 >>  >
 >>  > ; STS directive
 >>  > STS-d = STS-d-cur / STS-d-ext
 >>  >
 >>  > ; defined STS directives
 >>  > STS-d-cur = maxAge / [ includeSubDomains ]
 >>  >
 >>  > having includeSubDomains optional is a bit weird.
 >>  >
 >>  > This means that the empty string would be a valid STS-d-cur, thus an
 >>  > empty header field is allowed...
 >>
 >> Ah, thanks, yes -- i was unsure of how to make includeSubDomains
 >> optional while max-age is required, and that hack didn't work.
 >>
 >> I've now re-worked it as below -- how's that look?
 >>
 >> thanks again,
 >>
 >> =JeffH
 >>
 >>
 >> Strict-Transport-Security =
 >> "Strict-Transport-Security" ":" OWS STS-v OWS
 >>
 >> ; STS header field value; must have a max-age:
 >>
 >> STS-v = max-age
 >> / max-age *( OWS ";" OWS STS-d OWS )
 >
 > ...which makes putting max-age first required.
 >
 >> ; additional STS directives:
 >>
 >> STS-d = STS-d-cur / STS-d-ext
 >>
 >> ; currently defined STS directives,
 >> ; delta-seconds is 1*DIGIT and is from [RFC2616]:
 >>
 >> max-age = "max-age" OWS "=" OWS delta-seconds [ OWS v-ext ]
 >>
 >> STS-d-cur = includeSubDomains
 >>
 >> includeSubDomains = "includeSubDomains" [ OWS v-ext ]
 >>
 >>
 >> ; extension points
 >> STS-d-ext = name ; STS extension directive
 >>
 >> v-ext = value ; STS extension value
 >>
 >> name = token
 >>
 >> value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or
 >> ; [ ! .. : ] [ &lt; .. ~ ] any visible chars other than ";"
 >>
 >> token = 1*tchar
 >>
 >> tchar = "!" / "#" / "$" / "%" / "&amp;" / "'" / "*"
 >> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
 >> / DIGIT / ALPHA
 >> ; visible (printing) characters, except visible
 >> ; separators.
 >> ; DIGIT, ALPHA, separators are from [RFC2616]
 >>
 >> ; Basic rules:
 >>
 >> OWS = *( [ CRLF ] WSP )
 >> ; Optional White Space
 >>
 >> WSP = SP / HTAB
 >>
 >> CRLF = CR LF
 >>
 >> ; CR, LF, SP, HTAB are from [RFC2616]
 >>
 >>
 >> ---
 >> end
 >
 > I think it would be simpler not to try to express this in the ABNF.

what do you mean by "this" ?

 > Just use the ABNF to state the core syntax (that a parser will need to
 > understand), and then put additional requirements about what directives
 > must be there in prose (we're doing the same in HTTPbis, but aren't done
 > yet... :-).

do you have a particular example in mind?

I'm guessing that the Expect header might be a good example, from 
-httpbis-p2-semantics-16, yes?

thanks again,

=JeffH

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Sep 2011 08:34:23 +0200

> that's already done in -websec-strict-transport-sec-02 in S 7.1.

Indeed:

           If a UA receives more than one Strict-Transport-Security
           header field in a HTTP response message over secure transport,
           then the UA SHOULD process only the first such header field.

I think it would be cleaner to consider the message broken in this case.

> ah, so an intermediate can/might do that to multiple occurrences of any
> header field in a message ?

Yes.

> what do you mean by "this" ?

Essentially constraints on what directives need to be there (as opposed 
to their syntax).

> do you have a particular example in mind?

HTTPbis, for instance, doesn't enumerate header field names in the ABNF 
anymore.

> -httpbis-p2-semantics-16, yes?

Not really, it still has the directive "100-continue" spelled out in the 
ABNF.

Best regards, Julian