Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-21

[Ballot comment]

Thanks for clearing up my discuss points. One possible
remaining nit though:

- In 2.2 you say: "(1) the processing rules for HTTP
  request messages received over a secure transport (e.g.
  authenticated, non-anonymous TLS); "

Should the "e.g." be an "i.e." ? It's probably fine either
way but just wondered.

-- OLD comments below, didn't check 'em

abstract and elswhere: SubjectPublicKeyInfo doesn't usually
have spaces between the terms. No big deal. After the abstract
would a ref to 5280 be right for SPKI as well?

general: I think emphasising the backup pin requirement in the
intro would be good. It's a little hidden now and would be a
surprise to some I bet.

2.1 - pin-directive has the literal "pin-" but later you say
(in bullet #3) that directive names are case insensitive.  Does
that apply to "pin-" as well or not?

2.1 - has some typos: reistry and hahs

2.1 - "Known Pinned Host" would be a fine term to define in a
section 1.1 that was renamed via s/Requirements
Language/Terminology/

2.1.1 - max-age is really defined against the time of reception
and not (in principle) from when its emitted?  I know that
makes no difference now, but with a sufficient latency (e.g.
Earth->Mars, min 4 mins, max 20 mins, and yes my DTN heritage
is showing:-) it could, just about. I think to be pedantically
correct, max-age ought be defined versus the time of emission
and not receipt.

2.1.2 - uses the term "Pinned Host" which is not the same as
the previously used "Known Pinned Host" - is the distinction
meant to be significant or is that a typo?

2.1.3/section 4 - shouldn't the potential DoS issues be
discussed for cases where report-uri != same-origin? E.g.  if
busy-site.example.net (is hacked and) sets report-uri to
victim.example.com (maybe with some HTML/JS that generates
loads of queries to the victimj) that'd be like getting /.'d I
think that's maybe worth noting in the security considerations
or in 2.1.3 where you (quite properly) say to rate-limit
reporting. If you'd rather not say why though, that's ok too.

[Ballot comment]
I've cleared my DISCUSS.  For the record, here it is, but there is no further action required:

This mechanism relies on there being no MiTM attack from a compromised signing key either prior to a legitimate pinning, or in a situation where the host being "protected" doesn't actually do pinning.  I think this should be mentioned in the security considerations section.  I raise this to the level of DISCUSS because I think this actually creates a new attack surface for government censorship: you MiTM the host you're attacking, pin it to a cert signed using a compromised CA, and then that UA can't communicate with the host again for the duration of the pin.

The scenario would be that the government has a transparent web cache in the path between the host and the UA, and the web cache pins false cert for hosts that are being censored.  Now even if the user sets up a tunnel to bypass the transparent cache, they can't access the censored site, so they conclude that the site is down and abandon the tunnel.  I could easily see this being used in a scenario like the recent DNS censorship in Turkey.

Setting a lower maximum pin age mitigates the damage of such attacks if the user keeps the tunnel up for the duration of the pin, but I don't think it's realistic to assume that they will.  I think that the only way to mitigate this attack is to have a mechanism whereby conflicting DANE TLSA information overrides the pin.  This would allow a site being attacked in this way to securely inform the UA that the pin was invalid.  The government could of course prevent DNSSEC validation, but the UA could take this as another signal to drop the pin: if the zone where the TLSA record should be fails to validate (as opposed to isn't signed, which wouldn't signify anything), the pin is likely a censorship attempt.

[Ballot discuss]

-20 doesn't cover this, the WG are on the job apparently

-- my discuss

Good doc. Two things I'd like to check before moving to a yes
ballot:

(1) 2.1 - Can a simple-directive start with "pin-"?  Seems like
yes it can, but then the ABNF is ambiguous about the RHS of the
"=" I think, is that right? Its no big deal since valid values
will parse anyway, so only an issue if you ever care about
simple-directive vs. pin-directive. Ah - does the last para of
2.1 mean that this distinction is needed really?

(2) 2.1.3 says that "If the scheme in the report-uri is one
that uses TLS (e.g.  HTTPS), UAs MUST perform Pinning
Validation when the host in the report-uri is a Known Pinned
Host;" That's generally ok, however, I think it may break for
alt-svc, where TLS is used but https is not, or if TCPINC
decided on a TLS based solution then some coder might get it
wrong. I think a simple re-statement in terms of http vs. https
URIs should fix this. I realise that neither alt-svc nor TCPINC
existed when this work started, but since they now do it'd pay
to think about them and I don't recall seeing that on the
websec list (apologies if I'm wrong there).  The IFF in 2.5
also seems related.  2.2 has same issues about alt-svc and
TCPINC. I do see that you only say "e.g. TLS" here but
wonder nonetheless, e.g. would 2.2.1 cover an alt-svc case
or not?

[Ballot discuss]
This mechanism relies on there being no MiTM attack from a compromised signing key either prior to a legitimate pinning, or in a situation where the host being "protected" doesn't actually do pinning.  I think this should be mentioned in the security considerations section.  I raise this to the level of DISCUSS because I think this actually creates a new attack surface for government censorship: you MiTM the host you're attacking, pin it to a cert signed using a compromised CA, and then that UA can't communicate with the host again for the duration of the pin.

The scenario would be that the government has a transparent web cache in the path between the host and the UA, and the web cache pins false cert for hosts that are being censored.  Now even if the user sets up a tunnel to bypass the transparent cache, they can't access the censored site, so they conclude that the site is down and abandon the tunnel.  I could easily see this being used in a scenario like the recent DNS censorship in Turkey.

Setting a lower maximum pin age mitigates the damage of such attacks if the user keeps the tunnel up for the duration of the pin, but I don't think it's realistic to assume that they will.  I think that the only way to mitigate this attack is to have a mechanism whereby conflicting DANE TLSA information overrides the pin.  This would allow a site being attacked in this way to securely inform the UA that the pin was invalid.  The government could of course prevent DNSSEC validation, but the UA could take this as another signal to drop the pin: if the zone where the TLSA record should be fails to validate (as opposed to isn't signed, which wouldn't signify anything), the pin is likely a censorship attempt.

[Ballot discuss]


Good doc. Two things I'd like to check before moving to a yes
ballot:

(1) 2.1 - Can a simple-directive start with "pin-"?  Seems like
yes it can, but then the ABNF is ambiguous about the RHS of the
"=" I think, is that right? Its no big deal since valid values
will parse anyway, so only an issue if you ever care about
simple-directive vs. pin-directive. Ah - does the last para of
2.1 mean that this distinction is needed really?

(2) 2.1.3 says that "If the scheme in the report-uri is one
that uses TLS (e.g.  HTTPS), UAs MUST perform Pinning
Validation when the host in the report-uri is a Known Pinned
Host;" That's generally ok, however, I think it may break for
alt-svc, where TLS is used but https is not, or if TCPINC
decided on a TLS based solution then some coder might get it
wrong. I think a simple re-statement in terms of http vs. https
URIs should fix this. I realise that neither alt-svc nor TCPINC
existed when this work started, but since they now do it'd pay
to think about them and I don't recall seeing that on the
websec list (apologies if I'm wrong there).  The IFF in 2.5
also seems related.  2.2 has same issues about alt-svc and
TCPINC. I do see that you only say "e.g. TLS" here but
wonder nonetheless, e.g. would 2.2.1 cover an alt-svc case
or not?

[Ballot comment]


abstract and elswhere: SubjectPublicKeyInfo doesn't usually
have spaces between the terms. No big deal. After the abstract
would a ref to 5280 be right for SPKI as well?

general: I think emphasising the backup pin requirement in the
intro would be good. It's a little hidden now and would be a
surprise to some I bet.

2.1 - pin-directive has the literal "pin-" but later you say
(in bullet #3) that directive names are case insensitive.  Does
that apply to "pin-" as well or not?

2.1 - has some typos: reistry and hahs

2.1 - "Known Pinned Host" would be a fine term to define in a
section 1.1 that was renamed via s/Requirements
Language/Terminology/

2.1.1 - max-age is really defined against the time of reception
and not (in principle) from when its emitted?  I know that
makes no difference now, but with a sufficient latency (e.g.
Earth->Mars, min 4 mins, max 20 mins, and yes my DTN heritage
is showing:-) it could, just about. I think to be pedantically
correct, max-age ought be defined versus the time of emission
and not receipt.

2.1.2 - uses the term "Pinned Host" which is not the same as
the previously used "Known Pinned Host" - is the distinction
meant to be significant or is that a typo?

2.1.3/section 4 - shouldn't the potential DoS issues be
discussed for cases where report-uri != same-origin? E.g.  if
busy-site.example.net (is hacked and) sets report-uri to
victim.example.com (maybe with some HTML/JS that generates
loads of queries to the victimj) that'd be like getting /.'d I
think that's maybe worth noting in the security considerations
or in 2.1.3 where you (quite properly) say to rate-limit
reporting. If you'd rather not say why though, that's ok too.

[Ballot discuss]
Overall the draft is very good, thank you for writing it.  I just wanted to discuss some of the security/privacy considerations and see if we could improve the language and make sure the set of concerns are clear.

The privacy consideration section reads more like possible attack scenarios that would fit into the security considerations.  What privacy related concerns result from these attacks?  Having that spelled out to differentiate the risks as privacy only would be helpful (if appropriate) or moving this into the security consideration section *IF* it is more generically applicable.  If I am missing something and this is only privacy related, it would be good to understand that in this discussion.  Adding some text on how these attacks could be used to expose privacy related information would be helpful too.

For the first example, it seems it is the possibility that a report goes outside out the intended scope is the concern.  The mitigation seems to be provided in the last sentence of #4, but couldn't this be other information leakage and not just privacy?  Let me know if I am missing something that explains why this is privacy specific.

In #3 of the second example, the last sentence includes the following clause:
          and giving some UAs no
          Valid Pinning Header for other subdomains (causing subsequent
          requests for m.fingerprint.example.com to succeed).

Does this mean that these subdomains are succeeding when they should fail?  It might just be me, but that is not clear in the text (or if they are supposed to succeed).  It sounds like they are not supposed to succeed and this is the security issue.  How is this privacy specific?  Again, this may just be me, but an explanation would be helpful.

In the last sentence of the privacy considerations section, what is meant by the description "forensic attacker"?  I find this term confusing.  Was this intended to mean that techniques used in forensic analysis could be used by an attacker to discern information that could be of interest?  If that's the case, I think it would be clearer to the reader if that were stated instead.

[Ballot comment]
I agree with Richard's comment that the document is well written and an important document, thank you for writing it.  The style changed a little toward the end and I had some trouble with long sentences in the security & privacy considerations sections.  This should be easy enough to fix and may be done with the RFC editor anyway.

To Richard's point on operational concerns versus security concerns, are there explicit security attacks that could occur with the max-age variations described? 

In 4.2, I can't see this being more than an operational concern since it fails when overlapping pin sets are not used.  Are we missing a gap that leads to a security concern?

4.3 makes sense to me as a security concern that drives operational practices.

[Ballot comment]
This is an important document, and overall clearly written.  There are a few points that it would be good to clean up.


Introduction: "At least one UA..."

FWIW, this is now "At least two UAs..."  Firefox also has a manual pin list as of version 32, currently in Beta.


Introduction: "but is possible to pin keys without requiring HSTS"

-> "but it is ... and vice versa."


Section 2.2.2. "Pinned Hosts SHOULD NOT include..."

This applies not just to Pinned Hosts, but to any web host, right?


Section 2.3.1. "If a UA receives more than one PKP header field ... only the first PKP-RO header field (if present)"

This seems problematic in light of the fact that HTTP recipients are allowed to coalesce the values of multiple header fields.
http://tools.ietf.org/html/rfc7230#section-3.2.2

So, for example, if header coalescing were done at a lower layer in the HTTP stack than HPKP, then the pinning code wouldn't be able to distinguish "first" vs. "rest".  On the other hand, maybe this is a use case for using semicolons as separators, since the combined header field would not be valid.  In either case, there's a need for updated text.


Section 2.5. "at least one Pin that does NOT refer to an SPKI in the certificate chain"

I understand the motivation for this, but this doesn't actually force the site to have a backup pin -- they can just make up a pin value.  It seems like it would be more effective to make the recommendation in Section 4.3 stronger.


Section 4. "Security Considerations"

Most of these seem more like "Operational Considerations" or "How-To-Not-Brick-Your-Site Considerations".  :)

[Ballot comment]
I agree with Pete's comment about the first sentence.

It would be nice if in Section 5 or 7 some suggestion could be made for UAs to consider the relationship between the functionality they provide to clear pins/pinned hosts and the functionality they provide to clear (or prevent the storage of) other UA state. E.g., upon clearing one's browsing history or entering private browsing mode, it seems like having the option to clear pins/pinned hosts or not pin would make sense. This is alluded to in Section 7 but not really tied to the threat described in Section 5.

I'm also curious about whether there is any reason to retain expired pins? (Other than the fact that flushing them requires the UA to actively check which ones are expired.)

[Ballot comment]
1: The first sentence is quite confusing. Might I suggest instead:

  This document defines a new HTTP header that enables user agents
  (UAs) to determine which Subject Public Key Info (SPKI) structures
  will be present in the web host's certificate chain in future TLS
  [RFC5246] connections.

2.1:

  Public-Key-Directives = [ directive ] *( OWS ";" OWS [ directive ] )

Are you sure that's correct? First of all, it may be completely empty. That seems like something you wouldn't want. Second of all, it allows for semicolons without directives between them, which may or may not be what you want. It's not clear to me why you made this semicolon-delimited instead of comma-delimited, which would be much more in line with the rest of HTTP. Then you'd simply get:

  Public-Key-Directives = 1#directive

But if you insist on semicolons, you want either:

  Public-Key-Directives = directive *( OWS ";" OWS directive )

or if you want to allow for empty elements:

  Public-Key-Directives = *( ";" OWS ) directive *( OWS ";" [ OWS
    directive ] )
   
If the following is acceptable:

  Public-Key-Directives: ;;;;;

then your original is fine.

s/hahs/hash

10.1:

Update 4627 to 7159

I think W3C.REC-html401-19991224 is informative. This document says that you MUST NOT do what's in that document.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-websec-key-pinning-19.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has a question/comment about the action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/

two message headers are to be registered as follows:

Header Field Name: Public-Key-Pins
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

Header Field Name: Public-Key-Pins-Report-Only
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be ]

IANA Question -> The Permanent Message Header Field Names registry is managed via Expert Review as defined by RFC 5226. We have initiated a request and sent this to the designated expert for review.

IANA understands that this is the only action required to be completed upon approval of this document.


Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Public Key Pinning Extension for HTTP) to Proposed Standard


The IESG has received a request from the Web Security WG (websec) to
consider the following document:
- 'Public Key Pinning Extension for HTTP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes an extension to the HTTP protocol allowing
  web host operators to instruct user agents 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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ballot/


No IPR declarations have been submitted directly on this I-D.

Summary
=======

This document is a product of the WebSec working group intended to be
published as a standards-track RFC. Yoav Nir is the document
shepherd. Barry Leiba is the responsible Area Director.

This memo describes an extension to the HTTP protocol allowing web
host operators to instruct user agents 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.

Review and Consensus
====================

Previous versions of this document received useful reviews on the
mailing list. Many changes were introduced due to working group
consensus, including to pin format, an includeSubdomains directive,
and interaction with private trust anchors.

Some changes were proposed and rejected by the working group, most
notably named pins, a "strict" directive, and hard limits on the
max-age directive. The consensus on these involved a long and hard
discussion, but as chairs, Tobias and I believe that it is a regular
rather than rough consensus.

Two issues that were left for last were the interaction of pre-loaded
pins with noted pins, and the processing of report-only pins. There
was a lot of controversy and a lot of back-and-forth about these
issues. We believe that the current drafts represents the working
group's consensus, although at least one participant would have
preferred a different outcome.


Intellectual Property
=====================

Each author has confirmed conformance with BCPs 78 and 79.


Other Points
============

The document makes a normative reference to
draft-josefsson-pkix-textual-03 for the format of the
served-certificate-chain field in the failure report described in
section 3. The authors of that draft have asked Stephen Farrell to
sponsor the draft, and he will if the people on the PKIX list agree. 

The document includes some ABNF in section 2.1. It seems clear enough
but it has not been reviewed by an ABNF doctor.

Downward references:
  RFC 6234 - already in downref registry