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

From: =JeffH <[email-masked]>
Date: Thu, 27 Oct 2011 11:03:39 -0700

I've been working with Julian on simplifying the STS header field syntax. 
Here's where it's presently at -- thoughts?

thanks again to Julian and Ryan for their earlier feedback.

=JeffH

###

5.1. Strict-Transport-Security HTTP Response Header Field

    The Strict-Transport-Security HTTP response header field indicates to
    a UA that it MUST enforce the HSTS Policy in regards to the host
    emitting the response message containing this header field.

    Note: this specification uses the augmented BNF (ABNF) notation from
    Section 2 of [RFC2616], including its rules for "implied linear
    whitespace (LWS)", and case-insensitivity of quoted-string literals.

    The ABNF syntax for the Strict-Transport-Security (STS) HTTP Response
    Header field is:

     Strict-Transport-Security = "Strict-Transport-Security" ":"
                                 directive *( ";" [ directive ] )

    STS directives:

     directive         = max-age | includeSubDomains | STS-d-ext

     max-age           = "max-age" "=" delta-seconds

     includeSubDomains = "includeSubDomains"

    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
    specifications, using the STS directive extension point (STS-d-ext)
    syntax:

     STS-d-ext     = token [ "=" ( token | quoted-string ) ]

    Defined in [RFC2616]:

     delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>
     token         = <token, defined in [RFC2616], Section 2.2>
     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>

###

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Oct 2011 21:27:26 +0200

On 2011-10-27 20:03, =JeffH wrote:
> I've been working with Julian on simplifying the STS header field
> syntax. Here's where it's presently at -- thoughts?
>

That looks much better to me. More inline.

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

> 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. (To get this right an API will need 
to distinguish between "parameter missing", "parameter present and 
valueless" and "parameter present and having a zero-length value".

Also, identifiers "max-age" and "includeSubDomains" are 
case-insensitive, right? This follows from the ABNF, but might be worth 
saying again in prose; in particular because it also needs to be the 
case for all future extensions.

> quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Thu, 27 Oct 2011 23:47:22 -0700

>   the Strict-Transport-Security header field may be defined in other

MAY or might ?

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 29 Oct 2011 21:02:39 +0200

>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
<x/> and <x /> in an XML document using some XML parser API, as far as
my experience with HTTP APIs goes anyway.
-- 
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/