Re: [websec] #55: Clarify that the newest pinning information takes precedence

[websec issue tracker]

#55: Clarify that the newest pinning information takes precedence

Changes (by pal...@google.com):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Per discussion on the list, adopted Sleevi's text but changed "evict" to
 "ignore".

 https://code.google.com/p/key-pinning-
 
draft/source/diff?spec=svnfc4bef2ce138d467182832a362831b6d63ea9cdc&r=fc4bef2ce138d467182832a362831b6d63ea9cdc&format=side&path
 =/draft-ietf-websec-key-pinning.xml

-- 
---+
 Reporter:  pal...@google.com  |   Owner:  pal...@google.com
 Type:  defect |  Status:  closed
 Priority:  major  |   Milestone:
Component:  key-pinning| Version:
 Severity:  -  |  Resolution:  fixed
 Keywords: |
---+

Ticket URL: 
websec 

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

Re: [websec] #55: Clarify that the newest pinning information takes precedence

[Ryan Sleevi]

On Mon, April 1, 2013 3:28 pm, Chris Palmer wrote:
>  On Wed, Mar 27, 2013 at 7:54 PM, Tom Ritter  wrote:
>
> > " The UA MUST evict all expired Known Pinned Hosts if at any time, an
> > expired Known Pinned Host exists in the cache"
> >
> > I use rrdtool to keep 5 years of statistics for my server.  Once, I
> > accidentally set the date forward, to 2038, wiping out my statistics -
> > there was no way to recover, because rrdtool dutifully wiped all this
> > expired data.
> >
> > Using the word 'evict' seems particularly dangerous, for both active
> > ntp attacks, and accidental wiping.
>
>  Yoav says the text works for him. I wonder if we can satisfy both by
>  saying something like "the UA MUST ignore expired Known Pinned Hosts
>  in the cache." That way, if the client machine gets its clocked fixed
>  and the expired KPHs become un-expired, happiness will ensue once
>  again. Ryan, thoughts?
>  ___
>  websec mailing list
>  websec@ietf.org
>  https://www.ietf.org/mailman/listinfo/websec
>

Something like that works for me.

The spec only needs to ensure that the visible client behaviour remains
consistent - and ignoring expired Known Pin Hosts data is the desired
effect of the present language, so its fine to specify as this.

That said, I expect clients will probably continue with the "evict the
cache" approach, which would be fine and spec-compliant. I think there'd
only be an issue if there was language being proposed that said clients
*should not* evict the cache - as you could make an argument on security
considerations using Tom's example.

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

Re: [websec] #55: Clarify that the newest pinning information takes precedence

[Chris Palmer]

On Wed, Mar 27, 2013 at 7:54 PM, Tom Ritter  wrote:

> " The UA MUST evict all expired Known Pinned Hosts if at any time, an
> expired Known Pinned Host exists in the cache"
>
> I use rrdtool to keep 5 years of statistics for my server.  Once, I
> accidentally set the date forward, to 2038, wiping out my statistics -
> there was no way to recover, because rrdtool dutifully wiped all this
> expired data.
>
> Using the word 'evict' seems particularly dangerous, for both active
> ntp attacks, and accidental wiping.

Yoav says the text works for him. I wonder if we can satisfy both by
saying something like "the UA MUST ignore expired Known Pinned Hosts
in the cache." That way, if the client machine gets its clocked fixed
and the expired KPHs become un-expired, happiness will ensue once
again. Ryan, thoughts?
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #55: Clarify that the newest pinning information takes precedence

[Yoav Nir]

The text works for me.

On Mar 27, 2013, at 6:54 PM, websec issue tracker 

 wrote:

