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

[Ryan Sleevi]

>  On Wed, Nov 9, 2011 at 1:45 PM, Julian Reschke 
>  wrote:
>
> >> Could anyone propose exact ABNF grammar that is acceptable given the
> >> above constraints? Currently, I have it as:
> >> ...
> >
> > I made a proposal; is there something specific you didn't like?
>
>  Your proposal is fine — thank you! It's just that I am almost
>  certainly going to write the ABNF wrong, and then we'll have a whole
>  long thread about that. :)

While revisiting the ABNF, should "fp-type" be made into 'token' instead
of an explicit list ( "sha1" / "sha256" )? Rather than dealing with the
minimal set of "must-implements" in the grammar, define it in the text for
processing rules. This is similar to the conversation that happened for
the STS grammar rules.

I'm just wondering how legacy parsers would be expected to handle future
versions with say, SHA-3. Defining it as a token would at least allow it
to be syntactically valid and parsed, even if fingerprints of that type
are not understood/supported.



___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Chris Palmer]

On Wed, Nov 9, 2011 at 1:45 PM, Julian Reschke  wrote:

>> Could anyone propose exact ABNF grammar that is acceptable given the
>> above constraints? Currently, I have it as:
>> ...
>
> I made a proposal; is there something specific you didn't like?

Your proposal is fine — thank you! It's just that I am almost
certainly going to write the ABNF wrong, and then we'll have a whole
long thread about that. :)
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2011-11-09 22:28, Chris Palmer wrote:

From what I can gather, there is a thing called "header field

recombination", in which a proxy or something collapses two or more
headers of the same type into one, and joins their values with a ",".
Therefore, I should not list multiple pins separated with a "," in the
PKP header. OK.

(This is new to me. Are there MITMs that really do this? Why?)


I know of *libraries* that do this, and I wouldn't rule out 
intermediates using those.



(FWIW, the only relevant hit in the first page of Google results for [
header field recombination ] is
http://svn.tools.ietf.org/wg/httpbis/trac/ticket/231.)


   Public-Key-Pins: max-age=31536000;
   pins-sha1=4n972HfV354KP560yw4uqe/baXc=;
   pins-sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=


OK. I suppose now we might as well get rid of the "pins-" too.


Unless you need an extension point for other parameters.


Finally, allow quoted-string notation,

   Public-Key-Pins: max-age=31536000;
   pins-sha1="4n972HfV354KP560yw4uqe/baXc=";
   pins-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="

so that characters not allowed (such as "/") in HTTP tokens work.


But if "/" is not allowed in HTTP tokens, we have to require
quoted-string notation, and not merely allow it. Right?


Indeed. But they are used in base64, unless you switch to 
.



Could anyone propose exact ABNF grammar that is acceptable given the
above constraints? Currently, I have it as:
...


I made a proposal; is there something specific you didn't like?

Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Chris Palmer]

From what I can gather, there is a thing called "header field
recombination", in which a proxy or something collapses two or more
headers of the same type into one, and joins their values with a ",".
Therefore, I should not list multiple pins separated with a "," in the
PKP header. OK.

(This is new to me. Are there MITMs that really do this? Why?)

