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 On 08/08/14 23:06, Yoav Nir 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 protected]> 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 protected] >> Subject: Re: [Technical Errata Reported] RFC6797 (4075) >> >> >> On Aug 8, 2014, at 10:54 PM, Barry Leiba <[email protected]> wrote: >> >>>> 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? >> 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 >> >> _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
