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

[Adam Barth <[e-mail]>]

On Wed, Nov 9, 2011 at 10:04 AM, Paul Hoffman <[e-mail]> wrote:
> On Nov 9, 2011, at 9:03 AM, Adam Barth wrote:
>> On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy
>> <[e-mail]> wrote:
>>>> -----Original Message-----
>>>> From: Adam Barth [mailto:[e-mail]]
>>>>> 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.
>
> Another option is a short Internet Draft that would become an independent submission RFC that says "here is how a few browser vendors define the problem and solve it, at the time that this is published". That is *exactly* what the independent submission RFCs are good for. No wide IETF review, no need to listen to anyone who thinks you should do it differently; just "here is what we do, and why".

That sounds like a reasonable plan.  Collin Jackson has written up a
detailed analysis of the current state of affairs in this paper:

http://www.collinjackson.com/research/private-browsing.pdf

Adam