One document matched: draft-sheffer-tls-pinning-ticket-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<rfc ipr="trust200902" docName="draft-sheffer-tls-pinning-ticket-01" category="std">
<front>
<title abbrev="Pinning Tickets">TLS Server Identity Pinning with Tickets</title>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization>Intuit</organization>
<address>
<email>yaronf.ietf@gmail.com</email>
</address>
</author>
<date year="2016" month="February" day="06"/>
<area>General</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Fake public-key certificates are an ongoing problem for users of TLS. Several solutions
have been proposed, but none is currently in wide use.
This document proposes to extend TLS with opaque tickets, similar to those being
used for TLS session resumption, as a way to pin the server’s identity.
That is, to ensure the client that it is connecting to the right server even
in the presence of corrupt certificate authorities and fake certificates. The main advantage
of this solution is that no manual management actions are required.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The weaknesses of the global PKI system are by now widely known. Essentially,
any valid CA may issue a certificate for any organization without the
organization’s approval (a misissued or “fake” certificate),
and use the certificate to impersonate the organization.
There are many attempts
to resolve these weaknesses, including Certificate Transparency (CT) <xref target="RFC6962"/>, HTTP Public Key
Pinning (HPKP) <xref target="RFC7469"/>, and TACK <xref target="I-D.perrin-tls-tack"/>.
CT requires cooperation of a large
portion of the hundreds of
extant certificate authorities (CAs) before it can be used “for real”, in enforcing
mode. It is noted that the relevant industry forum (CA/Browser Forum) is indeed pushing for such
extensive adoption.
TACK has some similarities to the current proposal, but work on it seems to have stalled.
<xref target="tack"/> compares our proposal to TACK.
HPKP is a standard,
but so far has proven hard to deploy (see <xref target="hpkp"/>).
This proposal augments these mechanisms
with a much easier to implement and deploy solution for server identity pinning, by
reusing some of the mechanisms behind TLS session resumption.</t>
<t>When a client first connects to a server, the server responds with a ticket and a
committed lifetime. The ticket is modeled on the session resumption ticket, but is
distinct from it. Specifically, the ticket acts as a “second factor” for proving
the server’s identity;
the ticket does not authenticate the client. The
committed lifetime indicates for how long the server promises to
retain the server-side ticket-encryption key, which allows it to complete
the protocol exchange correctly and prove its identity. The committed lifetime is
typically on the order of weeks or months. We follow the Trust On First Use (TOFU)
model, in that the first server authentication is only based on PKI certificate
validation, but for any follow-on sessions, the client is further ensuring the server’s
identity based on the server’s ability to decrypt the ticket and complete the handshake
correctly.</t>
<t>This version of the draft only discusses TLS 1.3. We believe that the idea can also
be back-fitted into earlier versions of the protocol.</t>
<t>The main advantages of this protocol over earlier pinning solutions are:</t>
<t><list style="symbols">
<t>The protocol is at the TLS level, and as a result is not restricted to HTTP at the
application level.</t>
<t>Once a single parameter is configured (the ticket secret’s lifetime), operation
is fully automated. The server administrator need not bother with the
management of backup certificates or explicit pins.</t>
<t>For server clusters, we reuse the existing <xref target="RFC5077"/> infrastructure where
it exists.</t>
<t>Pinning errors, presumably resulting from MITM attacks, can be detected both by the
client and the server. This allows for server-side detection of MITM attacks using
large-scale analytics.</t>
</list></t>
<t>A note on terminology: unlike other solutions in this space, we do not
do “certificate pinning” (or “public key pinning”), since the protocol is oblivious to the server’s
certificate. We prefer the term “server identity pinning” for this new solution.</t>
<section anchor="conventions-used-in-this-document" title="Conventions used in this document">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be
interpreted as described in <xref target="RFC2119" />.</t>
</section>
</section>
<section anchor="protocol-overview" title="Protocol Overview">
<t>The protocol consists of two phases: the first time a particular client connects to a
server, and subsequent connections.</t>
<t>This protocol supports full TLS handshakes, as well as 0-RTT handshakes.
Below we present it in the context of a full handshake, but behavior in 0-RTT
handshakes should be identical.</t>
<t>The preshared key (PSK) variant of TLS 1.3 is orthogonal to this protocol. A TLS session can
be established using PKI and a pinning ticket, and later resumed with PSK.
The PSK handshake MUST NOT include the extension defined here.</t>
<section anchor="initial-connection" title="Initial Connection">
<t>When a client first connects to a server, it requests a pinning ticket by sending an
empty PinningTicket extension, and receives it
as part of the
server’s first response, in the returned PinningTicket extension.</t>
<figure><artwork><![CDATA[
Client Server
ClientHello
+ key_share
+ PinningTicket -------->
ServerHello
+ key_share
{EncryptedExtensions
+ PinningTicket}
{ServerConfiguration*}
{Certificate*}
{CertificateRequest*}
{CertificateVerify*}
<-------- {Finished}
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
* Indicates optional or situation-dependent
messages that are not always sent.
{} Indicates messages protected using keys
derived from the ephemeral secret.
[] Indicates messages protected using keys
derived from the master secret.
]]></artwork></figure>
<t>The server computes a pinning_secret value (<xref target="pinning-secret"/>)
in order to generate the ticket.
When the connection setup is complete, the client computes
the same pinning_secret value and saves it locally, together with the received
ticket.</t>
<t>The client SHOULD cache the ticket and the pinning_secret for the lifetime received from
the server. The client MUST forget these values
at the end of this duration.</t>
<t>The returned ticket is sent as a ServerHello protected extension, and MUST NOT be sent
as part of a HelloRetryRequest.</t>
</section>
<section anchor="subsequent-connections" title="Subsequent Connections">
<t>When the client initiates a connection to a server it has previously seen (see
<xref target="indexing"/>
on identifying servers and origins), it SHOULD send the pinning ticket for that server.</t>
<t>The server MUST extract the original pinning_secret from the ticket
and MUST respond with a PinningTicket extension, which includes:</t>
<t><list style="symbols">
<t>A proof that the server can understand
the ticket that was sent by the client; this proof also binds the pinning ticket to
the server’s (current) public key. The proof is MANDATORY if a ticket was sent by
the client.</t>
<t>A fresh pinning ticket. The main reason for refreshing the ticket on each connection
is privacy: to avoid the ticket serving as a fixed client identifier. It is RECOMMENDED
to include a fresh ticket with each response.</t>
</list></t>
<t>If the server cannot validate the ticket, that might indicate an earlier MITM attack
on this client. The server MUST then abort the connection with a
handshake_failure alert, and SHOULD log this failure.</t>
<t>The client MUST verify the proof, and if it fails to do so,
MUST issue a handshake_failure alert
and abort the connection (see also <xref target="client_error"/>). When the connection is successfully
set up, the
client SHOULD store the new ticket along with the corresponding pinning_secret.</t>
<t>Although this is an extension, if the client already has a ticket for a server,
the client MUST interpret a missing PinningTicket extension in the
server’s response as an attack, because of the server’s prior commitment to
respect the ticket. The client MUST abort the connection in this case.
See also <xref target="ramp_down"/> on ramping down support for this extension.</t>
</section>
<section anchor="indexing" title="Indexing the Pins">
<t>Each pin is associated with a host name, protocol (TLS or DTLS) and port number.
In other words, the pin for port TCP/443 may be different from that for DTLS or from
the pin for port TCP/8443.
The host name MUST be
the value sent inside the Server Name Indication (SNI) extension.
This definition is similar to
a Web Origin <xref target="RFC6454"/>, but does not assume the existence of a URL.</t>
<t>IP addresses are ephemeral and forbidden in SNI and therefore Pins MUST NOT be associated
with IP addresses.</t>
</section>
</section>
<section anchor="message-definitions" title="Message Definitions">
<t>This section defines the format of the PinningTicket extension.
We follow the message notation of <xref target="I-D.ietf-tls-tls13"/>.</t>
<figure><artwork><![CDATA[
opaque pinning_ticket<0..2^16-1>;
opaque pinning_proof<0..2^8-1>;
struct {
select (Role) {
case client:
pinning_ticket ticket<0..2^16-1>; //omitted on 1st connection
case server:
pinning_proof proof<0..2^8-1>; //no proof on 1st connection
pinning_ticket ticket<0..2^16-1>; //omitted on ramp down
uint32 lifetime;
}
} PinningTicketExtension;
]]></artwork></figure>
<t><list style="hanging">
<t hangText='ticket'>
a pinning ticket sent by the client or returned by the server. The ticket is opaque
to the client. The extension MUST contain exactly 0 or 1 tickets.</t>
<t hangText='proof'>
a demonstration by the server that it understands the ticket and therefore that
it is in possession of the secret that was used to generate it originally. The
proof is further bound to the server’s public key to prevent some MITM attacks.
The extension MUST contain exactly 0 or 1 proofs.</t>
<t hangText='lifetime'>
the duration (in seconds) that the server commits to accept the newly offered
ticket in the future. This period MUST be at least 604800 (one week).</t>
</list></t>
</section>
<section anchor="crypto" title="Cryptographic Operations">
<t>This section provides details on the cryptographic operations performed
by the protocol peers.</t>
<section anchor="pinning-secret" title="Pinning Secret">
<t>On each connection that includes the PinningTicket extension, both peers
derive the the value pinning_secret from the shared Diffie Hellman secret. They compute:</t>
<figure><artwork><![CDATA[
pinning_secret = HKDF(xSS, xES, "pinning secret", L)
]]></artwork></figure>
<t>using the notation of <xref target="I-D.ietf-tls-tls13"/>, sec. Key Schedule. This secret
is used by the server to generate the new ticket that it returns to the client.</t>
</section>
<section anchor="pinning-ticket" title="Pinning Ticket">
<t>The pinning ticket’s format is not specified by this document, but it MUST be
encrypted and integrity-protected using a long-term pinning-ticket protection key.
The server MUST rotate the protection key periodically, and therefore the ticket
MUST contain a protection key ID or serial number.
The ticket MUST allow the server to recover the pinning_secret value, and MAY
include additional information.</t>
<t>As noted in <xref target="cluster"/>, if the server is actually a cluster of machines,
the protection key MUST
be synchronized between them. An easy way to do it is to derive it from the
session-ticket protection key, which is already synchronized. For example:</t>
<figure><artwork><![CDATA[
pinning_protection_key = HKDF(0, resumption_protection_key,
"pinning protection", L)
]]></artwork></figure>
</section>
<section anchor="pinning-proof" title="Pinning Proof">
<t>The proof sent by the server consists of this value:</t>
<figure><artwork><![CDATA[
proof = HMAC(original_pinning_secret, "pinning proof" + '\0' +
client.random + server.random + Hash(server_public_key))
]]></artwork></figure>
<t>where HMAC <xref target="RFC2104"/> uses the Hash algorithm for the handshake,
and the same hash is also used over the server’s public key.</t>
</section>
</section>
<section anchor="operational-considerations" title="Operational Considerations">
<t>The main motivation behind the current protocol is to enable identity
pinning without the need for manual operations. Manual operations are susceptible
to human error and in the case of public key pinning, can easily result in
“server bricking”: the server becoming inaccessible to some or all of its users.</t>
<section anchor="cluster" title="Protection Key Synchronization">
<t>The only operational requirement when deploying this protocol is that if the server
is part of a cluster, protection keys (the keys used to encrypt tickets)
MUST be synchronized between all cluster members. The protocol is designed so
that if resumption ticket protection keys <xref target="RFC5077"/> are already synchronized between
cluster members, nothing more needs to be done.</t>
<t>Moreover, synchronization does not need
to be instantaneous, e.g. protection keys can be distributed a few minutes
or hours in advance of their rollover.</t>
</section>
<section anchor="certificate-renewal" title="Certificate Renewal">
<t>The protocol ensures that the client will continue speaking to the correct server
even when the server’s certificate is renewed. In this sense, we are not “pinning
certificates” and the protocol should more precisely be called “server identity pinning”.</t>
</section>
<section anchor="certificate-revocation" title="Certificate Revocation">
<t>The protocol is orthogonal to certificate validation, in the sense that, if the
server’s certificate has been revoked or is invalid for some other reason,
the client MUST refuse to connect to it.</t>
</section>
<section anchor="ramp_down" title="Disabling Pinning">
<t>A server implementing this protocol MUST have a “ramp down” mode of operation where:</t>
<t><list style="symbols">
<t>The server continues to accept valid pinning tickets and responds
correctly with a proof.</t>
<t>The server does not send back a new pinning ticket.</t>
</list></t>
<t>After a while no clients will hold valid tickets any more and the feature may be
disabled.</t>
</section>
<section anchor="server-compromise" title="Server Compromise">
<t>If a server compromise is detected, the pinning secret MUST be rotated immediately,
but the server MUST still accept valid tickets that use the old, compromised key.
Clients who still hold old pinning tickets will remain vulnerable to MITM attacks,
but those that connect to the correct server will immediately receive new tickets.</t>
</section>
<section anchor="disaster-recovery" title="Disaster Recovery">
<t>All web servers in production need to be backed up, so that they can be recovered if a
disaster (including a malicious activity) ever wipes them out. Backup typically includes
the certificate and its private key, which must be backed up securely. The pinning secret, including
earlier versions that are still being accepted, must be backed up regularly. However
since it is only used as an authentication second factor, it does not require the same level
of confidentiality as the server’s private key.</t>
<t>Readers should note that <xref target="RFC5077"/> session resumption keys are more security sensitive, and
should normally not be backed up but rather treated as ephemeral keys. Even when servers derive
pinning secrets from resumption keys (<xref target="pinning-secret"/>), they MUST NOT back up resumption keys.</t>
</section>
</section>
<section anchor="previous-work" title="Previous Work">
<t>This section compares ticket pinning to two earlier proposals, HPKP and TACK.</t>
<section anchor="hpkp" title="Comparison: HPKP Deployment">
<t>The current IETF standard for pinning the identity of web servers
is the Public Key Pinning Extension
for HTTP, or HPKP <xref target="RFC7469"/>. Unfortunately HPKP has not seen wide deployment yet.
This may simply be
due to inertia, but we believe the main reason is the onerous manual certificate
management which is needed to implement HPKP for enterprise servers. The penalty
for making mistakes (e.g. being too early or too late to deploy new pins) is
often bricking the server for some clients.</t>
<t>To demonstrate
this point, we present an analysis of what it would take to deploy HPKP for
a security-sensitive Web server.</t>
<t><list style="numbers">
<t>Pin only end-entity certificates. Pinning an intermediate certificate
means that the enterprise is
at risk if the CA makes sudden operational changes. Pinning the root certificate is useless:
it still allows every “brand” (sub-CA) to issue a fake certificate for the servers.</t>
<t>Make sure the default reminder period from the certificate management system is
long, e.g. 3 months. This is assuming a pin period (“max age”) of 1 month.</t>
<t>Issue two certificates with the same validity period, the main and a backup one.</t>
<t>Once we get the expiration reminder, issue two new certificates and install
the new “main”
certificate on servers. Change the HPKP header to send the old
main certificate as the main pin (actually, what is sent is the certificate’s SPKI),
the new main certificate as the backup, and the new backup certificate as a secondary backup
(in case the new main certificate gets compromised). This transition period must be at least
one month, so as not to break clients who still pin to the old main certificate.</t>
<t>Shortly before expiration, change the HPKP header again to send the new
main certificate’s SPKI as
the main pin and the new backup certificate as the backup pin.</t>
</list></t>
<t>To summarize:</t>
<texttable>
<ttcol align='left'>Period</ttcol>
<ttcol align='left'>Main server certificate</ttcol>
<ttcol align='left'>Backup pin</ttcol>
<ttcol align='left'>Secondary backup pin</ttcol>
<c>Regular operation: before rotation</c>
<c>Old main certificate</c>
<c>Old backup certificate</c>
<c> </c>
<c>>1 month before expiration of old certificates</c>
<c>Old main certificate</c>
<c>New main certificate</c>
<c>New backup certificate</c>
<c>Shortly before expiration but not earlier than the previous change + 1 month</c>
<c>New main certificate</c>
<c>New backup certificate</c>
<c> </c>
<c>Regular operation: after rotation</c>
<c>New main certificate</c>
<c>New backup certificate</c>
<c> </c>
</texttable>
<t>The above assumes that public keys are normally associated with certificates, that is, the certificate
is issued shortly after the public key is generated. This is true for many enterprise deployment,
where certificates are managed by certificate management applications or directly with the CA,
and there is no facility
for secure and resilient long-term storage of public (and private) keys.
HPKP is easier to deploy securely where such facilities do exist.</t>
</section>
<section anchor="tack" title="Comparison: TACK">
<t>Compared with HPKP, TACK <xref target="I-D.perrin-tls-tack"/> is a lot more similar to the current draft.
It can even be argued that this document is a symmetric-cryptography variant of TACK.
That said, there are still a few significant differences:</t>
<t><list style="symbols">
<t>Probably the most important difference is that with TACK, validation of the server
certificate is no longer required, and in fact TACK specifies it as a “MAY” requirement
(Sec. 5.3).
With ticket pinning, certificate validation by the client remains a MUST requirement, and the
ticket acts only as a second factor. If the pinning secret is compromised, the server’s
security is not immediately at risk.</t>
<t>Both TACK and the current draft are mostly orthogonal to the server certificate as far as
their life cycle, and so both can be deployed with no manual steps.</t>
<t>TACK uses ECDSA to sign the server’s public key. This allows cooperating clients
to share server assertions between themselves. This is an optional TACK feature,
one that cannot be done with pinning tickets.</t>
<t>TACK allows multiple servers to share its public keys. Such sharing is disallowed
by the current document.</t>
<t>TACK does not allow the server to track a particular client, and so has better
privacy properties than the current draft.</t>
<t>TACK has an interesting way to determine the pin’s lifetime, 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 lifetime explicit, which may be more flexible to deploy.
For 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 a daily basis.</t>
</list></t>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>This section reviews several security aspects related to the proposed extension.</t>
<section anchor="trust-on-first-use-tofu-and-mitm-attacks" title="Trust on First Use (TOFU) and MITM Attacks">
<t>This protocol is a “trust on first use” protocol. If a client initially connects to
the “right” server, it will be protected against MITM attackers for the lifetime
of each received ticket. If it connects regularly (depending of course on the
server-selected lifetime), it will stay constantly protected against fake
certificates.</t>
<t>However if it initially connects to an attacker, subsequent connections to
the “right” server will fail. Server operators might want to advise clients
on how to remove corrupted pins, once such large scale attacks are detected and remediated.</t>
<t>The protocol is designed so that it is not vulnerable to an active MITM attacker
who has real-time access
to the original server. The pinning proof includes a hash of the server’s
public key, to ensure the client that the proof was in fact generated by
the server with which it is initiating the connection.</t>
</section>
<section anchor="pervasive-monitoring" title="Pervasive Monitoring">
<t>Some organizations, and even some countries perform pervasive monitoring on their
constituents <xref target="RFC7258"/>. This often takes the form of SSL proxies. Because of
the TOFU property, this protocol does not provide any security in such cases.</t>
</section>
<section anchor="server_error" title="Server-Side Error Detection">
<t>Uniquely, this protocol allows the server to detect clients that present incorrect
tickets and therefore can be assumed to be victims of a MITM attack. Server operators
can use such cases as indications of ongoing attacks, similarly to fake certificate
attacks that took place in a few countries in the past.</t>
</section>
<section anchor="client-policy" title="Client Policy">
<t>Like it or not, some clients are normally deployed behind an SSL proxy.
Similarly to <xref target="RFC7469"/>, it is acceptable to allow pinning to be disabled for some hosts
according to local policy. For example, a UA MAY disable pinning for hosts whose
validated certificate chain terminates at a user-defined trust anchor, rather than
a trust anchor built-in to the UA (or underlying platform). Moreover, a client MAY accept
an empty PinningTicket extension from such hosts as a valid response.</t>
</section>
<section anchor="client_error" title="Client-Side Error Behavior">
<t>When a client receives an incorrect or empty PinningTicket from a pinned server, it MUST
abort the handshake and MUST NOT retry with no PinningTicket in the request. Doing
otherwise would expose the client to trivial fallback attacks, similar to
those described in <xref target="RFC7507"/>.</t>
<t>This rule can however have negative affects on clients that move from behind SSL proxies into
the open Internet. Therefore, browser and library vendors MUST provide a documented way to
remove stored pins.</t>
</section>
<section anchor="client-privacy" title="Client Privacy">
<t>This protocol is designed so that an external attacker cannot correlate between different requests
of a single client, provided the client requests and receives a fresh ticket upon each connection.</t>
<t>On the other hand, the server to which the client is connecting can easily track the client.
This may be an issue when the client expects to connect to the server (e.g., a mail server)
with multiple identities. Implementations SHOULD allow the user to opt out of pinning, either
in general or for particular servers.</t>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>IANA is requested to allocate a TicketPinning extension value in the
TLS ExtensionType Registry.</t>
<t>No registries are defined by this document.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The original idea behind this proposal was published in <xref target="Oreo"/> by Moty Yung,
Benny Pinkas
and Omer Berkman. The current protocol is but a
distant relative of the original Oreo protocol, and any errors are the
draft author’s alone.</t>
<t>I would like to thank Dave Garrett, Daniel Kahn Gillmor and Yoav Nir for their comments on this draft.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2104' target='http://www.rfc-editor.org/info/rfc2104'>
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'><organization /></author>
<author initials='M.' surname='Bellare' fullname='M. Bellare'><organization /></author>
<author initials='R.' surname='Canetti' fullname='R. Canetti'><organization /></author>
<date year='1997' month='February' />
<abstract><t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t></abstract>
</front>
<seriesInfo name='RFC' value='2104'/>
<seriesInfo name='DOI' value='10.17487/RFC2104'/>
</reference>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='December' day='28' year='2015' />
<abstract><t>This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-11' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-11.txt' />
</reference>
<reference anchor='RFC5077' target='http://www.rfc-editor.org/info/rfc5077'>
<front>
<title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title>
<author initials='J.' surname='Salowey' fullname='J. Salowey'><organization /></author>
<author initials='H.' surname='Zhou' fullname='H. Zhou'><organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2008' month='January' />
<abstract><t>This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5077'/>
<seriesInfo name='DOI' value='10.17487/RFC5077'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC6454' target='http://www.rfc-editor.org/info/rfc6454'>
<front>
<title>The Web Origin Concept</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2011' month='December' />
<abstract><t>This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6454'/>
<seriesInfo name='DOI' value='10.17487/RFC6454'/>
</reference>
<reference anchor='RFC6962' target='http://www.rfc-editor.org/info/rfc6962'>
<front>
<title>Certificate Transparency</title>
<author initials='B.' surname='Laurie' fullname='B. Laurie'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Kasper' fullname='E. Kasper'><organization /></author>
<date year='2013' month='June' />
<abstract><t>This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.</t><t>Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</t></abstract>
</front>
<seriesInfo name='RFC' value='6962'/>
<seriesInfo name='DOI' value='10.17487/RFC6962'/>
</reference>
<reference anchor='RFC7258' target='http://www.rfc-editor.org/info/rfc7258'>
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2014' month='May' />
<abstract><t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract>
</front>
<seriesInfo name='BCP' value='188'/>
<seriesInfo name='RFC' value='7258'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>
<reference anchor='RFC7469' target='http://www.rfc-editor.org/info/rfc7469'>
<front>
<title>Public Key Pinning Extension for HTTP</title>
<author initials='C.' surname='Evans' fullname='C. Evans'><organization /></author>
<author initials='C.' surname='Palmer' fullname='C. Palmer'><organization /></author>
<author initials='R.' surname='Sleevi' fullname='R. Sleevi'><organization /></author>
<date year='2015' month='April' />
<abstract><t>This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents 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 trusted 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.</t></abstract>
</front>
<seriesInfo name='RFC' value='7469'/>
<seriesInfo name='DOI' value='10.17487/RFC7469'/>
</reference>
<reference anchor='RFC7507' target='http://www.rfc-editor.org/info/rfc7507'>
<front>
<title>TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks</title>
<author initials='B.' surname='Moeller' fullname='B. Moeller'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<date year='2015' month='April' />
<abstract><t>This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.</t></abstract>
</front>
<seriesInfo name='RFC' value='7507'/>
<seriesInfo name='DOI' value='10.17487/RFC7507'/>
</reference>
<reference anchor='I-D.perrin-tls-tack'>
<front>
<title>Trust Assertions for Certificate Keys</title>
<author initials='M' surname='Marlinspike' fullname='Moxie Marlinspike'>
<organization />
</author>
<date month='January' day='7' year='2013' />
<abstract><t>This document defines a TLS Extension that enables a TLS server to support "pinning" to a self-chosen signing key. A client contacting a pinned host will require the server to present a signature from the signing key over the TLS server's public key.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-perrin-tls-tack-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-perrin-tls-tack-02.txt' />
</reference>
<reference anchor="Oreo" >
<front>
<title>Firm Grip Handshakes: A Tool for Bidirectional Vouching</title>
<author initials="O." surname="Berkman">
<organization></organization>
</author>
<author initials="B." surname="Pinkas">
<organization></organization>
</author>
<author initials="M." surname="Yung">
<organization></organization>
</author>
<date year="2012"/>
</front>
<seriesInfo name="Cryptology and Network Security, pp. 142-157" value=""/>
</reference>
</references>
<section anchor="document-history" title="Document History">
<section anchor="draft-sheffer-tls-pinning-ticket-01" title="draft-sheffer-tls-pinning-ticket-01">
<t><list style="symbols">
<t>Corrected the notation for variable-sized vectors.</t>
<t>Added a section on disaster recovery and backup.</t>
<t>Added a section on privacy.</t>
<t>Clarified the assumptions behind the HPKP procedure in the comparison section.</t>
<t>Added a definition of pin indexing (origin).</t>
<t>Adjusted to the latest TLS 1.3 notation.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-00" title="draft-sheffer-tls-pinning-ticket-00">
<t>Initial version.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:10:00 |