W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

following up on STS feedback -- draft-hodges-strict-transport-sec-06.plain.html

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Fri, 18 Dec 2009 14:44:09 -0800
Message-ID: <4B2C05B9.5080705@KingsMountain.com>
To: W3C Web Security Interest Group <public-web-security@w3.org>
I've pushed out the -06 rev of the STS spec..


I've attempted to chronicle all the items below that are included in -06 but 
that I hadn't as yet indicated that they are addressed in -06.

Items from the original messages that this message is a followup to, that 
aren't addressed in this message (and thus not addressed in -06), will be 
addressed in -07 or later STS spec revisions.

Also, there are outstanding feedback comments from Aryeh Gregor and Bil Corry 
that I'll address in -07 or later.


PayPal InfoSec

In reply to:
Re: Feedback on the Strict-Transport-Security specification (part 1)

=JeffH replied:
>   Adam replied:
>   > EricLaw had said:
>   >> [Section 2.4.2: Detailed Core Requirements]: Requirements #5 and #6 are
>   >> problematic because browsers (generally speaking) often don't have rock
>   >> solid knowledge of where the proper "private domain" / "public suffix"
>   >> transition occurs.
>   >
>   > I think there might be some confusion about what "higher-level" means
>   > in this context.  The intent is that:
>   >
>   > 1) both example.com and foo.example.com could set policy for
>   > bar.foo.example.com.
>   > 2) Neither bar.foo.example.com nor foo.example.com could set policy
>   > for example.com.
>   > 3) bar.foo.example.com cannot set policy for foo.example.com.
>   > 4) foo.example.com cannot set policy for qux.example.com.
>   >
>   > etc.
>   >
>   > I don't think we need a notion of a public suffix to enforce these rules.
> agreed.

I included the above examples in -06.

>   >> [Section 5.1: Syntax] Are the tokens intended to be interpreted
>   >> case-sensitively?
>   >
>   > Yes.  I think this is implied but the grammar style Jeff using, but it
>   > might be worth noting for us non-ABNF experts.
> Yes, quoted strings in the ABNF are case-insensitive by default. I can add some
> notes wrt ABNF details.

notes added in -06.

> I'm also thinking we ought to ref draft-ietf-httpbis-p1-messaging-08 & rfc5234
> rather than rfc2616 wrt ABNF as the former is getting close to last call.

added a TODO for this.

>   >> [Section 5.1: Syntax] What should be done if the server has multiple
>   >> Strict-Transport-Security response header fields of different values?
>   >
>   > My opinion is we should honor the most recently received header, both
>   > within a request and between requests.
> agreed. i.e. in a given response, first occurance wins.

well, what I said wrt "first occurrence wins" of course did not agree with what
Adam had said wrt "honor the most recently received header", doh.

But, given recent list discussion wrt multiply-occurring header fields, I put a
TODO wrt this in -06 for now.

> across received responses for a given STS server, most recently received header
> wins.

The spec essentially already says this, but I'll enhance and reply to Sid
Stamm's message to list wrt this.

>   >> [Section 6.1: HTTP-over-Secure-Transport Request Type] Why must the server
>   >> include this header on every response?  This seems likely to prove
>   >> prohibitively difficult across, say, Akamai load balancers for images, etc.
>   >> What happens if the server fails to include the response header on a given
>   >> response?
>   >
>   > I think that's a server conformance requirement.  The UA conformance
>   > requirements are set up so that this doesn't matter too much.  As long
>   > as you get your entry in the STS cache, you'll be fine.
> so this is a good point it seems. Given the UA behaivor, the server /can/ be
> more relaxed. I'll think about how to describe this in that section. Perhaps
> changing the MUST to a SHOULD, and explaining the ramifications of not
> returning STS on every response will do it.

fixed in section 6.1 in -06

>   >> [Section 6.2] A STS Server must not include the Strict-Transport-Security
>   >> HTTP Response Header in HTTP responses conveyed over a non-secure
>   >> transport.  Why not?  It seems harmless to include if the UA doesn't 
>   >> respect it.
>   >
>   > Again, this is a server conformance requirement that doesn't affect
>   > UAs.  It doesn't make sense to send the header here.  We might as well
>   > prohibit servers from sending it.
> well, there's security considerations here. If the STS header is conveyed also
> over insecure transport, then it is possible an attacker can turn off STS
> policy for a victim site.

big doh on my part. The UA only pays attention to STS headers received over
secure transport.

> There's also the desire to avoid DoS attacks where an attacker sets STS for a
> site that's available only (or for critical pieces) only insecurely (HTTP/TCP).

another doh. this isn't relevant to EricL's question above because the UA will
ignore STS headers delivered insecurely.

I've left the MUST NOT in section 6.2 in -06.

