Re: [websec] cookie injection attack via superdomain of HSTS Host (was: [Technical Errata Reported] RFC6797 (4075)

=JeffH <> Sat, 09 August 2014 01:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 23B551A02F0 for <>; Fri, 8 Aug 2014 18:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.231
X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GB-hK85v92pf for <>; Fri, 8 Aug 2014 18:01:44 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 673321A02E8 for <>; Fri, 8 Aug 2014 18:01:44 -0700 (PDT)
Received: (qmail 23422 invoked by uid 0); 9 Aug 2014 01:01:40 -0000
Received: from unknown (HELO cmgw3) ( by with SMTP; 9 Aug 2014 01:01:40 -0000
Received: from ([]) by cmgw3 with id cX1Y1o00L2UhLwi01X1bzq; Sat, 09 Aug 2014 01:01:38 -0600
X-Authority-Analysis: v=2.1 cv=DIUcvU9b c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ekOJvlQLSnQA:10 a=OKxkqqKDs78A:10 a=lVB5xtUsM40A:10 a=3NT3xRclEPMA:10 a=8nJEP1OIZ-IA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=vS7MmSmxvPQA:10 a=A1X0JdhQAAAA:8 a=48vgC7mUAAAA:8 a=KPcibb87oZ-6Z4ZuIhcA:9 a=9bFfiOKcGA-NuIkR:21 a=3iHkDXmn6asv3U17:21 a=wPNLvfGTeEIA:10 a=4rq7TwIXcRUA:10 a=lZB815dzVvQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=8/R4oTvpX/Gmtxc6zEzkF7kxdCQcXH9Z64CYGgfezWk=; b=jw6103sw5uz0XfsUAC0cCwp0n7kvuKw1kkLtEjInMD4LLEN0C8ttXYt8Ye8Yup4otboeKgauP+EbMNchXp2/i4putTGNsJVhh7t7IVx4wqoYoK1LBbrb/U+5WKRkWgao;
Received: from [] (port=16681 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1XFv2L-0003Ic-LG; Fri, 08 Aug 2014 19:01:33 -0600
Message-ID: <>
Date: Fri, 08 Aug 2014 18:01:30 -0700
From: =JeffH <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Eric Lawrence <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
Cc: IETF WebSec WG <>
Subject: Re: [websec] cookie injection attack via superdomain of HSTS Host (was: [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: Sat, 09 Aug 2014 01:01:46 -0000

[ trimming to: and cc: as I think most everyone is on websec@ ]

Hi Eric, thanks for submitting this errata.

Barry & everyone: actually, this issue is in S 14 "Security Considerations" 
of RFC6797, and I think Eric is correct that that subsection "14.4. The Need 
for includeSubDomains" is overlooking this detail, and hence is actually an 
errata (more or less).

However, the text I'd use to correct it would be somewhat different than 
Eric's proposed text (tho it'd build on it).

Overall, I think we discussed this aspect of things during our development 
of HSTS and rationale/defense overall amounts to..

1. HSTS Hosts really need to declare HSTS Policy at their top-level domain 
name whether or not they are reachable at other subdomains thereof and 
regardless of whether they employ .  I.e., it's  poor practice to have an 
HSTS Host at yet also answer at 
without also declaring the latter as an HSTS Host.

In terms of there being a policy authority boundary between one's HSTS Host 
and it's immediate superdomain -- eg between and com. -- that 
to some degree is presently addressed by language in RFC6265 section 5.3 
step 5 --- but nominally I think Eric is overall correct and this "cookie 
injection attack via superdomain of HSTS Host" isn't properly discussed in 
RFC6797 and that it would (today) be an issue for example if 
is a distinct entity from, and _is not_ a "public 
suffix". Essentially, i think there's a subtle impedance mismatch between 
HSTS's Storage Model and that of HTTP cookies per RFC6265, and it's arguably 
a spec bug in rfc6797 that it isn't explicitly called out.

Thus Barry is correct that this is treading into "domain boundary" aka 
"domain policy authority" territory <> -- and thus is another 
example of why the latter work is important (several of us, along with 
Andrew Sullivan, are chipping away at it).

Also, there's a recent draft academic paper that's been mentioned on other 
lists that I am going to post a reference to on this list -- it goes into 
HSTS deployment common mistakes as well as best practices and touches on 
issues similar to this.

ah, I see Eric's proposed best practice in his reply to Yoav, and yeah, 
that's one way to address this issue, and could ostensibly be included in a 
spec update -- but the actual errata is the above-noted impedance mismatch 
between cookies' and HSTS's storage models (and also the lack of cookie's 
declaring their originating origin).