Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-10.txt

From: [email-masked]
Date: Thu, 06 Feb 2014 11:01:06 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Security Working Group of the IETF.

        Title           : Public Key Pinning Extension for HTTP
        Authors         : Chris Evans
                          Chris Palmer
                          Ryan Sleevi
	Filename        : draft-ietf-websec-key-pinning-10.txt
	Pages           : 23
	Date            : 2014-02-06

Abstract:
   This memo describes an extension to the HTTP protocol allowing web
   host operators to instruct user agents (UAs) to remember ("pin") the
   hosts' cryptographic identities for a given period of time.  During
   that time, UAs will require that the host present a certificate chain
   including at least one Subject Public Key Info structure whose
   fingerprint matches one of the pinned fingerprints for that host.  By
   effectively reducing the number of authorities who can authenticate
   the domain during the lifetime of the pin, pinning may reduce the
   incidence of man-in-the-middle attacks due to compromised
   Certification Authorities.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-websec-key-pinning-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Yoav Nir <[email-masked]>
Date: Fri, 7 Feb 2014 09:39:43 +0000

Thank you Chris, Chris and Ryan.

This is to announce the beginning of a WGLC for this draft. Because a lot of the group members are busy preparing for London and getting those drafts out by the deadline, we will extend the time allocated for this WGLC to three weeks, ending on February 28th.

Please take this almost-final opportunity to review the draft and if you spot a problem, send comments to the list.

Thanks

Tobias and Yoav

On Feb 6, 2014, at 9:01 PM, [email-masked] wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
> 
> Email secured by Check Point

---

From: Tom Ritter <[email-masked]>
Date: Fri, 7 Feb 2014 08:12:56 -0500

" 5. If a PKP header field contains any directive(s) the UA does not
       recognize, the UA MUST ignore the those directives."

Typo.

--------

"If a Host sets both the Public-Key-Pins header and the Public-Key-
   Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and
   MUST note only the pins and directives given in the Public-Key-Pins-
   Report-Only header."

I thought we were following the CSP model, where you can enforce one
policy, but test a second.

--------

Figure 3 shows some example response header fields using the pins
   extension (folded for clarity).

   "d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="
   "E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="
   Public-Key-Pins: max-age=3000;
       pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
       pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";

I think some base64 got added accidentally at the top.

--------

"UAs MUST NOT heed http-equiv="Public-Key-Pins" attribute settings on
   <meta> elements [W3C.REC-html401-19991224] in received content."

It might be pedantic, but perhaps 'or http-equiv="Public-Key-Pins-Report-Only"'?

--------

UAs MUST recognize and "sha256".

Typo

--------

'Pins' vs 'pins'

Pedantry, but the noun pins is inconsistently capitalized through the document.

--------

Reporting Pin Validation Failure

The JSON report omits directives (such as max-age and
includeSubDomains) that are likely to be relevant.
It also omits superfluous certificates included in the chain that can
be relevant. (In certificate validation testing, it's common to bypass
it by including a superfluous chain that triggers a logic error. This
would help diagnose these types of attacks.)

--------

"The known-pins are the Pins that the UA has noted for the Known
   Pinned Host.  They are provided as an array of strings with the
   syntax:

   known-pin = token "=" quoted-string
                        Figure 6: Known Pin Syntax
"

I think this needs clarification (or fixing).  'Array of strings' +
token=quoted-string.  ["pin-sha256="base64==""] obviously doesn't
work. An example JSON post would be cool.

--------

Public-Key-Pins: pin-sha256="ABC..."; pin-sha256="DEF..."; includeSubDomains

                Figure 7: example.com Valid Pinning Header

To make it 'valid' should it include max-age=123...?

--------

"Here are two attack scenarios."

You actually list four. (Two of which have empty top-level bullets.)

--------

IANA Considerations

This omits Public-Key-Pins-Report-Only

-tom

---

From: Chris Palmer <[email-masked]>
Date: Fri, 7 Feb 2014 17:22:38 -0800

Thank you, Tom! I have submitted revision 11 which I think/hope
addresses all your points. And I added your name to the Thank You
section.

---

From: Chris Palmer <[email-masked]>
Date: Fri, 7 Feb 2014 17:47:19 -0800

Oops, I forgot one thing:

> policy, but test a second.

