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

[Barry Leiba <[e-mail]>]

> 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 ; [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
>>
>