(FWIW, the only relevant hit in the first page of Google results for [
header field recombination ] is
http://svn.tools.ietf.org/wg/httpbis/trac/ticket/231.)

>   Public-Key-Pins: max-age=31536000;
>       pins-sha1=4n972HfV354KP560yw4uqe/baXc=;
>       pins-sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=

OK. I suppose now we might as well get rid of the "pins-" too.

> Finally, allow quoted-string notation,
>
>   Public-Key-Pins: max-age=31536000;
>       pins-sha1="4n972HfV354KP560yw4uqe/baXc=";
>       pins-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="
>
> so that characters not allowed (such as "/") in HTTP tokens work.

But if "/" is not allowed in HTTP tokens, we have to require
quoted-string notation, and not merely allow it. Right?

Could anyone propose exact ABNF grammar that is acceptable given the
above constraints? Currently, I have it as:

Public-Key-Pins = "Public-Key-Pins" ":" LWS directives

directives  = max-age LWS ";" LWS pins
  / pins LWS ";" LWS max-age

max-age = "max-age" LWS "=" LWS delta-seconds

pins= "pins" LWS "=" LWS fingerprints

fingerprints= fingerprint
  / fingerprint "," fingerprints

fingerprint = fp-type "-" base64-digits

fp-type = "sha1"
  / "sha256"

Thanks!
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2011-11-09 21:09, Chris Palmer wrote:

On Wed, Nov 9, 2011 at 12:34 AM, Julian Reschke  wrote:




So decide whether you want to allow multiple header fields (in which case
you should use the ABNF list notation used in 2616/HTTPbis), *or* define the
syntax so that a "," introduced by header field recombination can be
detected by recipients.


I'm sorry, I don't know what you mean by "a ',' introduced by header
field recombination".





What grammar do you prefer?


I would recommend a syntax that uses a single delimiter. If you use ";", 
you'd be able to detect the case mentioned above. If you use ",", you 
could support multiple header fields (if this is desired).


By using both however, you gain nothing (IHMO), and create potential 
problems.


Let's assume it's ";". In that case I would write:

directives  = max-age LWS *( ";" LWS [ fingerprint ] )

thus require max-age to be always first (your grammar allows it at the 
beginning and at the end, but not inbetween; this is likely to cause 
confusion.


Then make fingerprint a proper name/value pair, as in other HTTP 
parameters, and put the name of the hash into the parameter name. So 
instead of


   Public-Key-Pins: max-age=31536000;
   pins=sha1-4n972HfV354KP560yw4uqe/baXc=,
   sha256-LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=

you'd have

   Public-Key-Pins: max-age=31536000;
   pins-sha1=4n972HfV354KP560yw4uqe/baXc=;
   pins-sha256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=

Finally, allow quoted-string notation,

   Public-Key-Pins: max-age=31536000;
   pins-sha1="4n972HfV354KP560yw4uqe/baXc=";
   pins-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="

so that characters not allowed (such as "/") in HTTP tokens work.

Best regards, Julian


Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Chris Palmer]

On Wed, Nov 9, 2011 at 12:34 AM, Julian Reschke  wrote:

> 
>
> So decide whether you want to allow multiple header fields (in which case
> you should use the ABNF list notation used in 2616/HTTPbis), *or* define the
> syntax so that a "," introduced by header field recombination can be
> detected by recipients.

I'm sorry, I don't know what you mean by "a ',' introduced by header
field recombination".

What grammar do you prefer?
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Adam Barth]

On Wed, Nov 9, 2011 at 10:04 AM, Paul Hoffman  wrote:
> On Nov 9, 2011, at 9:03 AM, Adam Barth wrote:
>> On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy
>>  wrote:
 -Original Message-
 From: Adam Barth [mailto:i...@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.
>
> 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
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] font sniffing

[Adam Barth]

On Wed, Nov 9, 2011 at 9:39 AM, Peter Saint-Andre  wrote:
> On 11/9/11 10:30 AM, Adam Barth wrote:
>>
>> On Wed, Nov 9, 2011 at 9:29 AM, Peter Saint-Andre
>>  wrote:
>>>
>>> On 10/25/11 12:42 AM, Tobias Gondrom wrote:

 On 25/10/11 07:30, "Martin J. Dürst" wrote:
>
> On 2011/10/25 11:34, Anne van Kesteren wrote:
>>
>> On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst
>>   wrote:

 But who is at fault is not what we are interested in here I think.
 We
 are interested in defining when implementations have to sniff. They
 very
 much have to sniff for fonts.
>>>
>>> Yes. If somebody has enough energy, it would still make sense to
>>> register font types.
>>
>> Because..?
>
> - Font formats, as well as other Mime types, are not only used by Web
> browsers.
> - There may be new formats, for which no sniffing is done yet.
> - Servers may prefer to declare what they are sending out rather than
> to be silent about it, even if not all clients use that information.
> - Once we have registered types, sniffing could in the long term maybe
> even go away.
>
> Regards,   Martin.

 +1 for that.
>>>
>>> Based on discussion here and at the W3C TPAC last week, I raised this
>>> issue
>>> on the apps-discuss list:
>>>
>>> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html
>>>
>>> The immediate reaction was: "do you mean fonts or typefaces?"
>>>
>>> Before taking on this work, it would be helpful to understand exactly
>>> what
>>> typographic entities are being sent around by browsers and other
>>> applications.
>>
>> Mechanically, resource representations that might get shoved into
>> @font-face rules.
>
> Based on Anne's previous message to this list [1], it seems that we're
> actually talking about font representation formats (his examples are
> TrueType Collection, OpenType, TrueType, and Web Open Font Format) instead
> of particular fonts (e.g., "12pt Georgia Bold Italic") or typefaces (e.g.,
> "Georgia").
>
> Correct?

Yep.

Adam
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Paul Hoffman]

On Nov 9, 2011, at 9:03 AM, Adam Barth wrote:

> On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy
>  wrote:
>>> -Original Message-
>>> From: Adam Barth [mailto:i...@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.

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".

--Paul Hoffman

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] font sniffing