Honestly, I think that's likely to be too complicated. I want to
prioritize ease of deployment (which includes a simple-to-state policy
like the above, and failing open when not unreasonably unsafe), and
I'd like for the implementation not to get too much more complicated.

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 7 Feb 2014 21:41:36 -0800

> Please take this almost-final opportunity to review the draft and if you spot a problem, send comments to the list.

Hi Yoav,

You've been trying to rush through a "Last Call" since June.  A new
draft appeared hours ago.  There were substantive open questions the
last time we discussed this, and there have been substantive changes
in the draft.

It's going to take time for people to read the new draft, digest the
changes, and discuss.

Could you please give us this time and stop trying to force this?

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Sat, 8 Feb 2014 15:00:09 +0000

> Could you please give us this time and stop trying to force this?

Hi Trevor.

I don't think taking from June till now is "rushing". As you have said, there are substantive changes in the draft, and that is why we have allowed three weeks rather than traditional two for this last call. We (Tobias, myself and the authors) believe that the issue that have been raised have been addressed in this version. If it turns out that there are new issues, on which we haven't yet reached consensus, we will discuss them, and have as many more revisions as necessary. 

In low-traffic mailing lists such as this one, there are participants who won't spend the time on reading and commenting until last call. In June we had thought that all the issues were addressed, but new ones emerged only when we started the WGLC. So we discussed more, and went through a few more revisions, and here we are. As always in the IETF, nothing leaves the working group without consensus being called. 

I believe that three weeks is plenty for reading, digesting and discussing. 

Regards,

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sat, 8 Feb 2014 15:00:03 +0000

Hi Trevor.

Regards,

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Feb 2014 08:36:58 -0800

> Could you please give us this time and stop trying to force this?

21 days for a WG Last Call is *long*, not short. One could easily argue that the chairs were being too slow with that.

--Paul Hoffman

---

From: Tom Ritter <[email-masked]>
Date: Sat, 8 Feb 2014 11:47:44 -0500

> I'd like for the implementation not to get too much more complicated.

I suppose. I think the extra  implementation complication is in
conditionally applying code rather than having to write additional code,
which strike me as different, but you would know better than me.

And that deployment would actually be made more confusing, not less, by
having two analogous headers, named in the same pattern, that behave
differently - I think that's likely to cause as much confusion as anything
else.

I imagine someone like Twitter, with its multiple pinned CAs, would have a
really good use case for being able to apply and test two different
policies.

But, I also am anxious to get this out in the field - if anyone thinks
similarly, they can speak up.

-tom

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 08 Feb 2014 20:29:23 +0000

> I believe that three weeks is plenty for reading, digesting and discussing. 

Hi Trevor,

I just wanted to add, that the call for WGLC has not been by decided by
Yoav alone, but that as WG co-chairs we both discussed the appropriate
timelines and are in full agreement on this.

And as Paul pointed out by normal IETF standards a 3 week WGLC would
normally be considered long.

Best regards, Tobias

Ps.: btw. if you think the draft still has major flaws or has not
addressed adequately major flaws that have been pointed out earlier, I
encourage you to post this now during the WGLC.

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 8 Feb 2014 16:53:10 -0800

I had ~20 comments on the last draft [1], which were issues I first
brought up in July and which the chairs have apparently decided to
ignore.  Brian Smith had several comments.  There's still an open
issue in the tracker which I've brought up a few times.

List volume is low because we've been spent most of the last several
months waiting for a new draft, not because we're out of things to
discuss.

It would be helpful if the chairs were tracking open issues and
promoting discussion to make sure they're resolved via on-list
consensus, instead of just trying to force a document through.

Trevor

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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 9 Feb 2014 05:02:00 +0000

Hi Trevor

The issue on the tracker is about the interaction of dynamic pins with pre-loaded pins. The authors have written section 2.7 to address this. 

So let's bring back your points:

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

Section 2.7 is pasted below my sig.

Yoav

2.7.  Interactions With Preloaded Pin Lists

   UAs MAY choose to implement additional sources of pinning
   information, such as through built-in lists of pinning information.
   Such UAs SHOULD allow users to override such additional sources,
   including disabling them from consideration.

   UAs that support additional sources of pinning information MUST use
   the most recently observed pinning information when performing Pin
   Validation for a host.  The most recently observed pinning
   information is determined based upon the most recent Effective Pin
   Date, as described in Section 2.3.2
