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

Yoav Nir <> Fri, 08 August 2014 21:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B57CF1A00D7 for <>; Fri, 8 Aug 2014 14:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h-OcjEFOvG7V for <>; Fri, 8 Aug 2014 14:16:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FA041A026C for <>; Fri, 8 Aug 2014 14:16:32 -0700 (PDT)
Received: by with SMTP id n3so3087866wiv.4 for <>; Fri, 08 Aug 2014 14:16:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=df6RsabIh68EPD8mDHEdNWlZ6O0Zisq8AS7FXOdCVDA=; b=Q4yL4lFB982vTK/l9lNRg79JXJMj8DPniXJ7JcWHIZjxUaHryH50bZFpqJ/7rMinh1 60h6CYBjkGZsE4Z87dYnQKlT1nvvGEzzkydFky6YDHF0S//9CuJ1JIzWpnNt1W9ong4Q Cx66m0NYNUL837PnWYpa5C04lIe/J5q7blYnxH82w1DacJpPP8haSfoc8bHbd+op/pM4 lfI4FTVr8DM9zomFK1g6bko4HmMmqL3225/fv6QL6HUG7GhrqoCWvrMYG5aSM9saQeeF N7x8tXB+OHIJzMJ0SC4X/6/JSQI1wG+mwqvREvvVlaieHUvDNkkOHKLl37msb1EnGkKB sy2A==
X-Received: by with SMTP id lo6mr928156wic.1.1407532591054; Fri, 08 Aug 2014 14:16:31 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id r1sm11115299wia.21.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 14:16:30 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Sat, 09 Aug 2014 00:16:30 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <COL131-DS14E7BAAD30061ECA07D1D5F0EE0@phx.gbl> <>
To: Eric Lawrence <>, Barry Leiba <>
X-Mailer: Apple Mail (2.1878.6)
Cc: Jeff Hodges <>, Pete Resnick <>, "" <>, Collin Jackson <>, RFC Errata System <>
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: Fri, 08 Aug 2014 21:16:35 -0000

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.