Subject: [websec] Comments on draft-ietf-websec-key-pinning

From: Jeffrey Walton <[email-masked]>
Date: Fri, 2 Jan 2015 00:21:33 -0500

I'd like to share some comments on
https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21.

Pubic key pinning is an effective security control and I'm glad to see
the IETF moving forward with it. And I'm especially thankful to Palmer
and Sleevi for taking the time to put it together and shepherd it
through the process.

***** (1) *****

The title "Public Key Pinning Extension for HTTP" seems overly broad
and misses the mark a bit. The Abstract states its for User Agents,
but the title does not narrow focus.

There are different problem domains where public key pinning can be
utilized. Painting with a broad brush, I categorize them as "the
general problem" where no 'a priori' knowledge exists, and various
specific "instance problems", where 'a priori' does exits and can be
leveraged. An example of the general problem is browsers, and an
example of the instance problem is any custom software deployed by an
organization.

Suggestion: change the title to "Trust on First Use Pinsets and
Overrides for HTTP" or "Pinsets and Overrides for HTTP in User
Agents".

There are a few reasons for the suggestion. First, the abstract
effectively states its. Second, the proposed standard is a TOFU scheme
used for the general problem. Third, the Introduction recognizes the
two classes of problems when it discusses the pre-shared keys. Fourth,
the embodiment described in the proposed standard is not a preferred
solution for the many instances of the specific problems. Fifth, the
overrides need to be highlighted since they are an integral and high
impact part of the proposed standard.

Above, when I said the "… is not a preferred solution for the many
instances of the specific problems", I'm referring to pinning as
described in Gutmann's Engineering Security [1], OWASP [2] or by Moxie
Marlinspike [3] and others.

***** (2) *****

I think the document could benefit from a more comprehensive
discussion of the goals. The abstract states "… [some]
man-in-the-middle attacks due to compromised Certification
Authorities". That wet my appetite and I'd like to read more.

I think it would be more helpful to state what is trying to be
achieved in terms of both operational goals and security goals. For
example, I don't see any operational goals, like business continuity
behind a proxy. And "some man-in-the-middle attacks due to compromised
Certification Authorities" seems to be a somewhat underspecifed
security goal.

***** (3) *****

I think the document could benefit from an enumeration of the threats
the security control is intended to defend against (or a normative
reference to the "Pinning Threat Model" stated in [4]).

Taken in its totality (pinning + overrides), its not clear to me what
the proposed standard defends against.

The Abstract mentions it could defend against "[some]
man-in-the-middle attacks due to compromised Certification
Authorities." Because we don't know what the control is intended to
protect against, we can't measure its effectiveness.

Additionally, when public key pinning is used in a more traditional
sense (like Gutmann's Engineering Security [1], OWASP [2] or Moxie
Marlinspike [3]), then pinning defends against some things the
proposed standard appears to allow.

The lack of clarity means there are some significant operational
differences between customary expectations and the proposed standard.
The misunderstood differences will clearly lead to confusion,
unexpected results and a false sense of security.

***** (4) *****

>From the 1. Introduction:

    Key pinning is a trust-on-first-use (TOFU) mechanism.

That may be true for the general problem, but its completely untrue
when 'a priori' knowledge exists for a specific instance of the
problem. Gutmann's Engineering Security [1], OWASP [2] or Moxie
Marlinspike [3] have been providing the counter examples for years.

***** (5) *****

>From the 1. Introduction:

   A Pin is a relationship between a hostname and a cryptographic
   identity (in this document, 1 or more of the public keys in a chain
   of X.509 certificates).  Pin Validation is the process a UA performs
   to ensure that a host is in fact authenticated with its previously-
   established Pin.

I was a little confused the first time I read this because I parsed it
incorrectly. Here's how I parsed the first time: only the server or
end-entity certificate has a hostname, so only that certificate can
contribute a public key to a pinset. The other certificates
(intermediate and ca) can't contribute to a pinset because they don't
have a hostname.