> #55: Clarify that the newest pinning information takes precedence
> 
> 
> Comment (by pal...@google.com):
> 
> Ryan Sleevi has added text to the working copy that I believe resolves
> this ticket. Comments?
> 
> https://code.google.com/p/key-pinning-
> draft/source/diff?spec=svn4f697cf66f747c18a5389922f484d9a1dbe85968&r=83bad3527ede8bb6ef52a8c220990ccd8762d9e7&format=side&path
> =/draft-ietf-websec-key-pinning.xml
> 
> -- 
> ---+
> Reporter:  pal...@google.com  |   Owner:  pal...@google.com
> Type:  defect |  Status:  assigned
> Priority:  major  |   Milestone:
> Component:  key-pinning| Version:
> Severity:  -  |  Resolution:
> Keywords: |
> ---+
> 
> Ticket URL: 
> websec 
> 
> ___
> 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] #55: Clarify that the newest pinning information takes precedence

[Tom Ritter]

" The UA MUST evict all expired Known Pinned Hosts if at any time, an
expired Known Pinned Host exists in the cache"

I use rrdtool to keep 5 years of statistics for my server.  Once, I
accidentally set the date forward, to 2038, wiping out my statistics -
there was no way to recover, because rrdtool dutifully wiped all this
expired data.

Using the word 'evict' seems particularly dangerous, for both active
ntp attacks, and accidental wiping.

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

Re: [websec] #55: Clarify that the newest pinning information takes precedence

[websec issue tracker]

#55: Clarify that the newest pinning information takes precedence


Comment (by pal...@google.com):

 Ryan Sleevi has added text to the working copy that I believe resolves
 this ticket. Comments?

 https://code.google.com/p/key-pinning-
 
draft/source/diff?spec=svn4f697cf66f747c18a5389922f484d9a1dbe85968&r=83bad3527ede8bb6ef52a8c220990ccd8762d9e7&format=side&path
 =/draft-ietf-websec-key-pinning.xml

-- 
---+
 Reporter:  pal...@google.com  |   Owner:  pal...@google.com
 Type:  defect |  Status:  assigned
 Priority:  major  |   Milestone:
Component:  key-pinning| Version:
 Severity:  -  |  Resolution:
 Keywords: |
---+

Ticket URL: 
websec 

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

Re: [websec] #55: Clarify that the newest pinning information takes precedence

[Chris Palmer]

Any thoughts on this text?


On Fri, Oct 19, 2012 at 2:33 PM, websec issue tracker
 wrote:
> #55: Clarify that the newest pinning information takes precedence
>
>  In section "Interactions With Preloaded Pin Lists", we need to specify
>  that the newest information, even "stop pinning", must take precedence. I
>  propose this text:
>
>  UAs MUST use the newest information — built-in or set via Valid Pinning
>  Header — when performing Pin Validation for the host. If the result of
>  noting a Valid Pinning Header is to disable pinning for the host (such as
>  because the host set a max-age directive with a value of 0), UAs MUST
>  allow this new  nformation to override any built-in pins. That is, a host
>  must be able to un-pin itself even from built-in pins.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] #55: Clarify that the newest pinning information takes precedence

[websec issue tracker]

#55: Clarify that the newest pinning information takes precedence

Changes (by palmer@…):

 * status:  new => assigned


-- 
-+---
 Reporter:  palmer@… |   Owner:  palmer@…
 Type:  defect   |  Status:  assigned
 Priority:  major|   Milestone:
Component:  key-pinning  | Version:
 Severity:  -|  Resolution:
 Keywords:   |
-+---

Ticket URL: 
websec 

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

[websec] #55: Clarify that the newest pinning information takes precedence

[websec issue tracker]

#55: Clarify that the newest pinning information takes precedence

 In section "Interactions With Preloaded Pin Lists", we need to specify
 that the newest information, even "stop pinning", must take precedence. I
 propose this text:

 UAs MUST use the newest information — built-in or set via Valid Pinning
 Header — when performing Pin Validation for the host. If the result of
 noting a Valid Pinning Header is to disable pinning for the host (such as
 because the host set a max-age directive with a value of 0), UAs MUST
 allow this new  nformation to override any built-in pins. That is, a host
 must be able to un-pin itself even from built-in pins.

-- 
-+--
 Reporter:  palmer@… |  Owner:  palmer@…
 Type:  defect   | Status:  new
 Priority:  major|  Milestone:
Component:  key-pinning  |Version:
 Severity:  -|   Keywords:
-+--

Ticket URL: 
websec 

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