On Mon, Aug 20, 2012 at 5:09 PM, Brian Smith <[email protected]> wrote: > Adam Barth wrote: >> The way the implementation in Chrome works is that max-age=0 only >> clears the entry for that particular host name. If there's another >> shorter host name with includeSubdomains, that isn't affected. > > Let me try to clarify with an example, which I think should be explicitly > documented in the spec: > > 1. We visit https://example.com and receive HSTS with max-age=1234567890 ; > includeSubdomains > 2. We visit https://sub.example.com and receive HSTS with max-age=0 > > Now, is sub.example.com HSTS (because it inherits the HSTS setting from > example.com), or is it non-HSTS (because we received a max-age=0 for that > host)?
It is HSTS. Visit (2) would have removed any sub.example.com-specific entries in the HSTS state table, but there were none, so it didn't have any effect on the world. > When we receive a HSTS header from sub.example.com with max-age > 0, then we > will treat the expiration time of sub.example.com to be > MAX(expiration(example.com), expiration(sub.example.com)). A simpler way to think about it is that you keep state for each host. To answer the question of whether a given host is HSTS, you walk the list of subdomains and check their unexpired state. > But, if we receive a HSTS header from sub.example.com with max-age == 0, > there are two possibilities: > > 1. We act consistently with the above case and calculate the HSTS expiration > time of sub.example.com to be: > > MAX(expiration(example.com), expiration(sub.example.com)) > == MAX(expiration(example.com), 0) > == expiration(example.com) > > This means that we would effectively be ignoring the max=age == 0 value > sent by sub.example.com. Correct. > 2. We honor the max-age=0 directive sent by sub.example.com and turn off HSTS > for sub.example.com, but not for example.com. That is, we would treat max-age > == 0 from a subdomain as "do not do includeSubdomains inheritance for this > subdomain." This is not correct. We do "honor" the max-age directive set by sub.example.com by expiring any sub.example.com-specific state. However, sub.example.com is HSTS due to state specific to example.com, which is not expired. > Now, it seems to me that the only reasonable choice is #2, but the spec seems > to imply that we should do #1. Choice #1 seems reasonable to me. > Here's the problematic scenerio: > > 1. We visit https://example.com and get the HSTS header with > includeSubdomains and an (effectively) infinite expiration time. There is no such thing as an infinite expiration time. Let's proceed assuming you mean "one year" rather than infinite. > 2. The owners of example.com decides to turn of HSTS for whatever reason > (perhaps the domain changed owners, or there's a compatibility issue, or > whatever), so they start sending out HSTS with max-age=0 for example.com and > for all the subdomains. That's not a correct way of disabling HSTS after (1). Instead, they need only send out an max-age=0 header for example.com itself. > 3. We visit https://sub.example.com and get the max-age=0 HSTS header. > > If we choose choice #2, we do what the owners of example.com intended, by > treating https://sub.example.com as non-HSTS right away, without ever needing > to visit https://example.com, which we might NEVER do ever again. I mean, it's just guesswork as to what they intend. I can write a similar story in which the intent is the reverse. > If we choose choice #1, we will effectively be making https://sub.example.com > HSTS forever, and the domain owner has no way to help us undo it. They can simply initiate a request to https://example.com/ (e.g., by using an HTTP redirect or an HTML image element) and clear the HSTS state for that host name. Adam _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
