Subject: Re: [websec] [Technical Errata Reported] RFC6797 (4075)

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Aug 2014 15:11:44 -0400

Eric, thanks for the report.

Errata are errors in the text that would have been fixed at
publication time, had they been caught.

Isn't this a change request, rather than an errata report?

Barry, Applications AD

On Fri, Aug 8, 2014 at 3:05 PM, RFC Errata System
<[email-masked]> wrote:
> The following errata report has been submitted for RFC6797,
> "HTTP Strict Transport Security (HSTS)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6797&eid=4075
>
> --------------------------------------
> Type: Technical
> Reported by: Eric Lawrence <[email-masked]>
>
> Section: 14
>
> Original Text
> -------------
>    Without the "includeSubDomains" directive, HSTS is unable to protect
>    such Secure-flagged domain cookies.
>
> Corrected Text
> --------------
>    Without the "includeSubDomains" directive, HSTS is unable to protect
>    such Secure-flagged domain cookies.
>
>    Even with the "includeSubDomains" directive, the unavailability of
>    an "includeParent" directive means that an Active MITM attacker can
>    perform a cookie-injection attack against an otherwise
>    HSTS-protected victim domain.
>
>    Consider the following scenario:
>
>     The user visits https://sub.example.com and gets a HSTS policy with
>     includeSubdomains set. All subsequent navigations to
>     sub.example.com and its subdomains will be secure.
>
>     An attacker causes the victim's browser to navigate to
>     http://example.com. Because the HSTS policy applies only to
>     sub.example.com and its superdomain matches, this insecure
>     navigation is not blocked by the user agent.
>
>     The attacker intercepts this insecure request and returns a
>     response that sets a cookie on the entire domain tree using a
>     Set-Cookie header.
>
>     All subsequent requests to sub.example.com carry the injected
>     cookie, despite the use of HSTS.
>
> Notes
> -----
> To mitigate this attack, HSTS-protected websites should perform a background fetch of a resource at the first-level domain. This resource should carry a HSTS header that will apply to the entire domain and all subdomains.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6797 (draft-ietf-websec-strict-transport-sec-14)
> --------------------------------------
> Title               : HTTP Strict Transport Security (HSTS)
> Publication Date    : November 2012
> Author(s)           : J. Hodges, C. Jackson, A. Barth
> Category            : PROPOSED STANDARD
> Source              : Web Security
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Aug 2014 15:54:14 -0400

> I'm afraid I'm only a consumer of RFCs and thus I'm not sure I understand
> the distinction here. To me, it seems that the RFC's threat model is
> incomplete.

Perhaps it is, but the distinction is about whether an error was made
in writing the document, or whether there's a flaw in the protocol, an
issue that wasn't considered in the discussion, or the like.

The sentence you're addressing is entirely consistent with the rest of
Section 14.4, and doesn't look like "errata" to me.  It's quite
possible that the working group blew it and should have thought about
things differently.  It's possible that someone should write an update
to RFC 6797 to correct it, and that your input would be useful.

But you're asking the websec working group to consider an update, not
making an errata report, as I see it.

Does anyone from websec have a comment on this?

Barry

> -----Original Message----- From: Barry Leiba
> Sent: Friday, August 8, 2014 2:11 PM
> To: RFC Errata System
> Cc: Jeff Hodges ; Collin Jackson ; Adam Barth ; Pete Resnick ; Tobias
> Gondrom ; Yoav Nir ; [email-masked] ; [email-masked]
> Subject: Re: [Technical Errata Reported] RFC6797 (4075)
>
>
>> To mitigate this attack, HSTS-protected websites should perform a
>> background fetch of a resource at the first-level domain. This resource
>> should carry a HSTS header that will apply to the entire domain and all
>> subdomains.
>>
>> Instructions:
>> -------------

---

From: Yoav Nir <[email-masked]>
Date: Sat, 9 Aug 2014 00:16:30 +0300

