IETF Logo Mail Archive

Re: [websec] New draft of HTTP header-based public key pinning

Adam Barth <ietf@adambarth.com> Wed, 09 November 2011 17:03 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9AB11E8083 for <websec@ietfa.amsl.com>; Wed, 9 Nov 2011 09:03:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFb+wylShn3v for <websec@ietfa.amsl.com>; Wed, 9 Nov 2011 09:03:53 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59E2221F8C70 for <websec@ietf.org>; Wed, 9 Nov 2011 09:03:53 -0800 (PST)
Received: by iaeo4 with SMTP id o4so2498443iae.31 for <websec@ietf.org>; Wed, 09 Nov 2011 09:03:53 -0800 (PST)
Received: by 10.42.19.195 with SMTP id d3mr3922801icb.21.1320858232981; Wed, 09 Nov 2011 09:03:52 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id l28sm7601277ibc.3.2011.11.09.09.03.50 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 09:03:50 -0800 (PST)
Received: by iaeo4 with SMTP id o4so2498380iae.31 for <websec@ietf.org>; Wed, 09 Nov 2011 09:03:50 -0800 (PST)
Received: by 10.231.73.196 with SMTP id r4mr933426ibj.19.1320858230092; Wed, 09 Nov 2011 09:03:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.50.14 with HTTP; Wed, 9 Nov 2011 09:03:19 -0800 (PST)
In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEBED718198@DEN-MEXMS-001.corp.ebay.com>
References: <CAOuvq21Ne0CWT3Dzn0sutGDBg0K+efZhxmqBZiLuxbO2OwxnFg@mail.gmail.com> <CA+cU71kFFpuooyiBTarvLT3VJigZhW0BgpQi1gMTn7zB=sFh+w@mail.gmail.com> <CAOuvq20uCZsp80yJ6gjeh-AGVswu3GTPuSYYCGyXPWpO-RJpsA@mail.gmail.com> <5EE049BA3C6538409BBE6F1760F328ABEBED718018@DEN-MEXMS-001.corp.ebay.com> <CAJE5ia9Ryjus6Zy38PFffCnGsZHw+byvdTVCi7XmYWUd8rVdTQ@mail.gmail.com> <5EE049BA3C6538409BBE6F1760F328ABEBED718198@DEN-MEXMS-001.corp.ebay.com>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 09 Nov 2011 09:03:19 -0800
Message-ID: <CAJE5ia-RArOM_8my7iZ4ren4vNS-UxE6ugqY5uUkO6c-poTZ+w@mail.gmail.com>
To: "Steingruebl, Andy" <asteingruebl@paypal-inc.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Chris Evans <cevans@google.com>, IETF WebSec WG <websec@ietf.org>, Ian Fette <ifette@google.com>, Wan-Teh Chang <wtc@google.com>
Subject: Re: [websec] New draft of HTTP header-based public key pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2011 17:03:54 -0000

On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy
<asteingruebl@paypal-inc.com> wrote:
>> -----Original Message-----
>> From: Adam Barth [mailto:ietf@adambarth.com]
>> > We battled this problem with HSTS as well.  I think what Mozilla settled on
>> (and I don't remember the Chrome solution) is to use a different storage
>> mechanism when HSTS is *set* during private browsing mode, and clear on
>> exit from private browsing.
>>
>> It's been a while since I wrote that code, but I'm pretty sure that's how it
>> works in Chrome too.  There's a separate memory-only HSTS store that's
>> used for incognito.  That's consistent with how we handle other host-specific
>> data stored by the network layer, such as cookies.
>
> Is this documented anywhere?  Where should it be?  Maybe add a section to the browser security handbook, if nowhere else, so at least we all have it written down what the browsers have implemented?

I don't believe it's documented anywhere.

> And, since we decided these specifics don't belong in the IETF  HSTS spec, where could we document them for real?

Typically, incognito mode hasn't been standardized anywhere.  The
general concept is that it should follow all the other standards, but
act as a short-lived user agent.  For example, you can imagine that
the user agent is created when the user enters incognito and destroyed
when the user leaves incognito.

If we were to standardize the mode, we'd probably do it in a working
group similar to http://www.w3.org/2006/WSC/.  However, I'm not sure
how much interest there is around that task.

Adam

v2.23.0 | Report a Bug | By Email