Subject: Re: [websec] #59: Is the interaction between pre-loaded pins and dynamic pins clear?

From: "websec issue tracker" <[email-masked]>
Date: Sun, 11 Aug 2013 20:55:55 -0000

#59: Is the interaction between pre-loaded pins and dynamic pins clear?

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => wontfix

Comment:

 The current text reflects working group consensus.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-websec-key-
  [email-masked]    |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  key-pinning  |     Version:
 Severity:  In WG Last   |  Resolution:  wontfix
  Call                   |
 Keywords:  HPKP         |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/59#comment:1>
websec <http://tools.ietf.org/websec/>

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 11 Aug 2013 22:53:08 -0700

> #59: Is the interaction between pre-loaded pins and dynamic pins clear?

Still needs discussion, in particular:

 * Preloaded pin stores will be periodically updated, which means
browsers will need to handle "backdated" pins, i.e. pins that are
received *after* other HPKP observations but have an "Effective Pin
Date" which is earlier.  To handle these in accordance with 2.7
requires browsers to remember "un-pinning" observations (expired pins,
max-age=0, or nonexistent HPKP headers).  This is sufficiently complex
that the spec needs some treatment of it.

 * 2.7 mandates that the most recent observation from any source MUST
take priority.  Browsers would not be allowed to implement other
priority rules, such as prioritizing one source over another,
prioritizing fail-open or fail-closed behavior, or anything else.  I
believe this is overly restrictive.  Some browsers might prefer
different policies, e.g. simpler policies that don't require tracking
"un-pinning" data.

When I brought these points up earlier, the two responses were
supportive of loosening the rules in 2.7.  I hadn't responded to
Yoav's latest query because I'm overloaded with HPKP discussion, and
assumed everyone else was too.

So I suggest we keep this open, and revisit once other discussions quiet down.

Trevor

---

From: "websec issue tracker" <[email-masked]>
Date: Mon, 12 Aug 2013 06:25:06 -0000

* status:  closed => reopened
 * resolution:  wontfix =>

Comment:

 Got a clarification from Trevor:

 http://www.ietf.org/mail-archive/web/websec/current/msg01833.html

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-websec-key-
  [email-masked]    |  [email-masked]
     Type:  defect       |      Status:  reopened
 Priority:  major        |   Milestone:
Component:  key-pinning  |     Version:
 Severity:  In WG Last   |  Resolution:
  Call                   |
 Keywords:  HPKP         |
-------------------------+-------------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/websec/trac/ticket/59#comment:2>
websec <http://tools.ietf.org/websec/>