draft-ietf-websec-key-pinning-14.txt   draft-ietf-websec-key-pinning-15.txt 
Web Security C. Evans Web Security C. Evans
Internet-Draft C. Palmer Internet-Draft C. Palmer
Intended status: Standards Track R. Sleevi Intended status: Standards Track R. Sleevi
Expires: December 14, 2014 Google, Inc. Expires: December 18, 2014 Google, Inc.
June 12, 2014 June 16, 2014
Public Key Pinning Extension for HTTP Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-14 draft-ietf-websec-key-pinning-15
Abstract Abstract
This memo describes an extension to the HTTP protocol allowing web This memo describes an extension to the HTTP protocol allowing web
host operators to instruct user agents to remember ("pin") the hosts' host operators to instruct user agents to remember ("pin") the hosts'
cryptographic identities for a given period of time. During that cryptographic identities for a given period of time. During that
time, UAs will require that the host present a certificate chain time, UAs will require that the host present a certificate chain
including at least one Subject Public Key Info structure whose including at least one Subject Public Key Info structure whose
fingerprint matches one of the pinned fingerprints for that host. By fingerprint matches one of the pinned fingerprints for that host. By
effectively reducing the number of authorities who can authenticate effectively reducing the number of authorities who can authenticate
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2014. This Internet-Draft will expire on December 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
2.3.2. Interaction of Public-Key-Pins and Public-Key-Pins- 2.3.2. Interaction of Public-Key-Pins and Public-Key-Pins-
Report-Only . . . . . . . . . . . . . . . . . . . . . 9 Report-Only . . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Noting a Pinned Host - Storage Model . . . . . . . . 10 2.3.3. Noting a Pinned Host - Storage Model . . . . . . . . 10
2.3.4. HTTP-Equiv <Meta> Element Attribute . . . . . . . . . 11 2.3.4. HTTP-Equiv <Meta> Element Attribute . . . . . . . . . 11
2.4. Semantics of Pins . . . . . . . . . . . . . . . . . . . . 11 2.4. Semantics of Pins . . . . . . . . . . . . . . . . . . . . 11
2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Validating Pinned Connections . . . . . . . . . . . . . . 13 2.6. Validating Pinned Connections . . . . . . . . . . . . . . 13
2.7. Interactions With Preloaded Pin Lists . . . . . . . . . . 14 2.7. Interactions With Preloaded Pin Lists . . . . . . . . . . 14
2.8. Pinning Self-Signed End Entities . . . . . . . . . . . . 14 2.8. Pinning Self-Signed End Entities . . . . . . . . . . . . 14
3. Reporting Pin Validation Failure . . . . . . . . . . . . . . 14 3. Reporting Pin Validation Failure . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 17 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 18
4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 17 4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 18
4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Interactions With Cookie Scoping . . . . . . . . . . . . 19 4.4. Interactions With Cookie Scoping . . . . . . . . . . . . 20
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Usability Considerations . . . . . . . . . . . . . . . . . . 21 7. Usability Considerations . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 21 9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 23 Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 24
Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 23 Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
We propose a new HTTP header to enable a web host to express to user We propose a new HTTP header to enable a web host to express to user
agents (UAs) which Subject Public Key Info (SPKI) structure(s) UAs agents (UAs) which Subject Public Key Info (SPKI) structure(s) UAs
SHOULD expect to be present in the host's certificate chain in future SHOULD expect to be present in the host's certificate chain in future
connections using TLS (see [RFC5246]). We call this "public key connections using TLS (see [RFC5246]). We call this "public key
pinning" (PKP). At least one UA (Google Chrome) has experimented pinning" (PKP). At least one UA (Google Chrome) has experimented
with the idea by shipping with a user-extensible embedded set of with the idea by shipping with a user-extensible embedded set of
Pins. Although effective, this does not scale. This proposal Pins. Although effective, this does not scale. This proposal
skipping to change at page 10, line 7 skipping to change at page 10, line 7
If a Host sets the PKP-RO header, the UA SHOULD note the Pins and If a Host sets the PKP-RO header, the UA SHOULD note the Pins and
directives given in the PKP-RO header as specified by the max-age directives given in the PKP-RO header as specified by the max-age
directive. If the UA does note the Pins and directives in the PKP-RO directive. If the UA does note the Pins and directives in the PKP-RO
header it SHOULD evaluate the specified policy and SHOULD report any header it SHOULD evaluate the specified policy and SHOULD report any
would-be Pin Validation failures that would occur if the report-only would-be Pin Validation failures that would occur if the report-only
policy were enforced. policy were enforced.
If a Host sets both the PKP header and the PKP-RO header, the UA MUST If a Host sets both the PKP header and the PKP-RO header, the UA MUST
note and enforce Pin Validation as specified by the PKP header, and note and enforce Pin Validation as specified by the PKP header, and
SHOULD note the Pins and directives given in the PKP-RO header. If SHOULD process the Pins and directives given in the PKP-RO header.
the UA does note the Pins and directives in the PKP-RO header it If the UA does process the Pins and directives in the PKP-RO header
SHOULD evaluate the specified policy and SHOULD report any would-be it SHOULD evaluate the specified policy and SHOULD report any would-
Pin Validation failures that would occur if the report-only policy be Pin Validation failures that would occur if the report-only policy
were enforced. were enforced.
2.3.3. Noting a Pinned Host - Storage Model 2.3.3. Noting a Pinned Host - Storage Model
The Effective Pin Date of a Known Pinned Host is the time that the UA The Effective Pin Date of a Known Pinned Host is the time that the UA
observed a Valid Pinning Header for the host. The Effective observed a Valid Pinning Header for the host. The Effective
Expiration Date of a Known Pinned Host is the Effective Pin Date plus Expiration Date of a Known Pinned Host is the Effective Pin Date plus
the max-age. A Known Pinned Host is "expired" if the Effective the max-age. A Known Pinned Host is "expired" if the Effective
Expiration Date refers to a date in the past. The UA MUST ignore all Expiration Date refers to a date in the past. The UA MUST ignore all
expired Known Pinned Hosts from its cache if, at any time, an expired expired Known Pinned Hosts from its cache if, at any time, an expired
skipping to change at page 13, line 12 skipping to change at page 13, line 12
Pins, includeSubDomains, and report-uri but future specifications and Pins, includeSubDomains, and report-uri but future specifications and
implementations might use additional directives. implementations might use additional directives.
Upon receipt of a PKP-RO response header field, the UA SHOULD Upon receipt of a PKP-RO response header field, the UA SHOULD
evaluate the policy expressed in the field, and SHOULD generate and evaluate the policy expressed in the field, and SHOULD generate and
send a report (see Section 3). However, failure to validate the pins send a report (see Section 3). However, failure to validate the pins
in the field MUST have no effect on the validity or non-validity of in the field MUST have no effect on the validity or non-validity of
the policy expressed in the PKP field or in previously-noted pins for the policy expressed in the PKP field or in previously-noted pins for
the Known Pinned Host. the Known Pinned Host.
The UA SHOULD NOT note any pins or other policy expressed in the PKP- The UA need not note any pins or other policy expressed in the PKP-RO
RO response header field. response header field, except for the purpose of determining that it
has already sent a report for a given policy. UAs SHOULD make a best
effort not to inundate report-uris with redundant reports.
2.6. Validating Pinned Connections 2.6. Validating Pinned Connections
When a UA connects to a Pinned Host, if the TLS connection has When a UA connects to a Pinned Host, if the TLS connection has
errors, the UA MUST terminate the connection without allowing the errors, the UA MUST terminate the connection without allowing the
user to proceed anyway. (This behavior is the same as that required user to proceed anyway. (This behavior is the same as that required
by [RFC6797].) by [RFC6797].)
If the connection has no errors, then the UA will determine whether If the connection has no errors, then the UA will determine whether
to apply a new, additional correctness check: Pin Validation. A UA to apply a new, additional correctness check: Pin Validation. A UA
skipping to change at page 14, line 5 skipping to change at page 14, line 5
is considered equivalent. is considered equivalent.
Although the UA has previously received Pins at the HTTP layer, it Although the UA has previously received Pins at the HTTP layer, it
can and MUST perform Pin Validation at the TLS layer, before can and MUST perform Pin Validation at the TLS layer, before
beginning an HTTP conversation over the TLS channel. The TLS layer beginning an HTTP conversation over the TLS channel. The TLS layer
thus evaluates TLS connections with pinning information the UA thus evaluates TLS connections with pinning information the UA
received previously, regardless of mechanism: statically preloaded, received previously, regardless of mechanism: statically preloaded,
via HTTP header, or some other means (possibly in the TLS layer via HTTP header, or some other means (possibly in the TLS layer
itself). itself).
If Pin Validation is not in effect (e.g. because the user has elected
to disable it, or because a presented certificate chain chains up to
a locally-installed anchor), and if the server has set a report-uri
in a PKP or PKP-RO header, the UA SHOULD NOT send any reports to the
report-uri for the given certificate chain.
2.7. Interactions With Preloaded Pin Lists 2.7. Interactions With Preloaded Pin Lists
UAs MAY choose to implement additional sources of pinning UAs MAY choose to implement additional sources of pinning
information, such as through built-in lists of pinning information. information, such as through built-in lists of pinning information.
Such UAs SHOULD allow users to override such additional sources, Such UAs SHOULD allow users to override such additional sources,
including disabling them from consideration. including disabling them from consideration.
The effective policy for a Known Pinned Host that has both built-in The effective policy for a Known Pinned Host that has both built-in
pins and pins from previously observed PKP header response fields is pins and pins from previously observed PKP header response fields is
implementation-defined. implementation-defined.
 End of changes. 7 change blocks. 
26 lines changed or deleted 34 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/