Perhaps something like "A Pin is a mapping of a hostname to a set (one
or more?) of public keys that can be used to cryptographically certify
the site's identity... The public keys can be any of (1) the host's
public key (2) any intermediate or ca public key...".

Also, 2.4 Semantics of Pins, offers a slightly different definition
(it includes an algorithm, which appears to be missing from this
definition). So maybe the definition above should be expanded to
include "contextual information" that can later be ratified.

***** (6) *****

The document might also consider introducing the term "Pinset". I
think Kenny Root or the Android Security Team introduced the term at
Google I/O a couple of years ago. They were probably using the term
internally before then.

***** (7) *****

>From the 1. Introduction:

        ...  UAs apply X.509 certificate chain validation in accord
        with [RFC5280].)

Typo: accord -> accordance.

***** (8) *****

>From 2.1.  Response Header Field Syntax:

    The "Public-Key-Pins" and "Public-Key-Pins-Report-Only" header...

The naming of the fields appear to indicate they are mutually
exclusive (Report Only seems to indicate anything other than reporting
is prohibited). But 2.3.2 allows them both, so it might be a good idea
to make a quick statement that both are allowed in 2.1, and then
detail it in 2.3.2. Or drop the "Only" from
"Public-Key-Pins-Report-Only".

***** (10) *****

>From 2.2.2. HTTP Request Type:

   Pinned Hosts SHOULD NOT include the PKP header field in HTTP
   responses conveyed over non-secure transport.  UAs MUST ignore any
   PKP header received in an HTTP response conveyed over non-secure
   transport.

There could be some confusion here. What about anonymous protocols
that provide confidentiality only? Is it allowed or not allowed?

***** (11) *****

>From 2.3.3. Noting a Pinned Host - Storage Model:

   Known Pinned Hosts are identified only by domain names, and never IP
   addresses.

This is kind of interesting. This document specifies behavior for
browsers and other UAs, but browsers follow the CA/B. The CA/B does
not prohibit a CA from issuing certificates for an IP address except
in the case of an an IANA reserved address (see the Baseline
Requirements, section 11.1.2 Authorization for an IP Address).
Additionally, RFC 5280 allows IP addresses in section 4.2.1.6 Subject
Alternative Name. So its not clear to me why a more restrictive policy
is called out.

I also understand an IP address for a host can change. But in the case
a public IP address has been previously bound to a public key by way
of an authority, it again seems more restrictive.

*If* the proposed standard is trying to guard against some threats
posed by the Domain Name System, IANA reserved addresses, RFC 1918
addresses and similar, then that should be listed under Goals and/or
Threats.

***** (12) *****

>From 2.6. Validating Pinned Connections:

   … It is acceptable to allow Pin
   Validation to be disabled for some Hosts according to local policy.
   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform).

OK, this is the reason for the proposed title change in (1). This is
also the reason for the list of goals and threats in (2) and (3). Its
just not clear to me (at the moment) how a known good pinset can be
broken to facilitate proxying/interception in a proposed standard for
a security control that's supposed to stop that kind of funny
business.

Also, as far as document flow is concerned, I think the sentences
quoted above should be removed from the second paragraph and placed as
the last stand alone paragraph in that section. I think it should be
moved because it breaks the flow of the discussion of "what to do"
with a discussion of the related topic of "not doing what you should
be doing".

***** (13) *****

>From 2.6. Validating Pinned Connections:

   UAs send validation failure reports only when Pin Validation is
   actually in effect.  Pin Validation might not be in effect e.g.
   because the user has elected to disable it, or because a presented
   certificate chain chains up to a user-defined trust anchor.  In such
   cases, UAs SHOULD NOT send reports.

If I am reading/parsing this correctly: adversaries want to be able to
surreptitiously MitM the channel, and they don't want a spotlight
shone on them while doing it.

As worded, the last two sentences are a tremendous blow to
transparency. The users and the site owner who are being
proxy'd/intercepted have a right to know what's occurring on his/her
[supposed] secure channel. In addition, the community has a right to
know how widespread potential problems are.