.

   If the result of noting a Valid Pinning Header is to disable pinning
   for the host, such as through supplying a max-age directive with a
   value of 0, UAs MUST allow this new information to override any other
   pinning data.  That is, a host must be able to un-pin itself, even in
   the presence of built-in Pins.

   Example: A UA may ship with a pre-configured list of Pins that are
   collected from past observations of Valid Pinning Headers supplied by
   hosts.  In such a solution, the pre-configured list should track when
   the Valid Pinning Header was last observed, in order to permit site
   operators to later update the value by supplying a new Valid Pinning
   Header.  Updates to such a pre-configured list should not update the
   Effective Pin Dates for each host unless the list vendor has actually
   observed a more recent header.  This is to prevent situations where
   updating the Effective Pin Date on a pre-configured list of Pins may
   effectively extend the max-age beyond the site operator's stated
   policy.

   Example: A UA may ship with a pre-configured list of Pins that are
   collected through out-of-band means, such as direct contact with the
   site operator.  In such a solution, the site operator accepts
   responsibility for keeping the configured Valid Pinning Header in
   sync with the vendor's list, allowing the UA vendor to have each
   update to the list be treated as as an update of the Effective Pin
   Date.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 9 Feb 2014 07:24:38 +0000

[Replying to myself, but with no hats on]

IMO the current text is fine. Regarding the first point, it creates a burden for the browser maker, but only if they update their pre-loaded pin list by observation. If it's created by OOB means as described in the second example, the burden is on the site operators, and they are likely to unpin in both places at the same time. I think this also goes to your second point. 

I think in a future where HPKP is supported in most browsers, pre-loaded lists will contain very few entries - perhaps the big content sites and a few banks, maybe Paypal. I expect that most site operators would be happier to pin sites by themselves with an HPKP header rather than interact with all browser vendors. 

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 09 Feb 2014 10:21:41 +0000

Hi Trevor,

<hat="wg chair">

I had no intention to ignore issues being raised. I was rather under the
impression they had been addressed via the issue tracker and in the new
version of the draft. One purpose of the WGLC is in fact to verify that
all issues have been resolved and weed out any remaining problems.

We have no intention of "forcing through" a document.
And I fully recognise the fact that new revisions of the draft have
regrettably been coming rather slow and that this can have contributed
to low volume on the mailing-list, waiting for the revised text.

Maybe to approach every issue in a structured approach in order to avoid
missing any open issues:
In my understanding all topics you and others posted have been mapped to
issues in the tracker. Are we missing something there? If so or if you
see new issues, please re-raise them on the mailing-list and please feel
free to post issues in the tracker. We use the tracker to track open
issues and to close them when they have been discussed. When you
disagree with the closing of an issue it is good to raise your
objections when that happens to make sure the WG understands your
opinion and concerns and can discuss the problem accordingly.

All the best, Tobias

(co-chair of websec)

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 Feb 2014 14:26:41 +0200

> Please take this almost-final opportunity to review the draft and if you spot a problem, send comments to the list.

Some comments of my own. No hats

Section 1, first sentence begins with "We propose a new...". Our target 
is called "proposed standard", but I think it would be better to say "We 
define a new HTTP header..."

  ---------

Fourth paragraph in section 2.1.3 is kind of clunky:

OLD
"When used in the Public-Key-Pins header, the presence of a report-uri 
directive indicates to the UA that the UA MUST enforce Pin Validation, 
and the UA SHOULD also, in the event of Pin Validation failure, POST a 
report to the report-uri."

The presence of the report-uri directive has nothing to do with the UA 
having to enforce pin validation. That is required by any PKP header. 
How about rewriting this as:
NEW
"When used in the Public-Key-Pins header, the presence of a report-uri 
directive indicates to the UA that it SHOULD also, in the event of Pin 
Validation failure, POST a report to the report-uri."

  --- ------

Section 2.5.
Section 2.4 says that future versions may add new algorithms. So we 
should be prepared for new algorithms. Section 2.5 says "For forward 
compatibility, the UA MUST ignore any unrecognized Public-Key-Pins 
header directives, while still processing those directives it does 
recognize."  So suppose the UA got the following header:

Public-Key-Pins: max-age=2592000;
     pin-sha4-256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
     pin-sha4-256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="