[Peter Saint-Andre]

On 11/9/11 10:44 AM, Peter Saint-Andre wrote:

On 11/9/11 10:42 AM, Anne van Kesteren wrote:

On Wed, 09 Nov 2011 09:39:56 -0800, Peter Saint-Andre
 wrote:

Based on Anne's previous message to this list [1], it seems that we're
actually talking about font representation formats (his examples are
TrueType Collection, OpenType, TrueType, and Web Open Font Format)
instead of particular fonts (e.g., "12pt Georgia Bold Italic") or
typefaces (e.g., "Georgia").

Correct?


Yes. Font formats, not font families.


Thanks for the clarification. That makes like much easier. :)


s/like/life/

There's still the general question of how useful it would be to define 
either a top-level content type or subtypes like application/woff, but 
at least we've constrained the problem space quite a bit here...


/psa

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] font sniffing

[Peter Saint-Andre]

On 11/9/11 10:42 AM, Anne van Kesteren wrote:

On Wed, 09 Nov 2011 09:39:56 -0800, Peter Saint-Andre
 wrote:

Based on Anne's previous message to this list [1], it seems that we're
actually talking about font representation formats (his examples are
TrueType Collection, OpenType, TrueType, and Web Open Font Format)
instead of particular fonts (e.g., "12pt Georgia Bold Italic") or
typefaces (e.g., "Georgia").

Correct?


Yes. Font formats, not font families.


Thanks for the clarification. That makes like much easier. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] font sniffing

[Anne van Kesteren]

On Wed, 09 Nov 2011 09:39:56 -0800, Peter Saint-Andre   
wrote:
Based on Anne's previous message to this list [1], it seems that we're  
actually talking about font representation formats (his examples are  
TrueType Collection, OpenType, TrueType, and Web Open Font Format)  
instead of particular fonts (e.g., "12pt Georgia Bold Italic") or  
typefaces (e.g., "Georgia").


Correct?


Yes. Font formats, not font families.



[1] http://www.ietf.org/mail-archive/web/websec/current/msg00235.html



--
Anne van Kesteren
http://annevankesteren.nl/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] font sniffing

[Peter Saint-Andre]

On 11/9/11 10:30 AM, Adam Barth wrote:

On Wed, Nov 9, 2011 at 9:29 AM, Peter Saint-Andre  wrote:

On 10/25/11 12:42 AM, Tobias Gondrom wrote:


On 25/10/11 07:30, "Martin J. Dürst" wrote:


On 2011/10/25 11:34, Anne van Kesteren wrote:


On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst
  wrote:


But who is at fault is not what we are interested in here I think. We
are interested in defining when implementations have to sniff. They
very
much have to sniff for fonts.


Yes. If somebody has enough energy, it would still make sense to
register font types.


Because..?


- Font formats, as well as other Mime types, are not only used by Web
browsers.
- There may be new formats, for which no sniffing is done yet.
- Servers may prefer to declare what they are sending out rather than
to be silent about it, even if not all clients use that information.
- Once we have registered types, sniffing could in the long term maybe
even go away.

Regards,   Martin.


+1 for that.


Based on discussion here and at the W3C TPAC last week, I raised this issue
on the apps-discuss list:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html

The immediate reaction was: "do you mean fonts or typefaces?"

Before taking on this work, it would be helpful to understand exactly what
typographic entities are being sent around by browsers and other
applications.


Mechanically, resource representations that might get shoved into
@font-face rules.


Based on Anne's previous message to this list [1], it seems that we're 
actually talking about font representation formats (his examples are 
TrueType Collection, OpenType, TrueType, and Web Open Font Format) 
instead of particular fonts (e.g., "12pt Georgia Bold Italic") or 
typefaces (e.g., "Georgia").


Correct?

/psa

[1] http://www.ietf.org/mail-archive/web/websec/current/msg00235.html


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] font sniffing

[Adam Barth]

On Wed, Nov 9, 2011 at 9:29 AM, Peter Saint-Andre  wrote:
> On 10/25/11 12:42 AM, Tobias Gondrom wrote:
>>
>> On 25/10/11 07:30, "Martin J. Dürst" wrote:
>>>
>>> On 2011/10/25 11:34, Anne van Kesteren wrote:

 On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst
  wrote:
>>
>> But who is at fault is not what we are interested in here I think. We
>> are interested in defining when implementations have to sniff. They
>> very
>> much have to sniff for fonts.
>
> Yes. If somebody has enough energy, it would still make sense to
> register font types.

 Because..?