> Does anyone from websec have a comment on this?

Hi Barry.

Reading this, it doesn’t look like an error in the document, but as an attack that the group may not have considered, which HSTS may not protect. If this is indeed valid, and if this had been caught in IETF last call or IESG review, this would probably have been sent back to the working group to complete.

Eric: I’m trying to understand the issue, so please see the below and tell me if I understood it correctly. 

Suppose we set up secure.tools.ietf.org and a sub-domain of tools.ietf.org and set HSTS on that domain (but not on tools.ietf.org, which is available in HTTP)
I browse http://tools.ietf.org. Because I’m not using HTTPS, an attacker intercepts the connection and injects a cookie for all subdomain (Path=/; Domain=tools.ietf.org). 
My next connection to https://secure.tools.ietf.org will send this cookie.

Did I get this correctly?

So my first reaction was “No way. You can’t set a Secure cookie over an HTTP connection, can you?  Just like you can’t set HSTS over an HTTP connection.” So I went to find where in RFC 6265 it says that. So of course it doesn’t.  Googling it shows that I’m not the first to wonder about that. In anyone has some insight about this, I’d be glad to know. Is it just that cookies have always worked like this, so we’re not changing it now?

Unless I’m missing something, this could be a real problem, and there are several ways to mitigate it. Any of them requires a new document that either replaces 6797 or updates it ( I can see this solved with a 2-page + boilerplate document). But I don’t think an errata report is the way to go on this.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sat, 9 Aug 2014 01:06:23 +0300

Thanks, Eric

This does look to me like content for an update RFC (with a name like “secure practices of using HSTS in the presence of subdomains”).

I’m not sure how high in the DNS hierarchy you would wish to go.

For secure.tools.ietf.org, it makes sense to check tools.ietf.org and ietf.org.  That also works for .com sites. But in some countries they have their national TLS plus another for commercial/organization. So the top company/organizational domain would be something like somecorp.co.uk or someorg.org.il.  There would be no point in checking for HSTS at co.uk.  Maybe there are rules for this.

Yoav

On Aug 9, 2014, at 12:52 AM, Eric Lawrence <[email-masked]> wrote:

> Hi, Yoav--
> 
> Ivan Ristic's new "Bulletproof SSL and TLS" covers "Cookie Manipulation Attacks" quite nicely.  As he explains well, a serious limitation with HTTP cookies is that they do not carry their metadata when resent to the server, so a secure cookie set by "secure.tools.ietf.org" is, upon receipt by the server in a request's Cookie header, indistinguishable from a insecure cookie of the same name set by "tools.ietf.org". The cookie does not convey the origin from which it was set.
> 
> RFC6797 Section 14 notes that HSTS's includeSubdomains feature blocks a similar problem (namely, an insecure cookie set by http://sub.secure.tools.ietf.org could be set against its parent secure.tools.ietf.org). However, because includeSubdomains only applies to sub-domains, rather than parent-domains, this protection is insufficient to address cookie injection attacks against a parent domain.
> 
> It's hard to argue that this limitation is a flaw in HSTS (because the alternative would be to permit a subdomain to define a HSTS policy for its parent). However, because it is a threat against a site that is otherwise protected via HSTS, I would suggest that there should be implementation guidance of the form: "Any page secured by HSTS that is at a third-level-effective-domain (www.privatedomain.etld) or lower in the DNS hierarchy should include a resource reference to the parent privatedomain (e.g. https://privatedomain.etld/1x1.gif) such that the dereferencing of that resource will provide the UA the opportunity to store a HSTS policy that will protect the entire privatedomain tree."
> 
> -Eric
> 
> -----Original Message----- From: Yoav Nir
> Sent: Friday, August 8, 2014 4:16 PM
> To: Eric Lawrence ; Barry Leiba
> Cc: RFC Errata System ; Jeff Hodges ; Collin Jackson ; Adam Barth ; Pete Resnick ; Tobias Gondrom ; [email-masked]

