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

From: =JeffH <[email-masked]>
Date: Wed, 14 Sep 2011 14:08:27 -0700

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

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.

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

; 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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Sep 2011 14:34:09 +0200

On 2011-09-14 23:08, =JeffH wrote:
> 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.

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, and 
(b) when an intermediate folds multiple headers using the comma syntax.

> Ah, thanks, yes -- i was unsure of how to make includeSubDomains
> optional while max-age is required, and that hack didn't work.
>

...which makes putting max-age first required.

> tchar = "!" / "#" / "$" / "%" / "&amp;" / "'" / "*"

I think it would be simpler not to try to express this in the ABNF.

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

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Sep 2011 14:16:11 -0400

Agreed, just write the syntax so that it specified a MIME header-ish
tag-value list. Then define the tags and the syntax of the
corresponding values separately.

That makes it much easier to extend the protocol at the API level
since the API can simply deliver the tag-value list to the caller.

Hasn't this been specified somewhere already?

On Sun, Sep 25, 2011 at 8:34 AM, Julian Reschke <[email-masked]> 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?)
>>
> 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, and (b) when
> an intermediate folds multiple headers using the comma syntax.
>
>>  > 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...
>>
> 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...
> :-).
>
> Best regards, Julian
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

-- 
Website: http://hallambaker.com/