< draft-sheffer-tls-pinning-ticket-09.txt   draft-sheffer-tls-pinning-ticket-10.txt >
Network Working Group Y. Sheffer Network Working Group Y. Sheffer
Internet-Draft Intuit Internet-Draft Intuit
Intended status: Experimental D. Migault Intended status: Experimental D. Migault
Expires: September 9, 2019 Ericsson Expires: November 9, 2019 Ericsson
March 08, 2019 May 08, 2019
TLS Server Identity Pinning with Tickets TLS Server Identity Pinning with Tickets
draft-sheffer-tls-pinning-ticket-09 draft-sheffer-tls-pinning-ticket-10
Abstract Abstract
Misissued public-key certificates can prevent TLS clients from Misissued public-key certificates can prevent TLS clients from
appropriately authenticating the TLS server. Several alternatives appropriately authenticating the TLS server. Several alternatives
have been proposed to detect this situation and prevent a client from have been proposed to detect this situation and prevent a client from
establishing a TLS session with a TLS end point authenticated with an establishing a TLS session with a TLS end point authenticated with an
illegitimate public-key certificate. These mechanisms are either not illegitimate public-key certificate. These mechanisms are either not
widely deployed or limited to public web browsing. widely deployed or limited to public web browsing.
This document proposes to extend TLS with opaque pinning tickets as a This document proposes experimental extensions to TLS with opaque
way to pin the server's identity. During an initial TLS session, the pinning tickets as a way to pin the server's identity. During an
server provides an original encrypted pinning ticket. In subsequent initial TLS session, the server provides an original encrypted
TLS session establishment, upon receipt of the pinning ticket, the pinning ticket. In subsequent TLS session establishment, upon
server proves its ability to decrypt the pinning ticket and thus the receipt of the pinning ticket, the server proves its ability to
ownership of the pinning protection key. The client can now safely decrypt the pinning ticket and thus the ownership of the pinning
conclude that the TLS session is established with the same TLS server protection key. The client can now safely conclude that the TLS
as the original TLS session. One of the important properties of this session is established with the same TLS server as the original TLS
proposal is that no manual management actions are required. session. One of the important properties of this proposal is that no
manual management actions are required.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 9, 2019. This Internet-Draft will expire on November 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 5 1.1. Conventions used in this document . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope of Experimentation . . . . . . . . . . . . . . . . 6
2.1. Initial Connection . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Subsequent Connections . . . . . . . . . . . . . . . . . 8 2.1. Initial Connection . . . . . . . . . . . . . . . . . . . 7
2.3. Indexing the Pins . . . . . . . . . . . . . . . . . . . . 9 2.2. Subsequent Connections . . . . . . . . . . . . . . . . . 9
3. Message Definitions . . . . . . . . . . . . . . . . . . . . . 9 2.3. Indexing the Pins . . . . . . . . . . . . . . . . . . . . 10
4. Cryptographic Operations . . . . . . . . . . . . . . . . . . 10 3. Message Definitions . . . . . . . . . . . . . . . . . . . . . 10
4.1. Pinning Secret . . . . . . . . . . . . . . . . . . . . . 10 4. Cryptographic Operations . . . . . . . . . . . . . . . . . . 11
4.2. Pinning Ticket . . . . . . . . . . . . . . . . . . . . . 10 4.1. Pinning Secret . . . . . . . . . . . . . . . . . . . . . 11
4.3. Pinning Protection Key . . . . . . . . . . . . . . . . . 11 4.2. Pinning Ticket . . . . . . . . . . . . . . . . . . . . . 11
4.4. Pinning Proof . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Pinning Protection Key . . . . . . . . . . . . . . . . . 12
5. Operational Considerations . . . . . . . . . . . . . . . . . 12 4.4. Pinning Proof . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Protection Key Synchronization . . . . . . . . . . . . . 12 5. Operational Considerations . . . . . . . . . . . . . . . . . 13
5.2. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 12 5.1. Protection Key Synchronization . . . . . . . . . . . . . 13
5.3. Certificate Renewal . . . . . . . . . . . . . . . . . . . 13 5.2. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 13 5.3. Certificate Renewal . . . . . . . . . . . . . . . . . . . 14
5.5. Disabling Pinning . . . . . . . . . . . . . . . . . . . . 13 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 14
5.6. Server Compromise . . . . . . . . . . . . . . . . . . . . 13 5.5. Disabling Pinning . . . . . . . . . . . . . . . . . . . . 14
5.7. Disaster Recovery . . . . . . . . . . . . . . . . . . . . 14 5.6. Server Compromise . . . . . . . . . . . . . . . . . . . . 14
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 5.7. Disaster Recovery . . . . . . . . . . . . . . . . . . . . 15
6.1. Mint Fork . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Mint Fork . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.2. Description . . . . . . . . . . . . . . . . . . . . . 15 6.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 16
6.1.3. Level of Maturity . . . . . . . . . . . . . . . . . . 15 6.1.2. Description . . . . . . . . . . . . . . . . . . . . . 16
6.1.4. Coverage . . . . . . . . . . . . . . . . . . . . . . 15 6.1.3. Level of Maturity . . . . . . . . . . . . . . . . . . 16
6.1.5. Version Compatibility . . . . . . . . . . . . . . . . 15 6.1.4. Coverage . . . . . . . . . . . . . . . . . . . . . . 16
6.1.6. Licensing . . . . . . . . . . . . . . . . . . . . . . 15 6.1.5. Version Compatibility . . . . . . . . . . . . . . . . 16
6.1.7. Contact Information . . . . . . . . . . . . . . . . . 15 6.1.6. Licensing . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.1.7. Contact Information . . . . . . . . . . . . . . . . . 16
7.1. Trust on First Use (TOFU) and MITM Attacks . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 16 7.1. Trust on First Use (TOFU) and MITM Attacks . . . . . . . 16
7.3. Server-Side Error Detection . . . . . . . . . . . . . . . 16 7.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 17
7.4. Client Policy and SSL Proxies . . . . . . . . . . . . . . 16 7.3. Server-Side Error Detection . . . . . . . . . . . . . . . 17
7.5. Client-Side Error Behavior . . . . . . . . . . . . . . . 16 7.4. Client Policy and SSL Proxies . . . . . . . . . . . . . . 17
7.6. Stolen and Forged Tickets . . . . . . . . . . . . . . . . 17 7.5. Client-Side Error Behavior . . . . . . . . . . . . . . . 17
7.7. Client Privacy . . . . . . . . . . . . . . . . . . . . . 17 7.6. Stolen and Forged Tickets . . . . . . . . . . . . . . . . 18
7.8. Ticket Protection Key Management . . . . . . . . . . . . 17 7.7. Client Privacy . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7.8. Ticket Protection Key Management . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Previous Work . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 20
A.1. Comparison: HPKP . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Previous Work . . . . . . . . . . . . . . . . . . . 22
A.2. Comparison: TACK . . . . . . . . . . . . . . . . . . . . 24 A.1. Comparison: HPKP . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Document History . . . . . . . . . . . . . . . . . . 25 A.2. Comparison: TACK . . . . . . . . . . . . . . . . . . . . 25
B.1. draft-sheffer-tls-pinning-ticket-08 . . . . . . . . . . . 25 Appendix B. Document History . . . . . . . . . . . . . . . . . . 26
B.2. draft-sheffer-tls-pinning-ticket-07 . . . . . . . . . . . 25 B.1. draft-sheffer-tls-pinning-ticket-10 . . . . . . . . . . . 26
B.3. draft-sheffer-tls-pinning-ticket-06 . . . . . . . . . . . 25 B.2. draft-sheffer-tls-pinning-ticket-09 . . . . . . . . . . . 26
B.4. draft-sheffer-tls-pinning-ticket-05 . . . . . . . . . . . 25 B.3. draft-sheffer-tls-pinning-ticket-08 . . . . . . . . . . . 26
B.5. draft-sheffer-tls-pinning-ticket-04 . . . . . . . . . . . 25 B.4. draft-sheffer-tls-pinning-ticket-07 . . . . . . . . . . . 26
B.6. draft-sheffer-tls-pinning-ticket-03 . . . . . . . . . . . 25 B.5. draft-sheffer-tls-pinning-ticket-06 . . . . . . . . . . . 26
B.7. draft-sheffer-tls-pinning-ticket-02 . . . . . . . . . . . 26 B.6. draft-sheffer-tls-pinning-ticket-05 . . . . . . . . . . . 26
B.8. draft-sheffer-tls-pinning-ticket-01 . . . . . . . . . . . 26 B.7. draft-sheffer-tls-pinning-ticket-04 . . . . . . . . . . . 27
B.9. draft-sheffer-tls-pinning-ticket-00 . . . . . . . . . . . 26 B.8. draft-sheffer-tls-pinning-ticket-03 . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 B.9. draft-sheffer-tls-pinning-ticket-02 . . . . . . . . . . . 27
B.10. draft-sheffer-tls-pinning-ticket-01 . . . . . . . . . . . 27
B.11. draft-sheffer-tls-pinning-ticket-00 . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Misissued public-key certificates can prevent TLS clients from Misissued public-key certificates can prevent TLS [RFC8446] clients
appropriately authenticating the TLS server. This is a significant from appropriately authenticating the TLS server. This is a
risk in the context of the global PKI, and similarly for large scale significant risk in the context of the global public key
deployments of certificates within enterprises. We propose ticket infrastructure (PKI), and similarly for large scale deployments of
pinning as an easy to implement and deploy solution to this problem, certificates within enterprises.
reusing some of the ideas behind TLS session resumption.
This document proposes experimental extensions to TLS with opaque
pinning tickets as a way to pin the server's identity. The approach
is intended to be easy to implement and deploy, and reuses some of
the ideas behind TLS session resumption.
Ticket pinning is a second factor server authentication method and is Ticket pinning is a second factor server authentication method and is
not proposed as a substitute for the authentication method provided not proposed as a substitute for the authentication method provided
in the TLS key exchange. More specifically, the client only uses the in the TLS key exchange. More specifically, the client only uses the
pinning identity method after the TLS key exchange is successfully pinning identity method after the TLS key exchange is successfully
completed. In other words, the pinning identity method is only completed. In other words, the pinning identity method is only
performed over an authenticated TLS session. Note that Ticket performed over an authenticated TLS session. Note that Ticket
Pinning does not pin certificate information and therefore is truly Pinning does not pin certificate information and therefore is truly
an independent second factor authentication. an independent second factor authentication.
skipping to change at page 4, line 22 skipping to change at page 4, line 29
case, the pinning secret is generated from parameters exchanged case, the pinning secret is generated from parameters exchanged
during the TLS key exchange, so client and server can generate it during the TLS key exchange, so client and server can generate it
locally and independently. The server constructs the pinning ticket locally and independently. The server constructs the pinning ticket
with the necessary information to retrieve the pinning secret. The with the necessary information to retrieve the pinning secret. The
server then encrypts the ticket and returns the pinning ticket to the server then encrypts the ticket and returns the pinning ticket to the
client with an associated pinning lifetime. client with an associated pinning lifetime.
The pinning lifetime value indicates for how long the server promises The pinning lifetime value indicates for how long the server promises
to retain the server-side ticket-encryption key, which allows it to to retain the server-side ticket-encryption key, which allows it to
complete the protocol exchange correctly and prove its identity. The complete the protocol exchange correctly and prove its identity. The
server committment (and ticket lifetime) is typically on the order of server commitment (and ticket lifetime) is typically on the order of
weeks. weeks.
Once the key exchange is completed and the server is deemed Once the key exchange is completed and the server is deemed
authenticated, the client generates locally the pinning secret and authenticated, the client generates locally the pinning secret and
caches the server's identifiers to index the pinning secret as well caches the server's identifiers to index the pinning secret as well
as the pinning ticket and its associated lifetime. as the pinning ticket and its associated lifetime.
When the client re-establishes a new TLS session with the server, it When the client re-establishes a new TLS session with the server, it
sends the pinning ticket to the server. Upon receiving it, the sends the pinning ticket to the server. Upon receiving it, the
server returns a proof of knowledge of the pinning secret. Once the server returns a proof of knowledge of the pinning secret. Once the
key exchange is completed and the server has been authenticated, the key exchange is completed and the server has been authenticated, the
client checks the pinning proof returned by the server using the client checks the pinning proof returned by the server using the
client's stored pinning secret. If the proof matches, the client can client's stored pinning secret. If the proof matches, the client can
conclude that the server it is currently connecting to is in fact the conclude that the server it is currently connecting to is in fact the
correct server. correct server.
This version of the draft only applies to TLS 1.3. We believe that This document only applies to TLS 1.3. We believe that the idea can
the idea can also be back-fitted into earlier versions of the also be back-fitted into earlier versions of the protocol, but this
protocol, but this would require significant changes. One example is would require significant changes. One example is that TLS 1.2
that TLS 1.2 and earlier versions do not provide a generic facility [RFC5246] and earlier versions do not provide a generic facility of
of encrypted handshake extensions, such as is used here to transport encrypted handshake extensions, such as is used here to transport the
the ticket. ticket.
The main advantages of this protocol over earlier pinning solutions The main advantages of this protocol over earlier pinning solutions
are: are:
- The protocol is at the TLS level, and as a result is not - The protocol is at the TLS level, and as a result is not
restricted to HTTP at the application level. restricted to HTTP at the application level.
- The protocol is robust to server IP, CA, and public key changes. - The protocol is robust to server IP, Certificate Authority (CA),
The server is characterized by the ownership of the pinning and public key changes. The server is characterized by the
protection key, which is never provided to the client. Server ownership of the pinning protection key, which is never provided
configuration parameters such as the CA and the public key may to the client. Server configuration parameters such as the CA and
change without affecting the pinning ticket protocol. the public key may change without affecting the pinning ticket
protocol.
- Once a single parameter is configured (the ticket's lifetime), - Once a single parameter is configured (the ticket's lifetime),
operation is fully automated. The server administrator need not operation is fully automated. The server administrator need not
bother with the management of backup certificates or explicit bother with the management of backup certificates or explicit
pins. pins.
- For server clusters, we reuse the existing [RFC5077] - For server clusters, we reuse the existing [RFC5077]
infrastructure where it exists. infrastructure where it exists.
- Pinning errors, presumably resulting from MITM attacks, can be - Pinning errors, presumably resulting from man-in-the-middle (MITM)
detected both by the client and the server. This allows for attacks, can be detected both by the client and the server. This
server-side detection of MITM attacks using large-scale analytics, allows for server-side detection of MITM attacks using large-scale
and with no need to rely on clients to explicitly report the analytics, and with no need to rely on clients to explicitly
error. report the error.
A note on terminology: unlike other solutions in this space, we do A note on terminology: unlike other solutions in this space, we do
not do "certificate pinning" (or "public key pinning"), since the not do "certificate pinning" (or "public key pinning"), since the
protocol is oblivious to the server's certificate. We prefer the protocol is oblivious to the server's certificate. We prefer the
term "server identity pinning" for this new solution. In our term "server identity pinning" for this new solution. In our
solution, the server proves its identity by generating a proof that solution, the server proves its identity by generating a proof that
it can read and decrypt an encrypted ticket. As a result, the it can read and decrypt an encrypted ticket. As a result, the
identity proof relies on proof of ownership of the pinning protection identity proof relies on proof of ownership of the pinning protection
key. However, this key is never exchanged with the client or known key. However, this key is never exchanged with the client or known
by it, and so cannot itself be pinned. by it, and so cannot itself be pinned.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Scope of Experimentation
This document describes an experimental extension to the TLS
protocol. This section defines constraints on this experiment and
how it can yield useful information, potentially resulting in a
standard.
The protocol is designed so that if the server does not support it,
the client and server fall back to a normal TLS exchange, with the
exception of a single PinningTicket extension being initially sent by
the client. In addition, the protocol is designed to only strengthen
the validation of the server's identity ("second factor"). As a
result, implementation or even protocol errors should not result
weakened security compared to the normal TLS exchange. Given these
two points, experimentation can be run on the open Internet between
consenting client and server implementations.
The goal of the experiment is to prove that:
- Non-supporting clients and servers are unaffected.
- Connectivity between supporting clients and servers is retained
under normal circumstances, whether the client connects to the
server frequently (relative to the ticket's lifetime) or very
rarely.
- Enterprise middleboxes to not interrupt such connectivity.
- Misissued certificates and rogue TLS-aware middleboxes do result
in broken connectivity, and these cases are detected on the client
and/or server side. Clients and servers can be recovered even
after such events and the normal connectivity restored.
Following two years of successful deployment, the authors will
publish a document that summarizes the experiment's findings and will
resubmit the protocol as a Proposed Standard.
2. Protocol Overview 2. Protocol Overview
The protocol consists of two phases: the first time a particular The protocol consists of two phases: the first time a particular
client connects to a server, and subsequent connections. client connects to a server, and subsequent connections.
This protocol supports full TLS handshakes, as well as 0-RTT This protocol supports full TLS handshakes, as well as 0-RTT
handshakes. Below we present it in the context of a full handshake, handshakes. Below we present it in the context of a full handshake,
but behavior in 0-RTT handshakes should be identical. but behavior in 0-RTT handshakes should be identical.
skipping to change at page 7, line 33 skipping to change at page 8, line 33
* Indicates optional or situation-dependent * Indicates optional or situation-dependent
messages that are not always sent. messages that are not always sent.
{} Indicates messages protected using keys {} Indicates messages protected using keys
derived from the ephemeral secret. derived from the ephemeral secret.
[] Indicates messages protected using keys [] Indicates messages protected using keys
derived from the master secret. derived from the master secret.
If a client supports the pinning ticket extension and does not have If a client supports the PinningTicket extension and does not have
any pinning ticket associated with the server, the exchange is any pinning ticket associated with the server, the exchange is
considered as an initial connection. Other reasons the client may considered as an initial connection. Other reasons the client may
not have a pinning ticket include the client having flushed its not have a pinning ticket include the client having flushed its
pinning ticket store, or the committed lifetime of the pinning ticket pinning ticket store, or the committed lifetime of the pinning ticket
having expired. having expired.
Upon receipt of the PinningTicket extension, the server computes a Upon receipt of the PinningTicket extension, the server computes a
pinning secret (Section 4.1), and sends the pinning ticket pinning secret (Section 4.1), and sends the pinning ticket
(Section 4.2) encrypted with the pinning protection key (Section 4.2) encrypted with the pinning protection key
(Section 4.3). The pinning ticket is associated with a lifetime (Section 4.3). The pinning ticket is associated with a lifetime
skipping to change at page 18, line 36 skipping to change at page 19, line 36
The TicketPinning Extension TLS.13 column should be set to CH, SH to The TicketPinning Extension TLS.13 column should be set to CH, SH to
indicate that the TicketPinning Extension is present in ClientHello indicate that the TicketPinning Extension is present in ClientHello
and ServerHello messages. and ServerHello messages.
9. Acknowledgements 9. Acknowledgements
The original idea behind this proposal was published in [Oreo] by The original idea behind this proposal was published in [Oreo] by
Moti Yung, Benny Pinkas and Omer Berkman. The current protocol is Moti Yung, Benny Pinkas and Omer Berkman. The current protocol is
but a distant relative of the original Oreo protocol, and any errors but a distant relative of the original Oreo protocol, and any errors
are the draft authors' alone. are the responsibility of the authors of this document alone.
We would like to thank Dave Garrett, Daniel Kahn Gillmor, Yoav Nir, We would like to thank Adrian Farrel, Dave Garrett, Daniel Kahn
Eric Rescorla and Rich Salz for their comments on this draft. Gillmor, Yoav Nir, Eric Rescorla and Rich Salz for their comments on
Special thanks to Craig Francis for contributing the HPKP deployment this document. Special thanks to Craig Francis for contributing the
script, and to Ralph Holz for several fruitful discussions. HPKP deployment script, and to Ralph Holz for several fruitful
discussions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
10.2. Informative References 10.2. Informative References
skipping to change at page 19, line 44 skipping to change at page 20, line 48
[Oreo] Berkman, O., Pinkas, B., and M. Yung, "Firm Grip [Oreo] Berkman, O., Pinkas, B., and M. Yung, "Firm Grip
Handshakes: A Tool for Bidirectional Vouching", Cryptology Handshakes: A Tool for Bidirectional Vouching", Cryptology
and Network Security, pp. 142-157 , 2012. and Network Security, pp. 142-157 , 2012.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
skipping to change at page 21, line 42 skipping to change at page 22, line 42
is made even higher given the fact that, even though work has been is made even higher given the fact that, even though work has been
done at the ACME WG to automate certificate management, in many or done at the ACME WG to automate certificate management, in many or
even most cases, certificates are still managed manually. As a even most cases, certificates are still managed manually. As a
result, HPKP cannot be completely automated resulting in error-prone result, HPKP cannot be completely automated resulting in error-prone
manual configuration. Such errors could prevent the web server from manual configuration. Such errors could prevent the web server from
being accessed by some clients. In addition, HPKP uses a HTTP header being accessed by some clients. In addition, HPKP uses a HTTP header
which makes this solution HTTPS specific and not generic to TLS. On which makes this solution HTTPS specific and not generic to TLS. On
the other hand, the current document provides a solution that is the other hand, the current document provides a solution that is
independent of the server's certificate management and that can be independent of the server's certificate management and that can be
entirely and easily automated. Appendix A.1 compares HPKP to the entirely and easily automated. Appendix A.1 compares HPKP to the
current draft in more detail. current document in more detail.
The ticket pinning proposal augments these mechanisms with a much The ticket pinning proposal augments these mechanisms with a much
easier to implement and deploy solution for server identity pinning, easier to implement and deploy solution for server identity pinning,
by reusing some of the ideas behind TLS session resumption. by reusing some of the ideas behind TLS session resumption.
This section compares ticket pinning to two earlier proposals, HPKP This section compares ticket pinning to two earlier proposals, HPKP
and TACK. and TACK.
A.1. Comparison: HPKP A.1. Comparison: HPKP
skipping to change at page 24, line 36 skipping to change at page 25, line 36
"backup2" key-pair. "backup2" key-pair.
Note that in the above steps, both the certificate issuance as well Note that in the above steps, both the certificate issuance as well
as the storage of the backup key pair involve manual steps. Even as the storage of the backup key pair involve manual steps. Even
with an automated CA that runs the ACME protocol, key backup would be with an automated CA that runs the ACME protocol, key backup would be
a challenge to automate. a challenge to automate.
A.2. Comparison: TACK A.2. Comparison: TACK
Compared with HPKP, TACK [I-D.perrin-tls-tack] is a lot more similar Compared with HPKP, TACK [I-D.perrin-tls-tack] is a lot more similar
to the current draft. It can even be argued that this document is a to the current document. It can even be argued that this document is
symmetric-cryptography variant of TACK. That said, there are still a a symmetric-cryptography variant of TACK. That said, there are still
few significant differences: a few significant differences:
- Probably the most important difference is that with TACK, - Probably the most important difference is that with TACK,
validation of the server certificate is no longer required, and in validation of the server certificate is no longer required, and in
fact TACK specifies it as a "MAY" requirement (Sec. 5.3). With fact TACK specifies it as a "MAY" requirement (Sec. 5.3). With
ticket pinning, certificate validation by the client remains a ticket pinning, certificate validation by the client remains a
MUST requirement, and the ticket acts only as a second factor. If MUST requirement, and the ticket acts only as a second factor. If
the pinning secret is compromised, the server's security is not the pinning secret is compromised, the server's security is not
immediately at risk. immediately at risk.
- Both TACK and the current draft are mostly orthogonal to the - Both TACK and the current document are mostly orthogonal to the
server certificate as far as their life cycle, and so both can be server certificate as far as their life cycle, and so both can be
deployed with no manual steps. deployed with no manual steps.
- TACK uses ECDSA to sign the server's public key. This allows - TACK uses ECDSA to sign the server's public key. This allows
cooperating clients to share server assertions between themselves. cooperating clients to share server assertions between themselves.
This is an optional TACK feature, and one that cannot be done with This is an optional TACK feature, and one that cannot be done with
pinning tickets. pinning tickets.
- TACK allows multiple servers to share its public keys. Such - TACK allows multiple servers to share its public keys. Such
sharing is disallowed by the current document. sharing is disallowed by the current document.
- TACK does not allow the server to track a particular client, and - TACK does not allow the server to track a particular client, and
so has better privacy properties than the current draft. so has better privacy properties than the current document.
- TACK has an interesting way to determine the pin's lifetime, - TACK has an interesting way to determine the pin's lifetime,
setting it to the time period since the pin was first observed, setting it to the time period since the pin was first observed,
with a hard upper bound of 30 days. The current draft makes the with a hard upper bound of 30 days. The current document makes
lifetime explicit, which may be more flexible to deploy. For the lifetime explicit, which may be more flexible to deploy. For
example, Web sites which are only visited rarely by users may opt example, Web sites which are only visited rarely by users may opt
for a longer period than other sites that expect users to visit on for a longer period than other sites that expect users to visit on
a daily basis. a daily basis.
Appendix B. Document History Appendix B. Document History
B.1. draft-sheffer-tls-pinning-ticket-08 B.1. draft-sheffer-tls-pinning-ticket-10
- ISE comments by Adrian Farrel, the ISE.
B.2. draft-sheffer-tls-pinning-ticket-09
- ISE comments by Yoav Nir.
B.3. draft-sheffer-tls-pinning-ticket-08
- ISE comments by Rich Salz. - ISE comments by Rich Salz.
B.2. draft-sheffer-tls-pinning-ticket-07 B.4. draft-sheffer-tls-pinning-ticket-07
- Refer to published RFCs. - Refer to published RFCs.
B.3. draft-sheffer-tls-pinning-ticket-06 B.5. draft-sheffer-tls-pinning-ticket-06
- IANA Considerations in preparation for Experimental publication. - IANA Considerations in preparation for Experimental publication.
B.4. draft-sheffer-tls-pinning-ticket-05 B.6. draft-sheffer-tls-pinning-ticket-05
- Multiple comments from Eric Rescorla. - Multiple comments from Eric Rescorla.
B.5. draft-sheffer-tls-pinning-ticket-04 B.7. draft-sheffer-tls-pinning-ticket-04
- Editorial changes. - Editorial changes.
- Two-phase rotation of protection key. - Two-phase rotation of protection key.
B.6. draft-sheffer-tls-pinning-ticket-03 B.8. draft-sheffer-tls-pinning-ticket-03
- Deleted redundant length fields in the extension's formal - Deleted redundant length fields in the extension's formal
definition. definition.
- Modified cryptographic operations to align with the current state - Modified cryptographic operations to align with the current state
of TLS 1.3. of TLS 1.3.
- Numerous textual improvements. - Numerous textual improvements.
B.7. draft-sheffer-tls-pinning-ticket-02 B.9. draft-sheffer-tls-pinning-ticket-02
- Added an Implementation Status section. - Added an Implementation Status section.
- Added lengths into the extension structure. - Added lengths into the extension structure.
- Changed the computation of the pinning proof to be more robust. - Changed the computation of the pinning proof to be more robust.
- Clarified requirements on the length of the pinning_secret. - Clarified requirements on the length of the pinning_secret.
- Revamped the HPKP section to be more in line with current - Revamped the HPKP section to be more in line with current
practices, and added recent statistics on HPKP deployment. practices, and added recent statistics on HPKP deployment.
B.8. draft-sheffer-tls-pinning-ticket-01 B.10. draft-sheffer-tls-pinning-ticket-01
- Corrected the notation for variable-sized vectors. - Corrected the notation for variable-sized vectors.
- Added a section on disaster recovery and backup. - Added a section on disaster recovery and backup.
- Added a section on privacy. - Added a section on privacy.
- Clarified the assumptions behind the HPKP procedure in the - Clarified the assumptions behind the HPKP procedure in the
comparison section. comparison section.
- Added a definition of pin indexing (origin). - Added a definition of pin indexing (origin).
- Adjusted to the latest TLS 1.3 notation. - Adjusted to the latest TLS 1.3 notation.
B.9. draft-sheffer-tls-pinning-ticket-00 B.11. draft-sheffer-tls-pinning-ticket-00
Initial version. Initial version.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Intuit Intuit
EMail: yaronf.ietf@gmail.com EMail: yaronf.ietf@gmail.com
Daniel Migault Daniel Migault
Ericsson Ericsson
EMail: daniel.migault@ericsson.com EMail: daniel.migault@ericsson.com
 End of changes. 31 change blocks. 
116 lines changed or deleted 183 lines changed or added

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