Users and sites have a right to know because non-trivial data is
sometimes traversing the channel, like site passwords and confidential
company information. Some organizations and verticals have auditing
and compliance requirements, so reporting a breach/loss of that data
is required. The community has a right to know so the breadth of the
problem can be ascertained, and plans of action can be formulated and
action taken.

Some proxying/interception performed by third parties or externalities
could be illegal in some jurisdictions, so the user or site will need
the evidence if they desire to have it addressed more formally. In the
US, I believe the law is the Computer Fraud and Abuse Act.

The perceived risk of a lawsuit could help stop some of the
unauthorized proxying/interception because some organizations will
weigh the risk with the reward. Considering this proposal is a
security control to stop unauthorized proxying/interception, that's a
win-win.

IETF leadership: Carl Sagan once asked, who speaks for the Earth. Who
here speaks for the users and sites? Does it *really* sound like a
good idea to suppress evidence of validation failures and unauthorized
overrides for a security control that's specifically designed to
contend with the threats?

***** (14) *****

2.7. Interactions With Preloaded Pin Lists:

   The effective policy for a Known Pinned Host that has both built-in
   Pins and Pins from previously observed PKP header response fields is
   implementation-defined.

In the name of transparency, the site should receive at least one
report detailing the issue. The site should be able to specify the
frequency of the reports so it can assess the breadth of the reported
issue.

***** (15) *****

2.8. Pinning Self-Signed End Entities

Kudos for this section. I think it fits nicely with Viktor Dukhovni's
Opportunistic Security.

***** (16) *****

Overrides are mentioned once in section 2.7. They effectively allow an
adversary to break known good pinsets and subvert the secure channel.
Section 4. Security Considerations does not discuss the impact of an
override.

The impact of overrides should be discussed so that sites and software
architects can ensure the security control meets expectations and
properly assess risk.

In addition, for browsers (which the proposed standard appears to
target), discarding the user's wishes is a violation in Priority of
Constituencies [5]; and violates the user and site's expectation of
Secure By Design [6]. So its not clear to me how useful the proposal
will be for browsers and other UAs that follow the W3C's Design
Principles. But I think things can be improved so that the proposed
standard does satisfy them.

In the above, I claim the user typing HTTPS (or a site redirecting to
HTTPS) is an indicator that a secure connection to a site is desired,
and not a connection to folks who would like to proxy the connection
for them. By not delivering what they asked, the proposal falls short
of both Priority of Constituencies and Secure By Design.

***** (17) *****

There is no consideration for a site to set policy on overrides. That
is, a site should be able to determine whether it wants to allow
proxying/interception, and not an externality. Sites offering HTTPS,
and other security controls like HSTS or CSP, are strong indicators
that sites care about these things.

Sites should be allowed to set policy on overrides, just like they can
set HSTS or CSP policy.

IETF leadership: Who here speaks for the users and sites?

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

Sorry for the long post, and thanks for taking the time for consideration.

Jeffrey Walton

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

