Subject: [websec] Richard Barnes' Yes on draft-ietf-websec-key-pinning-19: (with COMMENT)

From: "Richard Barnes" <[email-masked]>
Date: Wed, 06 Aug 2014 12:23:08 -0700

Richard Barnes has entered the following ballot position for
draft-ietf-websec-key-pinning-19: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

----------------------------------------------------------------------
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".  :)

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 6 Aug 2014 13:00:43 -0700

> http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Note, same issue applies to http://tools.ietf.org/html/rfc6797#section-8.1,
which is the source of this language.

This appears to be RFC 7230 changing the rules that RFC 2616 set out,
incompatibly.

RFC 2616 reads
"Multiple message-header fields with the same field-name MAY be present in
a message if and only if the entire field-value for that header field is
defined as a comma-separated list [i.e., #(values)]"

In this respect, both this draft and 6797 are compliant with 2616.

RFC 7230 changes this, incompatibly, to read
"A sender MUST NOT generate ... unless it's defined as a comma-separated
list [i.e., #(values)] or the header field is a well-known exception"
"A recipient MAY combine multiple header fields with the same field name,
..., without changing the semantics of the message, by appending each
subsequent field value to the combined field value in order, separated by
comma."

So this is clearly something that 7230 changed from 2616, in a way that
provides a more liberal interpretation than 2616 allows.

As addressed earlier on review, because semi-colons are used, if a
recipient did coalesce, then such a header injection would cause the
pinning header to be ignored (as invalid), rather than processed. That
still seems to be acceptable behaviour - e.g. no language change required.

> like it would be more effective to make the recommendation in Section 4.3

I'm not sure what you see as a viable change. There's no way that a UA can
confirm a Backup Pin is a valid backup pin, short of requiring the key be
online and capable of proving itself, which is precisely what having a
backup pin is to help you avoid.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Aug 2014 16:22:41 -0400

> still seems to be acceptable behaviour - e.g. no language change required.

Fair enough.  I hadn't seen your response to Pete.

> backup pin is to help you avoid.

I guess I'm just saying that forcing the server to present a backup pin is
kind of ineffective, precisely because the UA can't verify that it's
actually a backup pin.  So I'm not sure that having this requirement will
result in much more backup pinning than the recommendations in 4.3,
especially if those recommendations were made stronger or more prominent.

But if the WG thinks the requirement for a backup pin is worth the effort,
it is specified interoperably, so I'm not going to stand in the way.

--Richard

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Aug 2014 01:12:00 +0300

> like it would be more effective to make the recommendation in Section 4.3

I don’t think we can force a site to do thing securely with any protocol. TLS and the like require "32 bytes generated by a secure RNG” here and “nonce” there, yet the peer has no way of checking whether an implementation uses a 64-bit LFSR for the former and a hard-coded value for the latter. We’re hoping this requirement will steer them in the right direction, but there are no guarantees.

> But if the WG thinks the requirement for a backup pin is worth the effort, it is specified interoperably, so I'm not going to stand in the way.

It does. Besides, generating a real key is as easy as generating a fake one:
  openssl genrsa -out private 2048
  openssl rsa -in private -putout -outform DER -out public
  openssl dgst -sha256 -binary public | base64

> "How-To-Not-Brick-Your-Site Considerations".  :)

We felt that not bricking your site was very important. And it is security-relevant. If you don’t do these things, then a key compromise is augmented by a long-lasting DoS. If you don’t follow the advice, then this security mechanism actually makes the attacks worse.

Yoav