[ I'm forking the thread so as to avoid confusing it with the other issue ]

Section 2.7 ( 
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11#section-2.7 ) 
describes the interaction between pre-loaded pin lists and the dynamic pins 
that the UA observes.

The draft says that any later observation (new pin, unpin, missing pin) always 
trumps an earlier observation. Seems right, except this creates an interesting 
issue with updates to the pre-loaded pin list, such as when there are browser 
updates, or just a dynamic update from the list:
 - what happens if a pin in the fresh list differs from a dynamic pin?
 - what happens if a pin that is in the list is one that had been unpinned 
before?

One way is to require the static list to have "observation dates" for each 
entry, and also require the UA to keep track of all noted pins for the lifetime 
of that pin. By keeping track I mean recording all replacement and unpinning 
events, including dates, so as to be able to construct a timeline with the 
static list, and be able to tell which event happened last. For example, if the 
UA notes a pin on 1-Feb, then notes an unpinning on 9-Feb, then on 15-Feb it 
downloads a new list with the old pin observed at 7-Feb, the pin should remain 
deleted.

Another way is to treat all updates from the static pins as if they had just 
been observed at the moment of download. That is obviously much easier to 
implement.

A third way (Trevor's) is to treat the static and dynamic pins as two separate 
pin databases, both of which are enforced and no interaction between them. But 
the UA vendor can also push updates for deleting dynamic pins, to save web site 
operators who have shot themselves in the foot.

Yet a fourth way is to observer that none of this affects interoperability in 
any way and leave it up to the UA vendor to choose their way. The web site 
operator should only include valid pins in their HPKP headers, and they should 
also enter only valid pins in pre-loaded lists. They should also deal with the 
fact that don't control usage patterns, so anytime they pin something for X 
seconds, their website MUST conform to that pin for at least those X seconds or 
bad things will happen.  


Trevor: if I didn't capture your opinion, please correct me.

People other than Trevor: I don't really believe that only Trevor cares about 
this issue. Please speak up about these alternatives above

Thanks

Yoav

_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec

Reply via email to