>>>
>>> - Font formats, as well as other Mime types, are not only used by Web
>>> browsers.
>>> - There may be new formats, for which no sniffing is done yet.
>>> - Servers may prefer to declare what they are sending out rather than
>>> to be silent about it, even if not all clients use that information.
>>> - Once we have registered types, sniffing could in the long term maybe
>>> even go away.
>>>
>>> Regards,   Martin.
>>
>> +1 for that.
>
> Based on discussion here and at the W3C TPAC last week, I raised this issue
> on the apps-discuss list:
>
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html
>
> The immediate reaction was: "do you mean fonts or typefaces?"
>
> Before taking on this work, it would be helpful to understand exactly what
> typographic entities are being sent around by browsers and other
> applications.

Mechanically, resource representations that might get shoved into
@font-face rules.

Adam
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] font sniffing

[Peter Saint-Andre]

On 10/25/11 12:42 AM, Tobias Gondrom wrote:

On 25/10/11 07:30, "Martin J. Dürst" wrote:

On 2011/10/25 11:34, Anne van Kesteren wrote:

On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst
 wrote:

But who is at fault is not what we are interested in here I think. We
are interested in defining when implementations have to sniff. They
very
much have to sniff for fonts.


Yes. If somebody has enough energy, it would still make sense to
register font types.


Because..?


- Font formats, as well as other Mime types, are not only used by Web
browsers.
- There may be new formats, for which no sniffing is done yet.
- Servers may prefer to declare what they are sending out rather than
to be silent about it, even if not all clients use that information.
- Once we have registered types, sniffing could in the long term maybe
even go away.

Regards,   Martin.

+1 for that.


Based on discussion here and at the W3C TPAC last week, I raised this 
issue on the apps-discuss list:


http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03447.html

The immediate reaction was: "do you mean fonts or typefaces?"

Before taking on this work, it would be helpful to understand exactly 
what typographic entities are being sent around by browsers and other 
applications.


Peter

--
Peter Saint-Andre
https://stpeter.im/


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Adam Barth]

On Wed, Nov 9, 2011 at 8:38 AM, Steingruebl, Andy
 wrote:
>> -Original Message-
>> From: Adam Barth [mailto:i...@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
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Steingruebl, Andy]

> -Original Message-
> From: Adam Barth [mailto:i...@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?

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

- Andy
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Adam Barth]

On Tue, Nov 8, 2011 at 7:48 PM, Steingruebl, Andy
 wrote:
>> -Original Message-
>> From:  Chris Palmer
>> >  - There is no directive or suggestion to User Agents about saving or
>> > not saving pins received in a private browsing mode.  Maybe there
>> > shouldn't be, but if a User-Agent does save them, the same 304/ETag
>> > trick malicious sites use to track users can be created using certs
>> > and subdomains.
>>
>> Yes, another person raised this concern, and it is real. I don't see a way to
>> resolve this problem; perhaps I am not smart enough, but I can't see a way to
>> have both dynamic pinning AND avoid this tracking attack.
>>
>> I am willing to add a paragraph about what browsers should do in private
>> browsing mode, and I am willing to go either way on what the requirement
>> should be. I don't know what is best.
>
> 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.

Adam


> Clearing history/cookies on the browser is similarly problematic for HSTS and 
> pinning.  This is unfortunate in that we'd really like it to be hard for 
> users to clear HSTS state because it is "good for them".  Not clear whether 
> this belongs in the spec, or a set of implementation guidelines.  Folks got 
> squeamish here about talking about exact UA behavior, etc.
>
> There is a Firefox bugzilla bug about this issue, I'll try to go find it and 
> post back here unless someone beats me to it.
>
> - Andy
>
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

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

[Julian Reschke]

On 2011-11-09 01:31, Tom Ritter wrote:

My notes:

I believe the BNF (pseudo-BNF?) is incorrect:

Public-Key-Pins = "Public-Key-Pins" ":" LWS directives

directives  = max-age LWS ";" LWS fingerprints
  / fingerprints LWS ";" LWS max-age

max-age = "max-age" LWS "=" LWS delta-seconds

pins= "pins" LWS "=" LWS fingerprints

fingerprints= fingerprint
  / fingerprint "," fingerprints

fingerprint = fp-type "-" base64-digits

fp-type = "sha1"
  / "sha256"

I believe 'directives' should replace "fingerprints" with "pins":

directives  = max-age LWS ";" LWS pins
  / pins LWS ";" LWS max-age


...


By all means *please* consider re-using the syntax of an existing header 
field. In particular, please read





So decide whether you want to allow multiple header fields (in which 
case you should use the ABNF list notation used in 2616/HTTPbis), *or* 
define the syntax so that a "," introduced by header field recombination 
can be detected by recipients.


Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec