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

["Eric Lawrence" <[e-mail]>]

Hi, Barry--

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.

-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 
Gondrom ; Yoav Nir ; [e-mail] ; [e-mail]
Subject: Re: [Technical Errata Reported] RFC6797 (4075)

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
<[e-mail]> 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 <[e-mail]>
>
> 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
>