Not having support for SHA4, it can't validate or use these pins. That 
is fine when the server keys are not yet pinned. Now suppose that the 
server is pinned (because previously it expressed HPKP with a SHA2-256. 
Does the UA (a) ignore it, keeping the old pin, or (b) treat this as 
unpinning?  Either way, where does it say so?

Thanks

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 12 Feb 2014 19:03:04 -0800

> different policies, e.g. simpler policies that don't require tracking

I had a more recent email (below) which describes a simple and
reasonable interaction of preloaded and dynamic pins which the current
spec disallows:

"""
There was an item to discuss "interaction between pre-loaded and
dynamic pins", and some earlier discussion:

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

I think the current text in draft-08 section 2.7 is unclear about what
preloaded and dynamic information the browser needs to store.

Most of the draft is written as if the browser is only storing active,
unexpired pins.  But 2.7 seems to imply the browser stores timestamped
"negative observations" such as max-age=0 observations, no-header
observations, and expired pins, which will override
less-recently-observed pins from different data sources (preloaded
overriding dynamic, or vice versa).

I could imagine simpler policies.  One example:
 * The preload and dynamic lists contain only active, unexpired pins
 * The browser applies pins from both lists (i.e. if both a dynamic
and preloaded pin exist for example.com, they are both applied)
 * The browser manufacturer can push an "override" which erases bad
dynamic pins for particular hostnames.

This wouldn't provide automatic overriding of (preloaded/dynamic) pins
based on newer observations in a different source.  But it *would*
allow for explicit overriding of bad dynamic pins, which seems the
most important type of overriding.  It also seems much simpler.

I suggest we allow such different and simpler policies.

If people disagree, I'd like to hear a clearer statement of:
 * How exactly the current policy will work (i.e. what negative
information needs to be stored and how it's used).
 * Why it's necessary to support automatic overriding of pins from
different sources based on the newest observation?
"""
http://www.ietf.org/mail-archive/web/websec/current/msg01938.html

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 12 Feb 2014 19:22:55 -0800

On Sat, Feb 8, 2014 at 11:24 PM, Yoav Nir <[email-masked]> wrote:
> IMO the current text is fine. Regarding the first point, it creates a burden for the browser maker, but only if they update their pre-loaded pin list by observation.

Updating preloaded pin lists by "observation" (i.e. scanning sites for
HPKP headers) is a reasonable thing for a browser maker to do.

We shouldn't create an unnecessary burden for them in that case.

I find section 2.7 unclear, but it seems to mandate that preloaded pin
lists MUST include entries for expired pins or max-age=0 pins, as well
as the last-observed time for each such entry and each pin, so that
the browser can be sure it is using the "most recent" observation for
each pin, even when that observation was negative or now expired.

That seems to unnecessarily preclude simpler and more efficient
implementations, which is my objection.

> I think in a future where HPKP is supported in most browsers, pre-loaded lists will contain very few entries - perhaps the big content sites and a few banks, maybe Paypal. I expect that most site o…

Since browser vendors could scan for HPKP headers to populate their
preloaded lists I think wider use of HPKP is likely to lead to *MORE*
preloaded pinning, not less.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 12 Feb 2014 21:07:15 -0800

> I'd like for the implementation not to get too much more complicated.

When we discussed PKP-RO in Nov/Dec there was uncertainty on things like:
 * Is the browser expected to store a PKP-RO pin, or just evaluate it
against the connection that asserted it?
 * What happens when a server asserts both PKP and PKP-RO?

The first seems like a major decision which hasn't been decided yet.

On the second point, Ryan Sleevi's opinion back then was different from yours:

"A PKP might specify a looser-policy, while PKP-Report-Only is used to
test a more restrictive policy for deployment."
http://www.ietf.org/mail-archive/web/websec/current/msg01961.html

It seems you've decided differently.  But that brings back an earlier
question: if the PKP and PKP-RO headers can't be usefully asserted
simultaneously, why have two headers at all?  Shouldn't we just have a
"read-only" directive in that case?

In any case, the -10 and -11 drafts didn't make any clarifications to
PKP-RO, so are these still open issues?

There were a few other things Ryan was going to clarify about PKP-RO.
Below are excerpts from that thread:

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

[TREVOR] Why is there a "Public-Key-Pins-Report-Only" header instead
of a "report-only" directive?  Most of the document is written as if
there was a single "PKP header field", so a directive would make more
sense.

[SLEEVI] Similar to CSP. A PKP might specify a looser-policy, while
PKP-Report-Only is used to test a more restrictive policy for
deployment.
...
Report-Only doesn't/wouldn't need to be stored, because it is a
report-only mechanism. You simply evaluate the R-O on the current
connection (if a directive is present) and ping back.
...
To me, R-O makes most sense when treated like CSP - if present,
report, otherwise, nothing. This is consistent with an implicit
Max-Age: 0, because no storage is required or performed.

[TREVOR] Hmm, I assumed "report-only" pins would be noted, and the
draft seems written that way.

****************************

[TREVOR] Section 2.5 - Does a failed validation of a "report-only" pin
count as an "error" that will inhibit noting of new pins in the
connection?

[SLEEVI] No. Happy to clarify that.

****************************

[TREVOR] Specified UA behavior with multiple header fields is contradictory:
 - 2.1.3: "If a Host sets both the Public-Key-Pins header and the
Public-Key-Pins-Report-Only header, the UA MUST NOT enforce Pin
Validation, and MUST note only the pins and directives given in the
Public-Key-Pins-Report-Only header."
 - 2.3.1: "If a UA receives more than one PKP header field in an HTTP
response message over secure transport, then the UA MUST process only
the first such header field."

[SLEEVI] The ambiguity is the term "PKP header field", which may be
alternatively written "more than one PKP header field or more than one
PKP-R-O header field". Does that satisfy your concern?

Trevor

---

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

On Wed, Feb 12, 2014 at 4:26 AM, Yoav Nir <[email-masked]> wrote:

> Section 1, first sentence begins with "We propose a new...". Our target is
> called "proposed standard", but I think it would be better to say "We define
> a new HTTP header..."

That is currently what it says.
(https://code.google.com/p/key-pinning-draft/source/browse/draft-ietf-websec-key-pinning.xml)

> directive indicates to the UA that the UA MUST enforce Pin Validation, and
> the UA SHOULD also, in the event of Pin Validation failure, POST a report to
> the report-uri."
>
> having to enforce pin validation. That is required by any PKP header. How
> about rewriting this as:
> NEW

Agreed. Making that change now.

> Section 2.5.
> Section 2.4 says that future versions may add new algorithms. So we should
> be prepared for new algorithms. Section 2.5 says "For forward compatibility,
> the UA MUST ignore any unrecognized Public-Key-Pins header directives, while
> still processing those directives it does recognize."  So suppose the UA got
> the following header:
>
> Not having support for SHA4, it can't validate or use these pins. That is
> fine when the server keys are not yet pinned. Now suppose that the server is
> pinned (because previously it expressed HPKP with a SHA2-256. Does the UA
> (a) ignore it, keeping the old pin, or (b) treat this as unpinning?  Either
> way, where does it say so?

I don't think the text currently handles this case. And, I don't know
which of (a) or (b) is preferable.

It's a bit of a pathological case; why would a site operator send such
a header, knowing as they do that the current version of HPKP
specifies only SHA-256 (i.e. SHA2-256)?

In future versions, in which we hypothetically add support for SHA4
(or whatever future hash function), presumably we'd include some
language about this. But for now, any site operator doing this would
be making a mistake.

---

From: Chris Palmer <[email-masked]>
Date: Wed, 19 Feb 2014 15:05:23 -0800

> which strike me as different, but you would know better than me.

You're right, but even that feels complicated right now. :)

> differently - I think that's likely to cause as much confusion as anything

Yeah, I see that. I think I'll have to change the text to allow the
CSP-style enforce 1 policy, report on another behavior.

So, how about this:

<t>If a Host sets both the Public-Key-Pins header and the
Public-Key-Pins-Report-Only header, the UA MUST note and enforce Pin
Validation as specified by the Public-Key-Pins header, and SHOULD note and
the Pins and directives given in the Public-Key-Pins-Report-Only header. If
the UA does note the Pins and directives in the Public-Key-Pins-Report-Only
header it SHOULD evaluate the specified policy and SHOULD report any
would-be Pin Validation failures that would occur if the report-only policy
were enforced.</t>

---

From: Tom Ritter <[email-masked]>
Date: Wed, 19 Feb 2014 18:14:02 -0500

> Validation as specified by the Public-Key-Pins header, and SHOULD note and

"And the pins" is a typo. I'm not clear what note means in this context.
You probably mean "not ignore", but I don't know the least ambiguous verb
to use? In any event, I like the sentiment.

> would-be Pin Validation failures that would occur if the report-only
policy

(Sent on a phone)

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 Feb 2014 11:18:01 +0000

> language about this. But for now, any site operator doing this would

I think we do need to specify how an implementation of *this* spec deals with unknown hashes. Imagine that this technology came about 15 years ago, and that many websites had "pin-sha1" headers. Then in 2006 we realized that SHA-1 was no longer considered secure, and wrote a new RFC with pin-SHA256 (that was the new thing in 2005). Now it's 2014, and a site operator believes that everyone's browser supports the new standard, so he replaces the pin-sha1s with pin-sha256s. As it turns out, some browsers only started supporting the new standard in 2009, and some people are using an unupdated browser from 2008. 

Back to the real world, we don't have to say how to handle pin-sha4 directives, but we do have to specify how to handle pin directives that we don't recognize.  Section 2.5 says:
   For forward compatibility, the UA MUST ignore any unrecognized
   Public-Key-Pins header directives, while still processing those
   directives it does recognize.  Section 2.1 specifies the directives
   max-age, Pins, includeSubDomains, and report-uri but future
   specifications and implementations might use additional directives.

I guess "ignoring" is similar to omitting or filtering out, so my hypothetical header from above reduces to:

   Public-Key-Pins: max-age=2592000

What do we do with this, (a) or (b), and where does it say so. BTW: I'm not sure how servers can disable pinning. "max-age=0" is given as an example, but reading section 2.5 strictly seems to suggest that even with max-age=0 you need one valid pin from the certificate chain, and one valid pin not from the certificate chain. This makes the above example non-valid, so it shouldn't be noted, but it's weird that you require pins to unpin.

Thanks

Yoav

---

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

> What do we do with this, (a) or (b), and where does it say so. BTW: I'm not sure how servers can disable pinning. "max-age=0" is given as an example, but reading section 2.5 strictly seems to sugge…

<no hat>
in case of an unrecognised pin-shaX, scenario (a) would result in a
potentially dangerous situation, that can brick the site, i.e. make it
unavailable.
If the new pin is ignored, i.e. not noted, that would mean the old pin
would remain in place for the full period of time, even though maybe the
new cert will be active soon and the old one no longer available.
So I am afraid we probably need to entertain (b)?

Best regards, Tobias

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 22 Feb 2014 13:49:10 -0500

On 02/21/2014 03:58 PM, Tobias Gondrom wrote:

>> (a) ignore it, keeping the old pin, or (b) treat this as unpinning?

> So I am afraid we probably need to entertain (b)?

I also think that (b) (unpinning) is the right answer here, considering
the semantics of the decision.

Consider it this way:

 * the site operator gets to decide what pins they issue, and what hash
algorithms to use.

 * the site operator presumably has a rough idea of how many of their
clients are using software that might not be able to handle new hash
algorithms

 * the site operator also decides what security properties/strength they
require of a given hash algorithm.

If the site operator considers an older hash algorithm to be too weak to
rely on, and a client only knows that hash algorithm, then the site
operator asking that client to unpin (and perhaps acknowledge the lack
of pinning to the user via whatever UI provides information about the
pin) is the right thing to do.

If a site operator considers the older hash algorithm to be weak but
still acceptable as a pin for those that only know that hash algorithm,
then they should include a matching pin with the older hash algorithm as
well as their preferred hash algorithm.

This raises a couple of suggestions for me:

 0) if a site operator decides to use more than one hash algorithms in
the future, do we require that they issue the same set of pins under
each algorithm?  So if i'm pinning keys X and Y and Z, and i'm using
both pin-sha2-256 and pin-sha3-256, must i issue 6 pins?  I think it's
reasonable to say yes here, even if we don't have any other digests
defined yet.  Why would you want to pin different keys with different
hash algorithms?

 1) If a UA knows about two hashing algorithms, then the language in 2.6
is potentially problematic for visiting a site that provides pins using
both hashing algorithms.  In particular, checking the set intersection
of all pins suggests that an attacker need only defeat the weakest hash.
 I suggest that when multiple hash algorithms are known to the UA, and
it has pins for a given site under more than one hash algorithm, then it
must look for the set intersection *per hash algorithm used by the site*
and only proceed if all hash algorithms show a set intersection.

  This should raise the attacker's bar to the strongest of the set of
hashes used, rather than the weakest.

Regards,

	--dkg