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

From: [email-masked]
Date: Mon, 28 Apr 2014 16:10:41 -0700

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-12.txt
	Pages           : 25
	Date            : 2014-04-28

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-12

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

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: Tue, 29 Apr 2014 09:24:55 +0300

Thank you Chris, Chris, and Ryan.

Having reviewed this, I think this version addresses all the issues raised during WGLC. 

Unless someone hollers, we’re going to send this to Barry early next week, so please take this time to read the draft one more time.

Thanks!

Tobias and Yoav

On Apr 29, 2014, at 2:10 AM, [email-masked] wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 30 Apr 2014 14:41:17 -0700

> Having reviewed this, I think this version addresses all the issues raised during WGLC.

The added sentence in 2.7 on preloaded/dynamic pins doesn't match the
rest of the text, which is written to mandate specific behavior.  If
we're not going to discuss implementation alternatives, we should just
delete most of 2.7 and let implementations do what they want.

The text in 2.3.2 on PKP-RO doesn't really match the rest of the doc.
Most of the draft is written as if there is a single header, set of
Pinning Metadata, and "Known Pinned Host" state.  But 2.3.2 doubles
those things, which causes many minor ambiguities, e.g.:

 * 2.2.1 - "a Pinned Host SHOULD include in its response exactly one
PKP header field"

 * 2.3.1 - "the UA MUST process only the first such header field"

 * 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? (or
new "report-only" pins)?

 * 2.6 mandates "When a UA connects to a Pinned Host, if the TLS
connection has errors, the UA MUST terminate the connection without
allowing the user to proceed".  It's unclear whether a "report-only"
pin counts as a "Pinned Host" for the purpose of other TLS errors.

The draft could use an editing/cleanup pass to clarify all this.

Also, some of the issues I've been bringing up since July need to be addressed:

 * Interaction with cookies needs discussion, at least in security
considerations.  Cookie scoping rules pose a serious problem for
pinning, e.g. a pin at "example.com" could be undermined by a MITM
inventing a "badguy.example.com" and using it to steal or force
cookies.

 * "Pinning Policy" and "Pinning Metadata" are synonyms?
 * 2.3.1 ... "or," ... "Otherwise" is confusing
 * 2.6 - is pin validation performed on resumed TLS connections?
 * 3 - can UAs provide additional JSON fields inside the report?
 * The term "validated certificate chain" is not defined
 * An IANA registry is needed for directives
 * The acknowledgement for "pin break codes" is ancient/irrelevant

Trevor