Subject: [websec] Pre-loaded pins vs dynamic pins

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Feb 2014 11:56:07 +0000

[ 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

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 13 Feb 2014 11:42:41 -0800

> 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 recor…

Almost, but note that an unpinning event might be an observation of a
max-age=0 header, *or* a pin expiring (in which case the browser would
need to keep remembering the expired pin for some period along with
the time of last observing the header, *not* the expiration date).

So in your example - if the "unpinning" on 9-Feb is an HPKP
observation of max-age=0 then it would trump the preloaded pin's 7-Feb
observation date, but if it was an expiration of an 8-day pin it would
not, it would only trump preloaded observations prior to 1-Feb...

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

Seems fine, as long as the duration of those pins does not exceed what
the site has asserted.

> 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…

Yeah, I think this ability to un-pin sites who screw up will (sadly)
probably be necessary.

> 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 t…

Your "fourth way" is well-put, and I agree - all of these seem valid
implementations which should be allowed.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Wed, 19 Feb 2014 20:09:49 +0000

Sigh, the silence is deafening.

Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implementer?  If not, we'll resolve it that way.

Note, however, that the authors cannot update the draft until IETF week, but we can gather the required changes.

Please respond.

Thanks,

Yoav

---

From: Chris Palmer <[email-masked]>
Date: Wed, 19 Feb 2014 13:13:06 -0800

> implementations which should be allowed.

I have been thinking that this 4th way is the way to go. Note for
example that RFC 6797 (HSTS — which I would still like for HPKP to
emulate) does not even cover the topic.

---

From: Chris Palmer <[email-masked]>
Date: Wed, 19 Feb 2014 13:14:01 -0800

> Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implemen…

I don't object; I like that well enough.

---

From: Tom Ritter <[email-masked]>
Date: Wed, 19 Feb 2014 17:48:41 -0500

> I don't object; I like that well enough.

Seconded/Thirded/Fourthed

-tom

---

From: Daniel Veditz <[email-masked]>
Date: Wed, 19 Feb 2014 15:27:05 -0800

On 2/19/2014 1:13 PM, Chris Palmer wrote:
>> Your "fourth way" is well-put, and I agree - all of these seem
>> valid implementations which should be allowed.
>

The pre-load list seems outside the mechanism covered by the spec. At 
best the spec could mention it in a non-normative section as something 
UAs can do to cover the first-visit gap, but there are several valid 
ways such a list could be implemented.

-Dan Veditz

---

From: Tobias Gondrom <[email-masked]>
Date: Fri, 21 Feb 2014 20:49:07 +0000

> Seconded/Thirded/Fourthed

<no hat>
I agree. Thirded

Cheers, Tobias

>
> -tom
>
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec