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

Tobias Gondrom <> Sun, 10 August 2014 11:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B0FA1A06E0 for <>; Sun, 10 Aug 2014 04:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.969
X-Spam-Status: No, score=-99.969 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F97fLoxPKZ9w for <>; Sun, 10 Aug 2014 04:28:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20EF01A06DD for <>; Sun, 10 Aug 2014 04:28:05 -0700 (PDT)
X-No-Relay: not in my network
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=dlQiQF8H0LA4MTp4fA78E1DfTMt4jSXtcVBqJerrvr+xGEzbPZhnbAv/mPLN8x2nNn7zjxYbpugVOIkaqnuL4eSo3LMeMkIgsrKSb4STLkG69XHQYwb8bk3y6SOfr7hG12OtblzfBi0tsUD6Qn5VzDAh7r04B9zaD6GH2x63l04=; h=X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
Received: from [] ( []) by (Postfix) with ESMTPSA id D32EB1539004F; Sun, 10 Aug 2014 13:28:01 +0200 (CEST)
Message-ID: <>
Date: Sun, 10 Aug 2014 12:28:00 +0100
From: Tobias Gondrom <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <COL131-DS14E7BAAD30061ECA07D1D5F0EE0@phx.gbl> <> <> <COL131-DS10F844603100882CC36852F0EE0@phx.gbl> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Subject: Re: [websec] [Technical Errata Reported] RFC6797 (4075)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Aug 2014 11:28:08 -0000


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 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, it makes sense to check and  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 or  There would be no point in checking for HSTS at  Maybe there are rules for this.
> Yoav
> On Aug 9, 2014, at 12:52 AM, Eric Lawrence <> 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 "" is, upon receipt by the server in a request's Cookie header, indistinguishable from a insecure cookie of the same name set by "". 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 could be set against its parent 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 ;
>> Subject: Re: [Technical Errata Reported] RFC6797 (4075)
>> On Aug 8, 2014, at 10:54 PM, Barry Leiba <> 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 and a sub-domain of and set HSTS on that domain (but not on, which is available in HTTP)
>> I browse Because I’m not using HTTPS, an attacker intercepts the connection and injects a cookie for all subdomain (Path=/;
>> My next connection to 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