---

From: Chris Palmer <[email-masked]>
Date: Fri, 8 Aug 2014 16:44:36 -0700

> For secure.tools.ietf.org, it makes sense to check tools.ietf.org and ietf.org.  That also works for .com sites. But in some countries they have their national TLS plus another for commercial/organ…

https://publicsuffix.org/

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Aug 2014 20:06:27 -0400

And now we're in the DBOUND territory.  Talk with Andrew Sullivan.

I will mark this errata report as Rejected, and you can drop the RFC Editor
off the CC and continue this conversation in the we sec WG.

Barry

On Friday, August 8, 2014, Yoav Nir <[email-masked]> wrote:

> Thanks, Eric
>
> This does look to me like content for an update RFC (with a name like
> "secure practices of using HSTS in the presence of subdomains").
>
> I'm not sure how high in the DNS hierarchy you would wish to go.
>
> For secure.tools.ietf.org, it makes sense to check tools.ietf.org and
> ietf.org.  That also works for .com sites. But in some countries they
> have their national TLS plus another for commercial/organization. So the
> top company/organizational domain would be something like somecorp.co.uk
> or someorg.org.il.  There would be no point in checking for HSTS at co.uk.
>  Maybe there are rules for this.
>
> Yoav
>
> On Aug 9, 2014, at 12:52 AM, Eric Lawrence <[email-masked]
> <javascript:;>> wrote:
>
> > Hi, Yoav--
> >
> > Ivan Ristic's new "Bulletproof SSL and TLS" covers "Cookie Manipulation
> Attacks" quite nicely.  As he explains well, a serious limitation with HTTP
> cookies is that they do not carry their metadata when resent to the server,
> so a secure cookie set by "secure.tools.ietf.org" is, upon receipt by the
> server in a request's Cookie header, indistinguishable from a insecure
> cookie of the same name set by "tools.ietf.org". The cookie does not
> convey the origin from which it was set.
> >
> > RFC6797 Section 14 notes that HSTS's includeSubdomains feature blocks a
> similar problem (namely, an insecure cookie set by
> http://sub.secure.tools.ietf.org could be set against its parent
> secure.tools.ietf.org). However, because includeSubdomains only applies
> to sub-domains, rather than parent-domains, this protection is insufficient
> to address cookie injection attacks against a parent domain.
> >
> > It's hard to argue that this limitation is a flaw in HSTS (because the
> alternative would be to permit a subdomain to define a HSTS policy for its
> parent). However, because it is a threat against a site that is otherwise
> protected via HSTS, I would suggest that there should be implementation
> guidance of the form: "Any page secured by HSTS that is at a
> third-level-effective-domain (www.privatedomain.etld) or lower in the DNS
> hierarchy should include a resource reference to the parent privatedomain
> (e.g. https://privatedomain.etld/1x1.gif) such that the dereferencing of
> that resource will provide the UA the opportunity to store a HSTS policy
> that will protect the entire privatedomain tree."
> >
> > -Eric
> >
> > Cc: RFC Errata System ; Jeff Hodges ; Collin Jackson ; Adam Barth ; Pete
> Resnick ; Tobias Gondrom ; [email-masked] <javascript:;>
> > On Aug 8, 2014, at 10:54 PM, Barry Leiba <[email-masked]
> <javascript:;>> wrote:
> >
> > Reading this, it doesn't look like an error in the document, but as an
> attack that the group may not have considered, which HSTS may not protect.
> If this is indeed valid, and if this had been caught in IETF last call or
> IESG review, this would probably have been sent back to the working group
> to complete.
> >
> > Eric: I'm trying to understand the issue, so please see the below and
> tell me if I understood it correctly.
> >
> > Suppose we set up secure.tools.ietf.org and a sub-domain of
> tools.ietf.org and set HSTS on that domain (but not on tools.ietf.org,
> which is available in HTTP)
> > I browse http://tools.ietf.org. Because I'm not using HTTPS, an
> attacker intercepts the connection and injects a cookie for all subdomain
> (Path=/; Domain=tools.ietf.org).
> > So my first reaction was "No way. You can't set a Secure cookie over an
> HTTP connection, can you?  Just like you can't set HSTS over an HTTP
> connection." So I went to find where in RFC 6265 it says that. So of course
> it doesn't. Googling it shows that I'm not the first to wonder about that.
> In anyone has some insight about this, I'd be glad to know. Is it just that
> cookies have always worked like this, so we're not changing it now?
> >
> > Unless I'm missing something, this could be a real problem, and there
> are several ways to mitigate it. Any of them requires a new document that
> either replaces 6797 or updates it ( I can see this solved with a 2-page +
> boilerplate document). But I don't think an errata report is the way to go
> on this.
> >
> > Yoav
> >
> >
>
>

---

From: RFC Errata System <[email-masked]>
Date: Fri, 8 Aug 2014 12:05:33 -0700 (PDT)

Section: 14

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

---

From: "Eric Lawrence" <[email-masked]>
Date: Fri, 8 Aug 2014 16:52:10 -0500

Hi, Yoav--

Ivan Ristic's new "Bulletproof SSL and TLS" covers "Cookie Manipulation 
Attacks" quite nicely.  As he explains well, a serious limitation with HTTP 
cookies is that they do not carry their metadata when resent to the server, 
so a secure cookie set by "secure.tools.ietf.org" is, upon receipt by the 
server in a request's Cookie header, indistinguishable from a insecure 
cookie of the same name set by "tools.ietf.org". The cookie does not convey 
the origin from which it was set.

RFC6797 Section 14 notes that HSTS's includeSubdomains feature blocks a 
similar problem (namely, an insecure cookie set by 
http://sub.secure.tools.ietf.org could be set against its parent 
secure.tools.ietf.org). However, because includeSubdomains only applies to 
sub-domains, rather than parent-domains, this protection is insufficient to 
address cookie injection attacks against a parent domain.

-Eric

-----Original Message----- 
From: Yoav Nir
Sent: Friday, August 8, 2014 4:16 PM
To: Eric Lawrence ; Barry Leiba
Cc: RFC Errata System ; Jeff Hodges ; Collin Jackson ; Adam Barth ; Pete 
Resnick ; Tobias Gondrom ; [email-masked]
Subject: Re: [Technical Errata Reported] RFC6797 (4075)

Hi Barry.

Reading this, it doesn’t look like an error in the document, but as an 
attack that the group may not have considered, which HSTS may not protect. 
If this is indeed valid, and if this had been caught in IETF last call or 
IESG review, this would probably have been sent back to the working group to 
complete.

Eric: I’m trying to understand the issue, so please see the below and tell 
me if I understood it correctly.

Suppose we set up secure.tools.ietf.org and a sub-domain of tools.ietf.org 
and set HSTS on that domain (but not on tools.ietf.org, which is available 
in HTTP)
I browse http://tools.ietf.org. Because I’m not using HTTPS, an attacker 
intercepts the connection and injects a cookie for all subdomain (Path=/; 
Domain=tools.ietf.org).
My next connection to https://secure.tools.ietf.org will send this cookie.

So my first reaction was “No way. You can’t set a Secure cookie over an HTTP 
connection, can you?  Just like you can’t set HSTS over an HTTP connection.” 
So I went to find where in RFC 6265 it says that. So of course it doesn’t. 
Googling it shows that I’m not the first to wonder about that. In anyone has 
some insight about this, I’d be glad to know. Is it just that cookies have 
always worked like this, so we’re not changing it now?

Unless I’m missing something, this could be a real problem, and there are 
several ways to mitigate it. Any of them requires a new document that either 
replaces 6797 or updates it ( I can see this solved with a 2-page + 
boilerplate document). But I don’t think an errata report is the way to go 
on this.

Yoav

---

From: "Eric Lawrence" <[email-masked]>
Date: Fri, 8 Aug 2014 14:32:52 -0500

Hi, Barry--

-Eric

-----Original Message----- 
From: Barry Leiba
Sent: Friday, August 8, 2014 2:11 PM
To: RFC Errata System
Cc: Jeff Hodges ; Collin Jackson ; Adam Barth ; Pete Resnick ; Tobias 

Barry, Applications AD

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 10 Aug 2014 12:28:00 +0100

Thanks.

I agree, this is an "update" and not an "errata".

However, am not sure how to best retain this information:
Because this is a good point for a best practice.
And be it only in advising the best practice when using HSTS, like
simply including one link to the parent https://example.com to avoid
having unprotected parent-domains.

For errata we have this nice mechanism to keep errata proposals, while
for updates, I think we don't.

Best regards, Tobias

---

From: Yoav Nir <[email-masked]>
Date: Sun, 10 Aug 2014 14:40:59 +0300

> having unprotected parent-domains.

Well, if we could talk Eric into writing a draft…

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 10 Aug 2014 12:48:08 +0100

> Well, if we could talk Eric into writing a draft…

In theory we/he could do an RFC6797bis for this.
And as the change is only small, the review period should also be
possible to keep contained.

On the other hand, personally, I am not sure a new RFC would really be
necessary, because it seems to me that with proper best practices
(declare HSTS Policy at their top-level domain + frequently include the
top-level, to make sure it's HSTS is still renewed) this can be solved
and there would be no change on the wire.

Best regards, Tobias

---

From: Yoav Nir <[email-masked]>
Date: Sun, 10 Aug 2014 14:52:58 +0300

On Aug 10, 2014, at 2:48 PM, Tobias Gondrom <[email-masked]> wrote:

> And as the change is only small, the review period should also be possible to keep contained. 
> 
> On the other hand, personally, I am not sure a new RFC would really be necessary, because it seems to me that with proper best practices (declare HSTS Policy at their top-level domain + frequently include the top-level, to make sure it's HSTS is still renewed) this can be solved and there would be no change on the wire. 

So we get an Informational draft called “best practices in using HSTS”. 2 pages long unless we rathole and add lots of stuff.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 10 Aug 2014 11:02:02 -0400

> Well, if we could talk Eric into writing a draft...
...
> So we get an Informational draft called "best practices in using HSTS". 2
> pages long unless we rathole and add lots of stuff.

That absolutely seems the best approach, and have it "update" 6797.  I
would love it if Eric would be a co-author, and I think we can keep
the working group going long enough to do this.

To Tobias's more general question of where we keep track of these
sorts of things when we don't have a working group to pick it up and
go with it:  Yes, that's something we've been discussing.  If we have
a former working group to work from, there's a wiki on tools.ietf.org
(websec's is at <http://trac.tools.ietf.org/wg/websec/trac/wiki>, and
it's entirely unused, but some working groups do use theirs).  I've
been suggesting that we make a habit of keeping updates, change
requests, follow-on notes, and other non-errata things there, on the
appropriate current or former WG wiki.  If there's no obvious WG, we
can use the appsawg wiki at
<http://trac.tools.ietf.org/wg/appsawg/trac/wiki> for App Area stuff.
The only bad thing about that is that there's no pointer from the RFC
to the appropriate wiki, and we've talked about establishing some sort
of per-RFC wiki also, or maybe just a per-RFC pointer to a wiki.

Barry

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 10 Aug 2014 20:04:40 +0100

> of per-RFC wiki also, or maybe just a per-RFC pointer to a wiki.

I agree.

The question is, does Eric (and maybe Jeff or anybody else) want to do a
small update informational RFC?

Best regards, Tobias

Ps.: and thanks for the clarification about the Wiki.