>   >> [Section 7.1] What if the STS response header is present but contains no
>   >> tokens?  7.1 suggests that the header alone indicates an STS server.
>   >
>   > That sounds like a bug.  An empty header should be a no-op.
> agreed.

fixed in -06 by having section 7.1 refer to section 5, wherein section 5.1
clarifies that an STS header as defined by the ABNF grammar must have at least
a max-age directive with at least a single-digit value for delta-seconds.

>   >> Other thoughts: Should STS offer a flag such that all cookies received 
>   >> from the STS server would be automatically upgraded to "SECURE" cookies?
>   >
>   > I think this is a good idea for an new token in a future version.  I'm
>   > not sure whether Jeff has updated the grammar in the spec yet,
> I will in the next spec version, per..
> more flexible ABNF for STS?
> http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1185.html

Revised, extensible ABNF grammar is in -06, based on HTTPbis grammar.

In reply to:
Re: Feedback on the Strict-Transport-Security specification (part 2)

=JeffH replied:
 >   Adam replied:
 >   > EricLaw had said:
>> [Section 2.2: Policy Summary] terminates, without user recourse, any
>> secure transport connection attempts upon any and all errors. I'm not
>> convinced that any and all is the right way to go here. Shouldn't this
>> spec call out each certificate and certificate chain error? Otherwise,
>> should I consider the failure in a different protocol level (e.g. gateway
>> or DNS hiccup) as a fatal error?
> Good question. What is meant here is "any and all secure transport errors".
> I used "any and all" because e.g. TLS has some error alerts that aren't by
> default fatal -- i.e. its various cert errors.
> I'll see about crafting some more explicit language.

done in sec 2.2 in -06.

>   > [Section 4: Terminology] The production of the "Effective Request URI" omits
>   >  the protocol scheme.  I assume this was inadvertent and that the protocol
>   > scheme was meant to be included.
> By "production" I'm assuming you mean "definition".  Yes, the definition in
> Section 4 for "Effective Request URI" (ERU) is vague wrt scheme, and also about
> the details of how the server would go about constructing an ERU in the case
> where the Request-line header field contains just and abs-path value, and the
> Host header field contains the authority. I was thinking that we wouldn't need
> to spec the particulars on constructing an ERU in that case in this spec. (do
> we need to?)

I went ahead and added a new subsection (6.2.1) detailing how the server does this.

>   > [Section 6.2] I'm not sure why the spec contains the confusing terminology
>   > "HTTP-over-Secure-Transport" whilst simultaneously demanding that various
>   > URLs be converted to specifically "HTTPS", which would preclude the
>   > flexibility allowed by the more awkward terminology?
> I don't think there is a conflict here, but we could perhaps explain it better.
> We want to leave the door open to having HTTP mapped onto various secure
> transports, which at this time would all be signified by the "https" scheme.
> E.g. today's browsers typically offer a selection between SSLv2, v3, and TLS.
> So if one configs one's browser to use only SSLv2 (for whatever reason), then
> that's what it uses when it attempts a "load" of a URI having a "https" scheme.

I attempted to address the above in -06 via various clarifications scattered in 
section 6 and others.

In reply to:
Re: STS user-agent processing and new max-age values

 > =JeffH replied:
 >  Sid Stamm said:
>  > Section 7.1 of the STS spec[0] describes that when a known STS server
>  > sends a new STS header, the UA must update the cached information
>  > about the server.   Some web Mozilla web developers interested in STS
>  > are concerned that it is not clear enough how UAs will behave when the
>  > same STS header is sent for every request -- they are in particular
>  > concerned that it may not be obvious to some spec readers that the
>  > cached data is "time-received + max-age" and not just the value of
>  > max-age.   It currently reads:
>  >
>  > "Update its cached information for the Known STS Server if the max-age
>  > and/or includeSubDomains header field value tokens are conveying
>  > information different than that already held by the UA."
>  >
>  > Would it be possible/helpful to clarify this a bit,
> Yes, it is of course possible to clarify  :)   will do so in -06.
> I note that the definition of max-age in sec 5.1 needs work also.
>  > by mentioning that
>  > the updated cached data includes any expiration times calculated based
>  > on max-age *and* receipt time of the HTTP header?  This would
>  > eliminate any possible confusion about max-age being a time-to-live,
>  > not an expiration time.
> overall I think the right thing to do is clarify that max-age stipulates simply 
> a cache-entry-time-to-live-after-STS-header-receipt. Perhaps also mention in 
> section 10 UA advice that any timestamps derived from received max-age values 
> may require consistent updating.

addressed in -06 in sections 5.1, 7.1, and 10. Please review.

Received on Friday, 18 December 2009 22:44:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:17 UTC