[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf
[2] https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
[3] http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
[4] https://www.ietf.org/mail-archive/web/websec/current/msg02261.html
[5] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
[6] http://www.w3.org/TR/html-design-principles/#secure-by-design

---

From: Yoav Nir <[email-masked]>
Date: Fri, 2 Jan 2015 14:26:35 +0200

Hi, Jeffrey

Thanks for the review.

However, if you look at the datatracker link ([1]), you’ll see that this draft has been approved by the IESG 2.5 months ago. Its publication as RFC is only waiting for a referenced document to be published.

I’m afraid it’s too late now.

Yoav

[1] https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/history/

> On Jan 2, 2015, at 7:21 AM, Jeffrey Walton <[email-masked]> wrote:
> 
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 2 Jan 2015 13:18:34 -0800

>  https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21.

Hi Jeffrey,

Though I see Yoav has already mentioned that these comments are well
beyond the IETF LC phase, thus will not result in any changes to the
document, I do want to take the time to reply to your comments and explain
on a more substantive grounds why no changes are warranted, even if there
were still opportunity for change.

My fear is that this reply may encourage further discussion, and while I'm
certainly happy to provide further clarifications, I do think it is
important to keep in mind Yoav's remarks on changes.

<snip>

This isn't so much a technical argument as quibbling over naming. I'm not
sure why you feel that "User Agent" is somehow a narrowing of focus -
anything that processes an HTTP header for a user is surely a User Agent,
and anything not processing HTTP headers surely shouldn't care about HTTP
headers.

<snip>

Useful feedback, and perhaps more could have been detailed that would have
avoided some apparent confusion over the goals, but as noted, not likely
to result in substantive changes.

I think the discussion on the mailing list on the document serves as a bit
of a living discussion over the security goals, and I hope this message
(and the contents below) will help further clarify the non-goals.

<snip>

I think these comments fall into the same as (2)

This seems merely a disagreement on terminology. It would be equivalent to
say "Key pinning, as described in this document, is a ..."

<snip>

While I understand that you were confused by this, I'm not sure I agree
with the language being the source of the confusion or the proposed
changes being useful to avoiding that confusion.

<snip>

This seems to be minor textual quibbles and would not be something I think
would have been terribly useful to change.

<snip>

Possibly something to fix once it goes through the editor's queue fixing
up typographic and grammatical issues, although I'm not sure. Thanks for
highlighting this.

<snip>

Renaming the header would be a non-starter. Among other reasons, I would
note the parallel here to Content-Security-Policy-Report-Only.

While I can see how you reached your interpretation, it's also entirely
reasonable to reach the correct conclusion from the text. As you note, the
text certainly expounds upon its non-exclusivity, and nothing in the text
(beyond your interpretation of the header name) supports your conclusion
of mutual exclusivity.

They're anonymous - e.g. they lack authenticity, aka a key binding. If
you're binding a key, you're effectively authenticating the peer.

Perhaps you're describing something like "opportunistic encryption", in
which case, no, it would not be supported. The threat model in 4.5
hopefully makes it obvious why this would be bad.

>  browsers and other UAs, but browsers follow the CA/B.

Perhaps you meant the CA/Browser Forum's Baseline Requirements? In which
case, no, browsers don't follow the BRs - the BRs follow the browsers.

>  The CA/B does

I think it's a reasonable critique that we did not expound upon why IP
Addresses were forbidden from setting policy. As you note, currently the
CA/Browser Forum Baseline Requirements (and the browser policies that the
BRs are modeled after) permit publicly trusted certificates to IP
addresses.

This requirement is inherited from RFC 6797, which this document was
originally proposed as an extension of, and is documented in Appendix A,
Item 4 ( http://tools.ietf.org/html/rfc6797#appendix-A )

This is, as I understand it, your main point of contention.

Rather than write a full rebuttal, I'd rather point you to
http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-
which describes the design rationale.

In short, what you describe is a tension between the server operator (who
wishes to express a cryptographic policy) and the user (who wishes to use
their machine however they see fit). In such battles, User Agents (aka
things that processes requests for the user) implicitly and explicitly
choose to favour the user (for whom they act for) rather than the server.

Then no, you're not reading it properly.

This is about protecting user privacy and their rights, rather than the
server's goals. As discussed in this group in the past, it's quite silly
to suggest that the server should be able to violate the users' rights or
privileges with some header - as silly as setting an evil bit (RFC 3514)

For example, consider popular anti-virus solutions that do local MITM for
purposes of traffic inspection/protection. The user has chosen to grant
this program the capability to do so (such as by installing its trust
anchor), and derives great benefit from doing so.

Such MITM software may (and often does) include the authorized users' name
and other personally identifying details (such as a license number) within
the certificate it uses to intercept.

Under today's web security model, there is no way for the remote server to
get access to this data, and that is a GOOD thing. Even if the certificate
didn't contain any PII, the very key of the issuing certificate itself
would represent a stable identifier that could be tracked across browsing
sessions, since each key would be unique per user.

This is not a "tremendous blow to transparency", as you note. This is
about protecting users' privacy.

This is not about violating the users right to know they're being
proxy'd/intercepted - they're already aware of it, because only they could
have authorized it. If you're concerned that the user may not have
authorized it, then I would remind you of the Immutable Laws of Security -
particularly 2 and 3.
http://technet.microsoft.com/en-us/magazine/2008.10.securitywatch.aspx

<snip>
>  contend with the threats?

This spec speaks for the users, by ensuring that local privacy rights
trump remote server policy.

If this spec failed to respect the users' right to privacy, and disclose
to a remote server details that they would not otherwise have access to,
then it would just be a silly little arms race where the end result was
exactly what was specified - anyone doing this would block the reporting
(and rightfully so), as it would offer persistent tracking of users.

Remote policy requests CANNOT trump local security policy, full stop.

Implementation defined is implementation defined.

MAY is MAY.

<snip>

I think all of what you said is wrong here, for reasons expounded upon in
both (13) and in
http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-
. That is, everything you site as arguments for your interpretation are
exactly the same reasons why it does NOT do what you wish, and why it
would be terrible to do so.

The device owner has expressly authorized the interception. They are the
first constituent. Your remote server operator has far less priority than
them, nor can you argue that there is any way to protect users who are not
the device owners - this is one of the immutable law of security.

<snip>

This is just a restatement of (16) and (13).

The users' wishes - including allowing interception - trump the remote
servers wishes.

Though the remote server may not wish to allow the users' anti-virus to
protect them (and I can think of plenty hostile malware sites that would
want such a control), the users' wishes trump all.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 08 Jan 2015 20:21:09 +0900

Hello Chris, Chris, Ryan, and everybody,

A student of mine is working on a small client-side implementation of 
key pinning. For testing, we would like to know sites that already send 
the respective headers (Public-Key-Pins and/or 
Public-Key-Pins-Report-Only). Any replies on the list or in private 
appreciated.

Regards,   Martin.

---

From: Joseph Bonneau <[email-masked]>
Date: Thu, 8 Jan 2015 14:54:04 +0000

Hello Martin,

For our upcoming NDSS paper (
http://www.jbonneau.com/doc/KB15-NDSS-hsts_pinning_survey.pdf), we did a
crawl of the top 1M Alexa Domains plus every domain in Chrome's preloaded
list, we observed attempts to set PKP headers at the domains listed below.
Note some of these are set incorrectly (see Section IV-F of the paper).
Best of luck with your research.

Joe

amateurdumper.com

amigogeek.net

detectify.com

forumdenge.com

frederik-braun.com

freenetproject.org

freitag.de

homemakinghacks.com

kitapyurdu.eu

segu-info.com.ar

skysportsng.com

steventress.com

timtaubert.de

tone-and-tighten.com

webstars2k.com

www.deagostini.jp

www.ilireg.ir

www.metrotimes.com

www.mnot.net

www.munsterrugby.ie

www.pennydellpuzzles.com

www.userstyles.org

On Jan 8, 2015 11:22 AM, Martin J. Dürst <[email-masked]> wrote:

> A student of mine is working on a small client-side implementation of key
> pinning. For testing, we would like to know sites that already send the
> respective headers (Public-Key-Pins and/or Public-Key-Pins-Report-Only).
> Any replies on the list or in private appreciated.
>
> Regards,   Martin.
>

---

From: Pawel Krawczyk <[email-masked]>
Date: Thu, 8 Jan 2015 15:50:23 +0000

27 of them found here http://webcookies.org/http-headers/public-key-pins/

> On 8 Jan 2015, at 11:21, Martin J. Dürst <[email-masked]> wrote:
> 
> A student of mine is working on a small client-side implementation of key pinning. For testing, we would like to know sites that already send the respective headers (Public-Key-Pins and/or Public-Key-Pins-Report-Only). Any replies on the list or in private appreciated.
> 
> Regards,   Martin.
> 

-- 
Pawel Krawczyk
[email-masked] +44 7879 180015
CISSP, OWASP