rfc8672xml2.original.xml   rfc8672.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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.2.9 -->
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 --> <!-- converted to v3 (xml2rfc v2v3 conversion 2.31.0) -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
]> submissionType="independent"
category="exp"
<?rfc rfcedstyle="yes"?> ipr="trust200902"
<?rfc toc="yes"?> number="8672"
<?rfc tocindent="yes"?> docName="draft-sheffer-tls-pinning-ticket-12"
<?rfc sortrefs="yes"?> obsoletes=""
<?rfc symrefs="yes"?> updates=""
<?rfc strict="yes"?> xml:lang="en"
<?rfc comments="yes"?> tocInclude="true"
<?rfc inline="yes"?> sortRefs="true"
<?rfc text-list-symbols="-o*+"?> symRefs="true"
version="3">
<rfc ipr="trust200902" docName="draft-sheffer-tls-pinning-ticket-12" category="e
xp">
<front> <front>
<title abbrev="Pinning Tickets">TLS Server Identity Pinning with Tickets</ti <title abbrev="Pinning with Tickets">TLS Server Identity Pinning with Ticket
tle> s</title>
<seriesInfo name="RFC" value="8672"/>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer"> <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
<organization>Intuit</organization> <organization>Intuit</organization>
<address> <address>
<email>yaronf.ietf@gmail.com</email> <email>yaronf.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="Migault" fullname="Daniel Migault"> <author initials="D." surname="Migault" fullname="Daniel Migault">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>daniel.migault@ericsson.com</email> <email>daniel.migault@ericsson.com</email>
</address> </address>
</author> </author>
<date month="October" year="2019"/>
<date year="2019" month="June" day="26"/>
<area>General</area> <area>General</area>
<keyword>public-key certificates, trust-on-first-use, TOFU</keyword>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>Misissued public-key certificates can prevent TLS clients from appropri
<t>Misissued public-key certificates can prevent TLS clients from appropriately ately
authenticating the TLS server. Several alternatives authenticating the TLS server. Several alternatives
have been proposed to detect this situation and prevent a client from establishi ng have been proposed to detect this situation and prevent a client from establishi ng
a TLS session with a TLS end point authenticated with an illegitimate a TLS session with a TLS end point authenticated with an illegitimate
public-key certificate. These mechanisms are either not public-key certificate. These mechanisms are either not
widely deployed or limited to public web browsing.</t> widely deployed or limited to public web browsing.</t>
<t>This document proposes experimental extensions to TLS with opaque
<t>This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity.
pinning tickets as a way to pin the server’s identity.
During an initial TLS session, During an initial TLS session,
the server provides an original encrypted pinning ticket. the server provides an original encrypted pinning ticket.
In subsequent TLS session establishment, upon receipt of the pinning ticket, In subsequent TLS session establishment, upon receipt of the pinning ticket,
the server proves its ability to decrypt the pinning ticket the server proves its ability to decrypt the pinning ticket
and thus the ownership of the pinning protection key. and thus the ownership of the pinning protection key.
The client can now safely conclude that the TLS session is established The client can now safely conclude that the TLS session is established
with the same TLS server as the original TLS session. with the same TLS server as the original TLS session.
One of the important properties of this proposal is that One of the important properties of this proposal is that
no manual management actions are required.</t> no manual management actions are required.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>Misissued public-key certificates can prevent TLS <xref target="RFC8446
<t>Misissued public-key certificates can prevent TLS <xref target="RFC8446"/> cl " format="default"/> clients from
ients from
appropriately authenticating the TLS server. This is a significant appropriately authenticating the TLS server. This is a significant
risk in the context of the global public key infrastructure (PKI), risk in the context of the global public key infrastructure (PKI),
and similarly for large scale and similarly for large-scale
deployments of certificates within enterprises.</t> deployments of certificates within enterprises.</t>
<t>This document proposes experimental extensions to TLS with opaque <t>This document proposes experimental extensions to TLS with opaque
pinning tickets as a way to pin the server’s identity. The approach 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 is intended to be easy to implement and deploy, and reuses some of
the ideas behind TLS session resumption <xref target="RFC5077"/>.</t> the ideas behind TLS session resumption <xref target="RFC5077" format="default"/ >.</t>
<t>Ticket pinning is a second factor server authentication method and is <t>Ticket pinning is a second-factor server authentication method and is
not proposed as a substitute for the authentication method provided in not proposed as a substitute for the authentication method provided in
the TLS key exchange. More specifically, the client only uses the 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 Pinning performed over an authenticated TLS session. Note that ticket pinning
does not pin certificate information and therefore is truly an does not pin certificate information and therefore is truly an
independent second factor authentication.</t> independent second-factor authentication.</t>
<t>Ticket pinning is a trust-on-first-use (TOFU) mechanism, in that the
<t>Ticket pinning is a Trust On First Use (TOFU) mechanism, in that the
first server authentication is only based on PKI certificate validation, first server authentication is only based on PKI certificate validation,
but for any follow-on sessions, the client is further ensuring the 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, server's identity based on the server's ability to decrypt the ticket,
in addition to normal PKI certificate authentication.</t> in addition to normal PKI certificate authentication.</t>
<t>During initial TLS session establishment, the client requests a pinning
<t>During initial TLS session establishment, the client requests a pinning
ticket from the server. Upon receiving the request the server generates ticket from the server. Upon receiving the request the server generates
a pinning secret which is expected to be unpredictable for peers other a pinning secret that is expected to be unpredictable for peers other
than the client or the server. In our case, the pinning secret is than the client or the server. In our case, the pinning secret is
generated from parameters exchanged during the TLS key exchange, so generated from parameters exchanged during the TLS key exchange, so
client and server can generate it locally and independently. The server client and server can generate it locally and independently. The server
constructs the pinning ticket with the necessary information to retrieve constructs the pinning ticket with the necessary information to retrieve
the pinning secret. The server then encrypts the ticket and returns the the pinning secret. The server then encrypts the ticket and returns the
pinning ticket to the client with an associated pinning lifetime.</t> pinning ticket to the client with an associated pinning lifetime.</t>
<t>The pinning lifetime value indicates for how long the server promises t
<t>The pinning lifetime value indicates for how long the server promises to o
retain the server-side ticket-encryption key, which allows it 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 commitment (and ticket lifetime) is typically on the order of server commitment (and ticket lifetime) is typically on the order of
weeks.</t> weeks.</t>
<t>Once the key exchange is completed, and the server is deemed
<t>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 as caches the server's identifiers to index the pinning secret as well as
the pinning ticket and its associated lifetime.</t> the pinning ticket and its associated lifetime.</t>
<t>When the client reestablishes a new TLS session with the server, it
<t>When the client re-establishes a new TLS session with the server, it
sends the pinning ticket to the server. Upon receiving it, the server sends the pinning ticket to the server. Upon receiving it, the server
returns a proof of knowledge of the pinning secret. Once the key returns a proof of knowledge of the pinning secret. Once the key
exchange is completed and the server has been authenticated, the client exchange is completed, and the server has been authenticated, the client
checks the pinning proof returned by the server using the client’s checks the pinning proof returned by the server using the client's
stored pinning secret. If the proof matches, the client can conclude stored pinning secret. If the proof matches, the client can conclude
that the server it is currently connecting to is in fact the correct that the server to which it is currently connecting is, in fact, the correct
server.</t> server.</t>
<t>This document only applies to TLS 1.3. <t>This document only applies to TLS 1.3.
We believe that the We believe that the
idea can also be back-fitted into earlier versions of the protocol, but idea can also be retrofitted into earlier versions of the protocol, but
this would require significant changes. this would require significant changes.
One example is that TLS 1.2 <xref target="RFC5246"/> and One example is that TLS 1.2 <xref target="RFC5246" format="default"/> and
earlier versions do not provide a generic facility of encrypted earlier versions do not provide a generic facility of encrypted
handshake extensions, such as is used here to transport the ticket.</t> handshake extensions, such as is used here to transport the ticket.</t>
<t>The main advantages of this protocol over earlier pinning solutions
<t>The main advantages of this protocol over earlier pinning solutions are:</t> are the following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The protocol is at the TLS level, and as a result is not restricted
<t>The protocol is at the TLS level, and as a result is not restricted to to
HTTP at the application level.</t> HTTP at the application level.</li>
<t>The protocol is robust to server IP, Certificate Authority (CA), <li>The protocol is robust to changes in server IP address,
and public key changes. The certification authority (CA), and public key. The
server is characterized by the ownership of the pinning protection key, server is characterized by the ownership of the pinning protection key,
which is never provided to the client. Server configuration parameters which is never provided to the client. Server configuration parameters
such as the CA and the public key may change without affecting the such as the CA and the public key may change without affecting the
pinning ticket protocol.</t> pinning ticket protocol.</li>
<t>Once a single parameter is configured (the ticket’s lifetime), operation <li>Once a single parameter is configured (the ticket's lifetime), opera
tion
is fully automated. The server administrator need not bother with the is fully automated. The server administrator need not bother with the
management of backup certificates or explicit pins.</t> management of backup certificates or explicit pins.</li>
<t>For server clusters, we reuse the existing <xref target="RFC5077"/> infrast <li>For server clusters, we reuse the existing infrastructure <xref targ
ructure et="RFC5077" format="default"/>
where it exists.</t> where it exists.</li>
<t>Pinning errors, presumably resulting from man-in-the-middle (MITM) attacks, <li>Pinning errors, presumably resulting from man-in-the-middle (MITM) a
ttacks,
can be detected can be detected
both by the client and the server. This allows for server-side detection both by the client and the server. This allows for server-side detection
of MITM attacks using large-scale analytics, and with no need to rely on of MITM attacks using large-scale analytics, and with no need to rely on
clients to explicitly report the error.</t> clients to explicitly report the error.</li>
</list></t> </ul>
<t>A note on terminology: unlike other solutions in this space, we do not
<t>A note on terminology: unlike other solutions in this space, we do not do "certificate pinning" (or "public key pinning"), since the protocol
do “certificate pinning” (or “public key pinning”), since the protocol is oblivious to the server's certificate. We prefer the term "server
is oblivious to the server’s certificate. We prefer the term “server identity pinning" for this new solution. In our solution, the server
identity pinning” for this new solution. In our solution, the server
proves its identity by generating a proof that it can read and decrypt proves its identity by generating a proof that it can read and decrypt
an encrypted ticket. As a result, the identity proof relies on proof of an encrypted ticket. As a result, the identity proof relies on proof of
ownership of the pinning protection key. However, this key is never ownership of the pinning protection key. However, this key is never
exchanged with the client or known by it, and so cannot itself be exchanged with the client or known by it, and so cannot itself be
pinned.</t> pinned.</t>
<section anchor="conventions-used-in-this-document" numbered="true" toc="d
<section anchor="conventions-used-in-this-document" title="Conventions used in t efault">
his document"> <name>Conventions Used in This Document</name>
<t>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
“MAY”, and “OPTIONAL” in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
appear in all capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
<section anchor="scope-of-experimentation" title="Scope of Experimentation"> </t>
</section>
<t>This document describes an experimental extension to the TLS protocol. <section anchor="scope-of-experimentation" numbered="true" toc="default">
<name>Scope of Experimentation</name>
<t>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.</t> This section defines constraints on this experiment and how it can yield useful information, potentially resulting in a standard.</t>
<t>The protocol is designed so that if the server does not support it, t
<t>The protocol is designed so that if the server does not support it, the clien he client and server fall back to a normal TLS exchange,
t and server fall back to a normal TLS exchange,
with the exception of a single PinningTicket extension being initially sent by t he client. with the exception of a single PinningTicket extension being initially sent by t he client.
In addition, the protocol is designed to only strengthen the validation of the s erver’s identity (“second factor”). In addition, the protocol is designed only to strengthen the validation of the s erver's identity ("second factor").
As a result, implementation or even protocol errors should not result in As a result, implementation or even protocol errors should not result in
weakened security compared to the normal TLS exchange. 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.</t> Given these two points, experimentation can be run on the open Internet between consenting client and server implementations.</t>
<t>The goal of the experiment is to prove that:</t>
<t>The goal of the experiment is to prove that:</t> <ul spacing="normal">
<li>Non-supporting clients and servers are unaffected.</li>
<t><list style="symbols"> <li>Connectivity between supporting clients and servers is retained un
<t>Non-supporting clients and servers are unaffected.</t> der normal circumstances,
<t>Connectivity between supporting clients and servers is retained under norma whether the client connects to the server frequently (relative to the ticket's l
l circumstances, ifetime) or very rarely.</li>
whether the client connects to the server frequently (relative to the ticket’s l <li>Enterprise middleboxes do not interrupt such connectivity.</li>
ifetime) or very rarely.</t> <li>Misissued certificates and rogue TLS-aware middleboxes do result i
<t>Enterprise middleboxes do not interrupt such connectivity.</t> n broken connectivity,
<t>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 serve rs can be recovered and these cases are detected on the client and/or server side. Clients and serve rs can be recovered
even after such events and the normal connectivity restored.</t> even after such events and the normal connectivity restored.</li>
</list></t> </ul>
<t>Following two years of successful deployment, the authors will publis
<t>Following two years of successful deployment, the authors will publish a docu h a document that summarizes
ment that summarizes the experiment's findings and will resubmit the protocol for
the experiment’s findings and will resubmit the protocol for
consideration as a Proposed Standard.</t> consideration as a Proposed Standard.</t>
</section>
</section> </section>
</section> <section anchor="protocol-overview" numbered="true" toc="default">
<section anchor="protocol-overview" title="Protocol Overview"> <name>Protocol Overview</name>
<t>The protocol consists of two phases: the first time a particular client
<t>The protocol consists of two phases: the first time a particular client
connects to a server, and subsequent connections.</t> connects to a server, and subsequent connections.</t>
<t>This protocol supports full TLS handshakes, as well as 0-RTT handshakes
<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 Below we present it in the context of a full handshake, but behavior in
0-RTT handshakes should be identical.</t> 0-RTT handshakes should be identical.</t>
<t>The document presents some similarities with the ticket resumption
<t>The document presents some similarities with the ticket resumption mechanism described in <xref target="RFC5077" format="default"/>. However the sc
mechanism described in <xref target="RFC5077"/>. However the scope of this docum ope of this document
ent differs from session resumption mechanisms implemented with <xref target="RFC507
differs from session resumption mechanisms implemented with <xref target="RFC507 7" format="default"/>
7"/>
or with other mechanisms. Specifically, the pinning ticket does not or with other mechanisms. Specifically, the pinning ticket does not
carry any state associated with a TLS session and thus cannot be used carry any state associated with a TLS session and thus cannot be used
for session resumption, or to authenticate the client. Instead, the for session resumption or client authentication. Instead, the
pinning ticket only contains the encrypted pinning secret. pinning ticket only contains the encrypted pinning secret.
The pinning ticket is used by the server to prove The pinning ticket is used by the server to prove
its ability to decrypt it, which implies ownership of the pinning its ability to decrypt it, which implies ownership of the pinning
protection key.</t> protection key.</t>
<t><xref target="RFC5077" format="default"/> has been obsoleted
<t><xref target="RFC5077"/> has been obsoleted by <xref target="RFC8446"/> and t by <xref target="RFC8446" format="default"/>, and ticket resumption is
icket resumption is now defined by <xref target="RFC8446" sectionFormat="of" section="2.2" format="
now defined by Sec. 2.2 of <xref target="RFC8446"/>. This document references default"/>. This document references
<xref target="RFC5077"/> as an informational document since it contains a more <xref target="RFC5077" format="default"/> as an informational document since it
thorough discussion of stateless ticket resumption and because contains a more
thorough discussion of stateless ticket resumption, and because
ticket resumption benefits ticket resumption benefits
from significant operational experience with TLS 1.2 that is still from significant operational experience with TLS 1.2 that is still
widely deployed at the time of writing this document. This experience widely deployed at the time of writing. This experience,
as well as deployment can easily be re-used for identity pinning.</t> as well as deployment experience, can easily be re-used for identity pinning.</t
>
<t>With TLS 1.3, session resumption is based on a preshared key (PSK). <t>With TLS 1.3, session resumption is based on a Pre-Shared Key (PSK).
This is orthogonal to this protocol. With TLS 1.3, a TLS session can be This is orthogonal to this protocol. With TLS 1.3, a TLS session can be
established using PKI and a pinning ticket, and later resumed with PSK.</t> established using PKI and a pinning ticket, and later resumed with PSK.</t>
<t>However, the protocol described in this document addresses the problem
<t>However, the protocol described in this document addresses the problem
of misissued certificates. Thus, it is not expected to be used outside a of misissued certificates. Thus, it is not expected to be used outside a
certificate-based TLS key exchange, such as in PSK. As a result, PSK certificate-based TLS key exchange, such as in PSK. As a result, PSK
handshakes MUST NOT include the extension defined here.</t> handshakes <bcp14>MUST NOT</bcp14> include the extension defined here.</t>
<section anchor="initial-connection" numbered="true" toc="default">
<section anchor="initial-connection" title="Initial Connection"> <name>Initial Connection</name>
<t>When a client first connects to a server, it requests a pinning ticke
<t>When a client first connects to a server, it requests a pinning ticket t
by sending an empty PinningTicket extension, and receives it as part of by sending an empty PinningTicket extension, and receives it as part of
the server’s first response, in the returned PinningTicket extension.</t> the server's first response, in the returned PinningTicket extension.</t>
<artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
Client Server Client Server
ClientHello ClientHello
+ key_share + key_share
+ signature_algorithms + signature_algorithms
+ PinningTicket --------> + PinningTicket -------->
ServerHello ServerHello
+ key_share + key_share
{EncryptedExtensions {EncryptedExtensions
+ PinningTicket} + PinningTicket}
skipping to change at line 279 skipping to change at line 250
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
* 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.
]]></artwork></figure> ]]></artwork>
<t>If a client supports the PinningTicket extension and does not have an
<t>If a client supports the PinningTicket extension and does not have any y
pinning ticket associated with the server, the exchange is considered as pinning ticket associated with the server, the exchange is considered as
an initial connection. Other reasons the client may not have a pinning an initial connection. Other reasons the client may not have a pinning
ticket include the client having flushed its pinning ticket store, or ticket include the client having flushed its pinning ticket store, or
the committed lifetime of the pinning ticket having expired.</t> the committed lifetime of the pinning ticket having expired.</t>
<t>Upon receipt of the PinningTicket extension, the server computes a
<t>Upon receipt of the PinningTicket extension, the server computes a pinning secret (<xref target="pinning-secret" format="default"/>) and sends the
pinning secret (<xref target="pinning-secret"/>), and sends the pinning ticket pinning ticket
(<xref target="pinning-ticket"/>) encrypted with the pinning protection key (<xref target="pinning-ticket" format="default"/>) encrypted with the pinning pr
(<xref target="pinning-ticket-key"/>). The pinning ticket is associated with a otection key
(<xref target="pinning-ticket-key" format="default"/>). The pinning ticket is a
ssociated with a
lifetime value by which the server assumes the responsibility of lifetime value by which the server assumes the responsibility of
retaining the pinning protection key and being able to decrypt incoming retaining the pinning protection key and being able to decrypt incoming
pinning tickets during the period indicated by the committed lifetime.</t> pinning tickets during the period indicated by the committed lifetime.</t>
<t>Once the pinning ticket has been generated, the server returns the
<t>Once the pinning ticket has been generated, the server returns the
pinning ticket and the committed lifetime in a PinningTicket extension pinning ticket and the committed lifetime in a PinningTicket extension
embedded in the EncryptedExtensions message. We note that a embedded in the EncryptedExtensions message. We note that a
PinningTicket extension MUST NOT be sent as part of a HelloRetryRequest.</t> PinningTicket extension <bcp14>MUST NOT</bcp14> be sent as part of a HelloRetryR
equest.</t>
<t>Upon receiving the pinning ticket, the client MUST NOT accept it until <t>Upon receiving the pinning ticket, the client <bcp14>MUST NOT</bcp14>
accept it until
the key exchange is completed and the server authenticated. If the key the key exchange is completed and the server authenticated. If the key
exchange is not completed successfully, the client MUST ignore the exchange is not completed successfully, the client <bcp14>MUST</bcp14> ignore th e
received pinning ticket. Otherwise, the client computes the pinning received pinning ticket. Otherwise, the client computes the pinning
secret and SHOULD cache the pinning secret and the pinning ticket for secret and <bcp14>SHOULD</bcp14> cache the pinning secret and the pinning ticket
the duration indicated by the pinning ticket lifetime. The client SHOULD for
the duration indicated by the pinning ticket lifetime. The client <bcp14>SHOULD<
/bcp14>
clean up the cached values at the end of the indicated lifetime.</t> clean up the cached values at the end of the indicated lifetime.</t>
</section>
</section> <section anchor="subsequent-connections" numbered="true" toc="default">
<section anchor="subsequent-connections" title="Subsequent Connections"> <name>Subsequent Connections</name>
<t>When the client initiates a connection to a server it has previously
<t>When the client initiates a connection to a server it has previously seen (see <xref target="indexing" format="default"/> on identifying servers), it
seen (see <xref target="indexing"/> on identifying servers), it SHOULD send the <bcp14>SHOULD</bcp14> send the
pinning ticket for that server. The pinning ticket, pinning secret and pinning ticket for that server. The pinning ticket, pinning secret, and
pinning ticket lifetime computed during the establishment of the pinning ticket lifetime computed during the establishment of the
previous TLS session are designated in this document as the “original” previous TLS session are designated in this document as the "original"
ones, to distinguish them from a new ticket that may be generated during ones, to distinguish them from a new ticket that may be generated during
the current session.</t> the current session.</t>
<t>The server <bcp14>MUST</bcp14> extract the original pinning_secret va
<t>The server MUST extract the original pinning_secret value from the lue from the
ticket and MUST respond with a PinningTicket extension, which includes:</t> ticket and <bcp14>MUST</bcp14> respond with a PinningTicket extension, which inc
ludes:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>A proof that the server can understand the ticket that was sent by the <li>A proof that the server can understand the ticket that was sent by
client; this proof also binds the pinning ticket to the server’s the
client; this proof also binds the pinning ticket to the server's
(current) public key, as well as the ongoing TLS session. The proof is (current) public key, as well as the ongoing TLS session. The proof is
mandatory and MUST be included if a pinning ticket was sent by the client.</t> mandatory and <bcp14>MUST</bcp14> be included if a pinning ticket was sent by th
<t>A fresh pinning ticket. The main reason for refreshing the ticket on e client.</li>
<li>A fresh pinning ticket. The main reason for refreshing the ticket
on
each connection is privacy: to avoid the ticket serving as a fixed each connection is privacy: to avoid the ticket serving as a fixed
client identifier. While a fresh pinning ticket might be of zero length, client identifier. While a fresh pinning ticket might be of zero length,
it is RECOMMENDED to include a fresh ticket with a non zero length with each it is <bcp14>RECOMMENDED</bcp14> to include a fresh ticket with a nonzero length
response.</t> with each
</list></t> response.</li>
</ul>
<t>If the server cannot validate the received ticket, that might indicate <t>If the server cannot validate the received ticket, that might indicat
an earlier MITM attack on this client. The server MUST then abort the e
connection with a handshake_failure alert, and SHOULD log this failure.</t> an earlier MITM attack on this client. The server <bcp14>MUST</bcp14> then abort
the
<t>The client MUST verify the proof, and if it fails to do so, MUST issue a connection with a handshake_failure alert and <bcp14>SHOULD</bcp14> log this fai
lure.</t>
<t>The client <bcp14>MUST</bcp14> verify the proof, and if it fails to d
o so,
the client <bcp14>MUST</bcp14> issue a
handshake_failure alert and abort the connection (see also handshake_failure alert and abort the connection (see also
<xref target="client_error"/>). It is important that the client does not attemp <xref target="client_error" format="default"/>). It is important that the clien
t to t does not attempt to
“fall back” by omitting the PinningTicket extension.</t> "fall back" by omitting the PinningTicket extension.</t>
<t>When the connection is successfully set up, i.e., after the Finished
<t>When the connection is successfully set up, i.e. after the Finished message is verified, the client <bcp14>SHOULD</bcp14> store the new ticket along
message is verified, the client SHOULD store the new ticket along with with
the corresponding pinning_secret, replacing the original ticket.</t> the corresponding pinning_secret, replacing the original ticket.</t>
<t>Although this is an extension, if the client already has a ticket for
<t>Although this is an extension, if the client already has a ticket for a a
server, the client MUST interpret a missing PinningTicket extension in server, the client <bcp14>MUST</bcp14> interpret a missing PinningTicket extensi
the server’s response as an attack, because of the server’s prior on in
commitment to respect the ticket. The client MUST abort the connection the server's response as an attack, because of the server's prior
in this case. See also <xref target="ramp_down"/> on ramping down support for t commitment to respect the ticket. The client <bcp14>MUST</bcp14> abort the conne
his ction
in this case. See also <xref target="ramp_down" format="default"/> on ramping d
own support for this
extension.</t> extension.</t>
</section>
<section anchor="indexing" numbered="true" toc="default">
<name>Indexing the Pins</name>
</section> <t>Each pin is associated with a set of identifiers that include, among
<section anchor="indexing" title="Indexing the Pins"> others, hostname, protocol (TLS or DTLS), and port
<t>Each pin is associated with a set of identifiers which include among
others host name, protocol (TLS or DTLS) and port
number. In other words, the pin for port TCP/443 may be different from 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. These identifiers are that for DTLS, or from the pin for port TCP/8443. These identifiers are
expected to be relevant to characterize the identity of the server as expected to be relevant to characterize the identity of the server as
well as the establishing TLS session. When a host name is used, it MUST be well as the establishing TLS session. When a hostname is used, it <bcp14>MUST</b cp14> be
the value sent inside the Server Name Indication (SNI) extension. This the value sent inside the Server Name Indication (SNI) extension. This
definition is similar to a Web Origin <xref target="RFC6454"/>, but does not ass ume definition is similar to the concept of a Web Origin <xref target="RFC6454" form at="default"/>, but does not assume
the existence of a URL.</t> the existence of a URL.</t>
<t>The purpose of ticket pinning is to pin the server identity. As a
<t>The purpose of ticket pinning is to pin the server identity. As a result, any information orthogonal to the server's identity <bcp14>MUST NOT</bcp
result, any information orthogonal to the server’s identity MUST NOT be 14> be
considered in indexing. More particularly, IP addresses are ephemeral considered in indexing. More particularly, IP addresses are ephemeral
and forbidden in SNI and therefore pins MUST NOT be associated with IP and forbidden in SNI, and therefore pins <bcp14>MUST NOT</bcp14> be associated w ith IP
addresses. Similarly, CA names or public keys associated with server addresses. Similarly, CA names or public keys associated with server
MUST NOT be used for indexing as they may change over time.</t> <bcp14>MUST NOT</bcp14> be used for indexing as they may change over time.</t>
</section>
</section> </section>
</section> <section anchor="message-definitions" numbered="true" toc="default">
<section anchor="message-definitions" title="Message Definitions"> <name>Message Definitions</name>
<t>This section defines the format of the PinningTicket extension.
<t>This section defines the format of the PinningTicket extension. We follow the message notation of <xref target="RFC8446" format="default"/>.</t>
We follow the message notation of <xref target="RFC8446"/>.</t> <sourcecode name="" type="c"><![CDATA[
<figure><artwork><![CDATA[
opaque pinning_ticket<0..2^16-1>; opaque pinning_ticket<0..2^16-1>;
opaque pinning_proof<0..2^8-1>; opaque pinning_proof<0..2^8-1>;
struct { struct {
select (Role) { select (Role) {
case client: case client:
pinning_ticket ticket<0..2^16-1>; //omitted on 1st connection pinning_ticket ticket<0..2^16-1>; //omitted on 1st connection
case server: case server:
pinning_proof proof<0..2^8-1>; //no proof on 1st connection pinning_proof proof<0..2^8-1>; //no proof on 1st connection
pinning_ticket ticket<0..2^16-1>; //omitted on ramp down pinning_ticket ticket<0..2^16-1>; //omitted on ramp down
uint32 lifetime; uint32 lifetime;
} }
} PinningTicketExtension; } PinningTicketExtension;
]]></artwork></figure> ]]></sourcecode>
<dl newline="false" spacing="normal" indent="10">
<t><list style="hanging"> <dt>ticket</dt>
<t hangText='ticket'> <dd>
a pinning ticket sent by the client or returned by the server. The 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 ticket is opaque to the client. The extension <bcp14>MUST</bcp14> contain exactl
1 tickets.</t> y 0 or
<t hangText='proof'> 1 tickets.</dd>
<dt>proof</dt>
<dd>
a demonstration by the server that it understands the received ticket a demonstration by the server that it understands the received ticket
and therefore that it is in possession of the secret that was used to and therefore that it is in possession of the secret that was used to
generate it originally. The extension MUST contain exactly 0 or 1 generate it originally. The extension <bcp14>MUST</bcp14> contain exactly 0 or
proofs.</t> 1
<t hangText='lifetime'> proofs.</dd>
<dt>lifetime</dt>
<dd>
the duration (in seconds) that the server commits to accept offered the duration (in seconds) that the server commits to accept offered
tickets in the future.</t> tickets in the future.</dd>
</list></t> </dl>
</section>
</section> <section anchor="crypto" numbered="true" toc="default">
<section anchor="crypto" title="Cryptographic Operations"> <name>Cryptographic Operations</name>
<t>This section provides details on the cryptographic operations performed
<t>This section provides details on the cryptographic operations performed
by the protocol peers.</t> by the protocol peers.</t>
<section anchor="pinning-secret" numbered="true" toc="default">
<section anchor="pinning-secret" title="Pinning Secret"> <name>Pinning Secret</name>
<t>The pinning secret is generated locally by the client and the server,
<t>The pinning secret is generated locally by the client and the server
which means they must use the same inputs to generate it. This value which means they must use the same inputs to generate it. This value
must be generated before the ServerHello message is sent, as the server must be generated before the ServerHello message is sent, as the server
includes the corresponding pinning ticket in the same flight as the includes the corresponding pinning ticket in the same flight as the
ServerHello message. In addition, the pinning secret must be ServerHello message. In addition, the pinning secret must be
unpredictable to any party other than the client and the server.</t> unpredictable to any party other than the client and the server.</t>
<t>The pinning secret is derived using the Derive-Secret function provid
<t>The pinning secret is derived using the Derive-Secret function provided ed
by TLS 1.3, described in Section “Key Schedule” of <xref target="RFC8446"/>.</t> by TLS 1.3, described in <xref target="RFC8446" sectionFormat="of" section="7.1"
format="default"/>.</t>
<figure><artwork><![CDATA[ <sourcecode name="" type="c"><![CDATA[
pinning secret = Derive-Secret(Handshake Secret, "pinning secret", pinning secret = Derive-Secret(Handshake Secret, "pinning secret",
ClientHello...ServerHello) ClientHello...ServerHello)
]]></artwork></figure> ]]></sourcecode>
</section>
</section> <section anchor="pinning-ticket" numbered="true" toc="default">
<section anchor="pinning-ticket" title="Pinning Ticket"> <name>Pinning Ticket</name>
<t>The pinning ticket contains the pinning secret. The pinning ticket is
<t>The pinning ticket contains the pinning secret. The pinning ticket is provided by the client to the server, which decrypts it in order to
provided by the client to the server which decrypts it in order to
extract the pinning secret and responds with a pinning proof. As a extract the pinning secret and responds with a pinning proof. As a
result, the characteristics of the pinning ticket are:</t> result, the characteristics of the pinning ticket are:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Pinning tickets <bcp14>MUST</bcp14> be encrypted and integrity-pro
<t>Pinning tickets MUST be encrypted and integrity-protected using strong tected using strong
cryptographic algorithms.</t> cryptographic algorithms.</li>
<t>Pinning tickets MUST be protected with a long-term pinning protection <li>Pinning tickets <bcp14>MUST</bcp14> be protected with a long-term
key.</t> pinning protection
<t>Pinning tickets MUST include a pinning protection key ID or serial key.</li>
number as to enable the pinning protection key to be refreshed.</t> <li>Pinning tickets <bcp14>MUST</bcp14> include a pinning protection k
<t>The pinning ticket MAY include other information, in addition to the ey ID or serial
number as to enable the pinning protection key to be refreshed.</li>
<li>The pinning ticket <bcp14>MAY</bcp14> include other information, i
n addition to the
pinning secret. When additional information is included, a careful pinning secret. When additional information is included, a careful
review needs to be performed to evaluate its impact on privacy.</t> review needs to be performed to evaluate its impact on privacy.</li>
</list></t> </ul>
<t>The pinning ticket’s format is not specified by this document, but we
RECOMMEND a format similar to the one proposed by <xref target="RFC5077"/>.</t>
</section>
<section anchor="pinning-ticket-key" title="Pinning Protection Key">
<t>The pinning protection key is only used by the server and so remains <t>The pinning ticket's format is not specified by this document, but
server implementation specific. <xref target="RFC5077"/> recommends the use of t a format similar to the one proposed by <xref target="RFC5077" format="default"/
wo >
keys, but when using AEAD algorithms only a single key is required.</t> is <bcp14>RECOMMENDED</bcp14>.</t>
</section>
<section anchor="pinning-ticket-key" numbered="true" toc="default">
<name>Pinning Protection Key</name>
<t>The pinning protection key is used only by the server and so remains
server implementation specific. <xref target="RFC5077" format="default"/> recomm
ends the use of two
keys, but when using Authenticated Encryption with Associated Data (AEAD) algori
thms,
only a single key is required.</t>
<t>When a single server terminates TLS for multiple virtual servers using <t>When a single server terminates TLS for multiple virtual servers usin
the Server Name Indication (SNI) mechanism, we strongly RECOMMEND to use g
the SNI mechanism, it is strongly <bcp14>RECOMMENDED</bcp14> that the server use
a separate protection key for each one of them, in order to allow a separate protection key for each one of them, in order to allow
migrating virtual servers between different servers while keeping migrating virtual servers between different servers while keeping
pinning active.</t> pinning active.</t>
<t>As noted in <xref target="cluster" format="default"/>, if the server
<t>As noted in <xref target="cluster"/>, if the server is actually a cluster of is actually a cluster of
machines, the protection key MUST be synchronized between all the nodes machines, the protection key <bcp14>MUST</bcp14> be synchronized between all the
that accept TLS connections to the same server name. When <xref target="RFC5077 nodes
"/> that accept TLS connections to the same server name. When <xref target="RFC5077
" format="default"/>
is deployed, an easy way to do it is to derive the protection key from is deployed, an easy way to do it is to derive the protection key from
the session-ticket protection key, which is already synchronized. For the session-ticket protection key, which is already synchronized. For
example:</t> example:</t>
<sourcecode name="" type="c"><![CDATA[
<figure><artwork><![CDATA[
pinning_protection_key = HKDF-Expand(resumption_protection_key, pinning_protection_key = HKDF-Expand(resumption_protection_key,
"pinning protection", L) "pinning protection", L)
]]></artwork></figure> ]]></sourcecode>
<t>Where resumption_protection_key is the ticket protection key defined
<t>Where resumption_protection_key is the ticket protection key defined in in
<xref target="RFC5077"/>. Both resumption_protection_key and pinning_protection_ <xref target="RFC5077" format="default"/>. Both resumption_protection_key and pi
key nning_protection_key
are only used by the server.</t> are only used by the server.</t>
<t>The above solution attempts to minimize code changes related to management of the resumption_protection_key. <t>The above solution attempts to minimize code changes related to manag ement of the resumption_protection_key.
The drawback is that this key would be used both to directly encrypt session tic kets and to derive The drawback is that this key would be used both to directly encrypt session tic kets and to derive
the pinning_protection_key, and such mixed usage of a single key is not in line with cryptographic best practices. the pinning_protection_key, and such mixed usage of a single key is not in line with cryptographic best practices.
Where possible, we RECOMMEND to have the resumption_protection_key and pinning_p Where possible, it is <bcp14>RECOMMENDED</bcp14> that the resumption_protection_
rotection_key as two, key
unrelated keys that are separately shared among the relevant servers.</t> be unrelated to the pinning_protection_key and that they are separately
shared among the relevant servers.</t>
</section> </section>
<section anchor="pinning-proof" title="Pinning Proof"> <section anchor="pinning-proof" numbered="true" toc="default">
<name>Pinning Proof</name>
<t>The pinning proof is sent by the server to demonstrate that it has been <t>The pinning proof is sent by the server to demonstrate that it has be
able to decrypt the pinning ticket and retrieve the pinning secret. The en
able to decrypt the pinning ticket and to retrieve the pinning secret. The
proof must be unpredictable and must not be replayed. Similarly to the proof must be unpredictable and must not be replayed. Similarly to the
pinning ticket, the pinning proof is sent by the server in the pinning ticket, the pinning proof is sent by the server in the
ServerHello message. In addition, it must not be possible for a MITM ServerHello message. In addition, it must not be possible for a MITM
server with a fake certificate to obtain a pinning proof from the server with a fake certificate to obtain a pinning proof from the
original server.</t> original server.</t>
<t>In order to address these requirements, the pinning proof is bound to
<t>In order to address these requirements, the pinning proof is bound to
the TLS session as well as the public key of the server:</t> the TLS session as well as the public key of the server:</t>
<sourcecode name="" type="c"><![CDATA[
<figure><artwork><![CDATA[ pinning_proof_secret=Derive-Secret(Handshake Secret,
pinning_proof_secret=Derive-Secret(Handshake Secret, "pinning proof 1", "pinning proof 1", ClientHello...ServerHello)
ClientHello...ServerHello)
proof = HMAC(original_pinning_secret, "pinning proof 2" + proof = HMAC(original_pinning_secret, "pinning proof 2" +
pinning_proof_secret + Hash(server_public_key)) pinning_proof_secret + Hash(server_public_key))
]]></artwork></figure> ]]></sourcecode>
<t>where HMAC <xref target="RFC2104" format="default"/> uses the Hash al
<t>where HMAC <xref target="RFC2104"/> uses the Hash algorithm that was negotiat gorithm that was negotiated in
ed in the handshake, and the same hash is also used over the server's public
the handshake, and the same hash is also used over the server’s public
key. The original_pinning_secret value refers to the secret value key. The original_pinning_secret value refers to the secret value
extracted from the ticket sent by the client, to distinguish it from a extracted from the ticket sent by the client, to distinguish it from a
new pinning secret value that is possibly computed in the current new pinning secret value that is possibly computed in the current
exchange. The server_public_key value is the DER representation of exchange. The server_public_key value is the DER representation of
the public key, specifically the SubjectPublicKeyInfo structure as-is.</t> the public key, specifically the SubjectPublicKeyInfo structure as-is.</t>
</section>
</section> </section>
</section> <section anchor="operational-considerations" numbered="true" toc="default">
<section anchor="operational-considerations" title="Operational Considerations"> <name>Operational Considerations</name>
<t>The main motivation behind the current protocol is to enable identity
<t>The main motivation behind the current protocol is to enable identity
pinning without the need for manual operations. Manual operations are pinning without the need for manual operations. Manual operations are
susceptible to human error and in the case of public key pinning, can susceptible to human error, and in the case of public key pinning, can
easily result in “server bricking”: the server becoming inaccessible to easily result in "server bricking": the server becoming inaccessible to
some or all of its users. To achieve this goal operations described in some or all of its users. To achieve this goal, operations described in
identity pinning are only performed within the current TLS session, and identity pinning are only performed within the current TLS session, and
there is no dependence on any TLS configuration parameters such as CA there is no dependence on any TLS configuration parameters such as CA
identity or public keys. As a result, configuration changes are identity or public keys. As a result, configuration changes are
unlikely to lead to desynchronized state between the client and the unlikely to lead to desynchronized state between the client and the
server.</t> server.</t>
<section anchor="cluster" numbered="true" toc="default">
<section anchor="cluster" title="Protection Key Synchronization"> <name>Protection Key Synchronization</name>
<t>The only operational requirement when deploying this protocol is that
<t>The only operational requirement when deploying this protocol is that if , if
the server is part of a cluster, protection keys (the keys used to the server is part of a cluster, protection keys (the keys used to
encrypt tickets) MUST be synchronized between all cluster members. The encrypt tickets) <bcp14>MUST</bcp14> be synchronized between all cluster members . The
protocol is designed so that if resumption ticket protection keys protocol is designed so that if resumption ticket protection keys
<xref target="RFC5077"/> are already synchronized between cluster members, nothi ng <xref target="RFC5077" format="default"/> are already synchronized between clust er members, nothing
more needs to be done.</t> more needs to be done.</t>
<t>Moreover, synchronization does not need to be instantaneous, e.g.,
<t>Moreover, synchronization does not need to be instantaneous, e.g.
protection keys can be distributed a few minutes or hours in advance of protection keys can be distributed a few minutes or hours in advance of
their rollover. In such scenarios, each cluster member MUST be able to their rollover. In such scenarios, each cluster member <bcp14>MUST</bcp14> be ab le to
accept tickets protected with a new version of the protection key, even accept tickets protected with a new version of the protection key, even
while it is still using an old version to generate keys. This ensures while it is still using an old version to generate keys. This ensures
that a client that receives a “new” ticket does not next hit a cluster that, when a client receives a "new" ticket, it does not next hit a cluster
member that still rejects this ticket.</t> member that still rejects this ticket.</t>
<t>Misconfiguration can lead to the server's clock being off by a large
<t>Misconfiguration can lead to the server’s clock being off by a large amount of time. Consider a case where a server's clock is misconfigured,
amount of time. Consider a case where a server’s clock is misconfigured,
for example, to be 1 year in for example, to be 1 year in
the future, and the system is allowed to delete expired keys automatically. the future, and the system is allowed to delete expired keys automatically.
The server will then delete many outstanding keys because they are now The server will then delete many outstanding keys because they are now
long expired and will end up rejecting valid tickets that are stored long expired and will end up rejecting valid tickets that are stored
by clients. Such a scenario could make the server by clients. Such a scenario could make the server
inaccessible to a large number of clients.</t> inaccessible to a large number of clients.</t>
<t>The decision to delete a key should at least consider
<t>The decision to delete a key should at least consider
the largest value of the ticket lifetime as well as the expected time the largest value of the ticket lifetime as well as the expected time
desynchronisation between the servers of the cluster and the time desynchronization between the servers of the cluster and the time
difference for distributing the new key among the different servers in difference for distributing the new key among the different servers in
the cluster.</t> the cluster.</t>
</section>
</section> <section anchor="ticket-lifetime" numbered="true" toc="default">
<section anchor="ticket-lifetime" title="Ticket Lifetime"> <name>Ticket Lifetime</name>
<t>The lifetime of the ticket is a commitment by the server to retain th
<t>The lifetime of the ticket is a commitment by the server to retain the e
ticket’s corresponding protection key for this duration, so that the ticket's corresponding protection key for this duration, so that the
server can prove to the client that it knows the secret embedded in the server can prove to the client that it knows the secret embedded in the
ticket. For production systems, the lifetime SHOULD be between 7 and 31 ticket. For production systems, the lifetime <bcp14>SHOULD</bcp14> be between 7 and 31
days.</t> days.</t>
</section>
</section> <section anchor="certificate-renewal" numbered="true" toc="default">
<section anchor="certificate-renewal" title="Certificate Renewal"> <name>Certificate Renewal</name>
<t>The protocol ensures that the client will continue speaking to the
<t>The protocol ensures that the client will continue speaking to the correct server even when the server's certificate is renewed. In this
correct server even when the server’s certificate is renewed. In this sense, pinning is not associated with certificates, which is the reason we
sense, pinning is not associated with certificates which is the reason we designate the protocol described in this document as "server identity
designate the protocol described in this document as “server identity pinning".</t>
pinning”.</t> <t>Note that this property is not impacted by the use of the server's
public key in the pinning proof because the scope of the public key
<t>Note that this property is not impacted by the use of the server’s
public key in the pinning proof, because the scope of the public key
used is only the current TLS session.</t> used is only the current TLS session.</t>
</section>
</section> <section anchor="certificate-revocation" numbered="true" toc="default">
<section anchor="certificate-revocation" title="Certificate Revocation"> <name>Certificate Revocation</name>
<t>The protocol is orthogonal to certificate validation in the sense tha
<t>The protocol is orthogonal to certificate validation in the sense that, t,
if the server’s certificate has been revoked or is invalid for some if the server's certificate has been revoked or is invalid for some
other reason, the client MUST refuse to connect to it regardless of any other reason, the client <bcp14>MUST</bcp14> refuse to connect to it regardless
of any
ticket-related behavior.</t> ticket-related behavior.</t>
</section>
</section> <section anchor="ramp_down" numbered="true" toc="default">
<section anchor="ramp_down" title="Disabling Pinning"> <name>Disabling Pinning</name>
<t>A server implementing this protocol <bcp14>MUST</bcp14> have a "ramp
<t>A server implementing this protocol MUST have a “ramp down” mode of down" mode of
operation where:</t> operation where:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The server continues to accept valid pinning tickets and responds
<t>The server continues to accept valid pinning tickets and responds correctly with a proof.</li>
correctly with a proof.</t> <li>The server does not send back a new pinning ticket.</li>
<t>The server does not send back a new pinning ticket.</t> </ul>
</list></t> <t>After a while, no clients will hold valid tickets, and the
<t>After a while no clients will hold valid tickets any more and the
feature may be disabled. Note that clients that do not receive a new feature may be disabled. Note that clients that do not receive a new
pinning ticket do not necessarily need to remove the original ticket. pinning ticket do not necessarily need to remove the original ticket.
Instead, the client may keep on using the ticket until its lifetime Instead, the client may keep using the ticket until its lifetime
expires. However, as detailed in section <xref target="privacy"/>, re-use of a expires. However, as detailed in <xref target="privacy" format="default"/>, re-u
se of a
ticket by the client may result in privacy concerns as the ticket value ticket by the client may result in privacy concerns as the ticket value
may be used to correlate TLS sessions.</t> may be used to correlate TLS sessions.</t>
<t>Issuing a new pinning ticket with a shorter lifetime would only delay
<t>Issuing a new pinning ticket with a shorter lifetime would only delay
the ramp down process, as the shorter lifetime can only affect clients the ramp down process, as the shorter lifetime can only affect clients
that actually initiated a new connection. Other clients would still see that actually initiated a new connection. Other clients would still see
the original lifetime for their pinning tickets.</t> the original lifetime for their pinning tickets.</t>
</section>
</section> <section anchor="server-compromise" numbered="true" toc="default">
<section anchor="server-compromise" title="Server Compromise"> <name>Server Compromise</name>
<t>If a server compromise is detected, the pinning protection key <bcp14
<t>If a server compromise is detected, the pinning protection key MUST be >MUST</bcp14> be
rotated immediately, but the server MUST still accept valid tickets that rotated immediately, but the server <bcp14>MUST</bcp14> still accept valid ticke
ts that
use the old, compromised key. Clients that still hold old pinning use the old, compromised key. Clients that still hold old pinning
tickets will remain vulnerable to MITM attacks, but those that connect tickets will remain vulnerable to MITM attacks, but those that connect
to the correct server will immediately receive new tickets protected to the correct server will immediately receive new tickets protected
with the newly generated pinning protection key.</t> with the newly generated pinning protection key.</t>
<t>The same procedure applies if the pinning protection key is compromis
<t>The same procedure applies if the pinning protection key is compromised ed
directly, e.g. if a backup copy is inadvertently made public.</t> directly, e.g., if a backup copy is inadvertently made public.</t>
</section>
</section> <section anchor="disaster-recovery" numbered="true" toc="default">
<section anchor="disaster-recovery" title="Disaster Recovery"> <name>Disaster Recovery</name>
<t>All web servers in production need to be backed up, so that they can
<t>All web servers in production need to be backed up, so that they can be be
recovered if a disaster (including a malicious activity) ever wipes them recovered if a disaster (including a malicious activity) ever wipes them
out. Backup often includes the certificate and its private key, which out. Backup often includes the certificate and its private key, which
must be backed up securely. The pinning secret, including earlier must be backed up securely. The pinning secret, including earlier
versions that are still being accepted, must be backed up regularly. versions that are still being accepted, must be backed up regularly.
However since it is only used as an authentication second factor, it However since it is only used as an authentication second factor, it
does not require the same level of confidentiality as the server’s does not require the same level of confidentiality as the server's
private key.</t> private key.</t>
<t>Readers should note that <xref target="RFC5077" format="default"/> se
<t>Readers should note that <xref target="RFC5077"/> session resumption keys are ssion resumption keys are more
more security sensitive and should normally not be backed up, but rather
security sensitive, and should normally not be backed up but rather
treated as ephemeral keys. Even when servers derive pinning secrets from treated as ephemeral keys. Even when servers derive pinning secrets from
resumption keys (<xref target="pinning-secret"/>), they MUST NOT back up resumpt ion resumption keys (<xref target="pinning-secret" format="default"/>), they <bcp14> MUST NOT</bcp14> back up resumption
keys.</t> keys.</t>
</section>
</section>
</section> <section anchor="security-considerations" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<section anchor="implementation-status" title="Implementation Status"> <t>This section reviews several security aspects related to the proposed
<t>Note to RFC Editor: please remove this section before publication,
including the reference to <xref target="RFC7942"/>.</t>
<t>This section records the status of known implementations of the protocol
defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in <xref target="RFC7942"><
/xref>. The
description of implementations in this section is intended to assist the
IETF in its decision processes in progressing drafts to RFCs. Please
note that the listing of any individual implementation here does not
imply endorsement by the IETF. Furthermore, no effort has been spent to
verify the information presented here that was supplied by IETF
contributors. This is not intended as, and must not be construed to be,
a catalog of available implementations or their features. Readers are
advised to note that other implementations may exist.</t>
<t>According to RFC 7942, “this will allow reviewers and working groups to
assign due consideration to documents that have the benefit of running
code, which may serve as evidence of valuable experimentation and
feedback that have made the implemented protocols more mature. It is up
to the individual working groups to use this information as they see
fit”.</t>
<section anchor="mint-fork" title="Mint Fork">
<section anchor="overview" title="Overview">
<t>A fork of the Mint TLS 1.3 implementation, developed by Yaron Sheffer
and available at https://github.com/yaronf/mint.</t>
</section>
<section anchor="description" title="Description">
<t>This is a fork of the TLS 1.3 implementation, and includes client and
server code. In addition to the actual protocol, several utilities are
provided allowing to manage pinning protection keys on the server side,
and pinning tickets on the client side.</t>
</section>
<section anchor="level-of-maturity" title="Level of Maturity">
<t>This is a prototype.</t>
</section>
<section anchor="coverage" title="Coverage">
<t>The entire protocol is implemented.</t>
</section>
<section anchor="version-compatibility" title="Version Compatibility">
<t>The implementation is compatible with draft-sheffer-tls-pinning-ticket-02.</t
>
</section>
<section anchor="licensing" title="Licensing">
<t>Mint itself and this fork are available under an MIT license.</t>
</section>
<section anchor="contact-information" title="Contact Information">
<t>See author details below.</t>
</section>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>This section reviews several security aspects related to the proposed
extension.</t> extension.</t>
<section anchor="trust-on-first-use-tofu-and-mitm-attacks" numbered="true"
<section anchor="trust-on-first-use-tofu-and-mitm-attacks" title="Trust on First toc="default">
Use (TOFU) and MITM Attacks"> <name>Trust-on-First-Use (TOFU) and MITM Attacks</name>
<t>This protocol is a trust-on-first-use protocol. If a client initially
<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
connects to the “right” server, it will be protected against MITM
attackers for the lifetime of each received ticket. If it connects attackers for the lifetime of each received ticket. If it connects
regularly (depending of course on the server-selected lifetime), it will regularly (depending, of course, on the server-selected lifetime), it will
stay constantly protected against fake certificates.</t> stay constantly protected against fake certificates.</t>
<t>However if it initially connects to an attacker, subsequent connectio
<t>However if it initially connects to an attacker, subsequent connections ns
to the “right” server will fail. Server operators might want to advise to the "right" server will fail. Server operators might want to advise
clients on how to remove corrupted pins, once such large scale attacks clients on how to remove corrupted pins, once such large-scale attacks
are detected and remediated.</t> are detected and remediated.</t>
<t>The protocol is designed so that it is not vulnerable to an active MI
<t>The protocol is designed so that it is not vulnerable to an active MITM TM
attacker who has real-time access to the original server. The pinning 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 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 that the proof was in fact generated by the server with which it is
initiating the connection.</t> initiating the connection.</t>
</section>
</section> <section anchor="pervasive-monitoring" numbered="true" toc="default">
<section anchor="pervasive-monitoring" title="Pervasive Monitoring"> <name>Pervasive Monitoring</name>
<t>Some organizations, and even some countries, perform pervasive monito
<t>Some organizations, and even some countries perform pervasive monitoring ring
on their constituents <xref target="RFC7258"/>. This often takes the form of on their constituents <xref target="RFC7258" format="default"/>. This often take
s the form of
always-active SSL proxies. Because of the TOFU property, this protocol always-active SSL proxies. Because of the TOFU property, this protocol
does not provide any security in such cases.</t> does not provide any security in such cases.</t>
<t>Pervasive monitoring may also result in privacy concerns detailed in
<t>Pervasive monitoring may also result in privacy concerns detailed in <xref target="privacy" format="default"/>.</t>
section <xref target="privacy"/>.</t> </section>
<section anchor="server_error" numbered="true" toc="default">
</section> <name>Server-Side Error Detection</name>
<section anchor="server_error" title="Server-Side Error Detection"> <t>Uniquely, this protocol allows the server to detect clients that pres
ent
<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 incorrect tickets and therefore can be assumed to be victims of a MITM
attack. Server operators can use such cases as indications of ongoing attack. Server operators can use such cases as indications of ongoing
attacks, similarly to fake certificate attacks that took place in a few attacks, similarly to fake certificate attacks that took place in a few
countries in the past.</t> countries in the past.</t>
</section>
</section> <section anchor="client_policy" numbered="true" toc="default">
<section anchor="client_policy" title="Client Policy and SSL Proxies"> <name>Client Policy and SSL Proxies</name>
<t>Like it or not, some clients are normally deployed behind an SSL prox
<t>Like it or not, some clients are normally deployed behind an SSL proxy. y.
Similarly to <xref target="RFC7469"/>, it is acceptable to allow pinning to be Similar to <xref target="RFC7469" format="default"/>, it is acceptable to allow
pinning to be
disabled for some hosts according to local policy. For example, disabled for some hosts according to local policy. For example,
a User Agent (UA) MAY a User Agent (UA) <bcp14>MAY</bcp14>
disable pinning for hosts whose validated certificate chain terminates disable pinning for hosts whose validated certificate chain terminates
at a user-defined trust anchor, rather than a trust anchor built-in to at a user-defined trust anchor, rather than a trust anchor built into
the UA (or underlying platform). Moreover, a client MAY accept an empty the UA (or underlying platform). Moreover, a client <bcp14>MAY</bcp14> accept an
empty
PinningTicket extension from such hosts as a valid response.</t> PinningTicket extension from such hosts as a valid response.</t>
</section>
<section anchor="client_error" numbered="true" toc="default">
<name>Client-Side Error Behavior</name>
</section> <t>When a client receives a malformed or empty PinningTicket extension f
<section anchor="client_error" title="Client-Side Error Behavior"> rom
a pinned server, it <bcp14>MUST</bcp14> abort the handshake. If the client
<t>When a client receives a malformed or empty PinningTicket extension from retries the request, it <bcp14>MUST NOT</bcp14> omit the
a pinned server, it MUST abort the handshake and MUST NOT retry with no PinningTicket in the retry message. Doing otherwise would expose the client to
PinningTicket in the request. Doing otherwise would expose the client to trivial fallback attacks, similar to those described in <xref target="RFC7507" f
trivial fallback attacks, similar to those described in <xref target="RFC7507"/> ormat="default"/>.</t>
.</t> <t>However, this rule can negatively impact clients that move from
behind SSL proxies into the open Internet, and vice versa, if the advice
<t>This rule can however have negative affects on clients that move from in <xref target="client_policy" format="default"/> is not followed. Therefore,
behind SSL proxies into the open Internet and vice versa, if the advice it is <bcp14>RECOMMENDED</bcp14> that
in <xref target="client_policy"/> is not followed. Therefore, we RECOMMEND that
browser and library vendors provide a documented way to remove stored browser and library vendors provide a documented way to remove stored
pins.</t> pins.</t>
</section>
</section> <section anchor="stolen-and-forged-tickets" numbered="true" toc="default">
<section anchor="stolen-and-forged-tickets" title="Stolen and Forged Tickets"> <name>Stolen and Forged Tickets</name>
<t>An attacker gains no benefit from stealing pinning tickets, even in c
<t>Stealing pinning tickets even in conjunction with other pinning onjunction with other pinning
parameters, such as the associated pinning secret, provides no benefit parameters such as the associated pinning secret, since pinning tickets are used
to the attacker since pinning tickets are used to secure the client to secure the client
rather than the server. Similarly, it is useless to forge a ticket for rather than the server. Similarly, it is useless to forge a ticket for
a particular server.</t> a particular server.</t>
</section>
<section anchor="privacy" numbered="true" toc="default">
<name>Client Privacy</name>
</section> <t>This protocol is designed so that an external attacker cannot link
<section anchor="privacy" title="Client Privacy"> different requests to a single client, provided the client
<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. This may be requests and receives a fresh ticket upon each connection. This may be
of concern particularly during ramp-down, if the server does not provide of concern particularly during ramp down, if the server does not provide
any new ticket and the client re-uses the same ticket. To reduce or avoid such a new ticket, and the client reuses the same ticket. To reduce or avoid such
privacy concerns, it is RECOMMENDED for the server to issue a fresh ticket with privacy concerns, it is <bcp14>RECOMMENDED</bcp14> for the server to issue a fre
a sh ticket with a
reduced life time. This would at least reduce the time period under reduced lifetime. This would at least reduce the time period in which
which TLS session of the client are correlated. The server MAY also the TLS sessions of the client can be linked. The server <bcp14>MAY</bcp14> also
issue tickets with a zero second lifetime until it is confident all issue tickets with a zero-second lifetime until it is confident all
tickets are expired.</t> tickets are expired.</t>
<t>On the other hand, the server to which the client is connecting can
<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 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. 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 Implementations <bcp14>SHOULD</bcp14> allow the user to opt out of pinning, eith er in
general or for particular servers.</t> general or for particular servers.</t>
<t>This document does not define the exact content of tickets.
<t>This document does not define the exact content of tickets.
Including client-specific information in tickets would raise privacy concerns Including client-specific information in tickets would raise privacy concerns
and is NOT RECOMMENDED.</t> and is <bcp14>NOT RECOMMENDED</bcp14>.</t>
</section>
</section> <section anchor="ticket-protection-key-management" numbered="true" toc="de
<section anchor="ticket-protection-key-management" title="Ticket Protection Key fault">
Management"> <name>Ticket Protection Key Management</name>
<t>While the ticket format is not mandated by this document, we RECOMMEND <t>While the ticket format is not mandated by this document, protecti
using authenticated encryption to protect it. Some of the algorithms ng
commonly used for authenticated encryption, e.g. GCM, are highly the ticket using authenticated encryption is <bcp14>RECOMMENDED</bcp14>. Some of
the algorithms
commonly used for authenticated encryption, e.g., Galois/Counter Mode (GCM), are
highly
vulnerable to nonce reuse, and this problem is magnified in a cluster vulnerable to nonce reuse, and this problem is magnified in a cluster
setting. Therefore implementations that choose AES-GCM or any AEAD setting. Therefore, implementations that choose AES-GCM or any AEAD
equivalent MUST adopt equivalent <bcp14>MUST</bcp14> adopt
one of these three alternatives:</t> one of these three alternatives:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Partition the nonce namespace between cluster members and use mono
<t>Partition the nonce namespace between cluster members and use monotonic tonic
counters on each member, e.g. by setting the nonce to the concatenation counters on each member, e.g., by setting the nonce to the concatenation
of the cluster member ID and an incremental counter.</t> of the cluster member ID and an incremental counter.</li>
<t>Generate random nonces but avoid the so-called birthday bound, i.e. <li>Generate random nonces but avoid the so-called birthday bound, i.e
.,
never generate more than the maximum allowed number of encrypted never generate more than the maximum allowed number of encrypted
tickets (2**64 for AES-128-GCM) for the same ticket tickets (2**64 for AES-128-GCM) for the same ticket
pinning protection Key.</t> pinning protection key.</li>
<t>An alternative design which has been attributed to Karthik Bhargavan is <li>An alternative design that has been attributed to Karthik Bhargava
as follows. Start with a 128-bit master key “K_master” and then for n is
as follows. Start with a 128-bit master key K_master and then for
each encryption, generate a 256-bit random nonce and compute: K = each encryption, generate a 256-bit random nonce and compute: K =
HKDF(K_master, Nonce || “key”), then N = HKDF(K_master, Nonce || HKDF(K_master, Nonce || "key"), then N = HKDF(K_master, Nonce ||
“nonce”). Use these values to encrypt the ticket, AES-GCM(K, N, "nonce"). Use these values to encrypt the ticket, AES-GCM(K, N,
data). This nonce should then be stored and transmitted with the data). This nonce should then be stored and transmitted with the
ticket.</t> ticket.</li>
</list></t> </ul>
</section>
</section> </section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>The IANA has allocated a TicketPinning extension value in the "TLS
<t>IANA is requested to allocate a TicketPinning extension value in the TLS ExtensionType Values" registry.</t>
ExtensionType Registry.</t> <t><xref target="RFC8447" format="default"/> defines the procedure, requir
ements, and the necessary
<t><xref target="RFC8447"/> defines the procedure and requirements and the neces information for the IANA to update the "TLS ExtensionType Values"
sary registry <xref target="TLS-EXT" format="default"/>. The registration procedure
information for the IANA to update the “TLS ExtensionType Values” is "Specification Required" <xref target="RFC8126"/>.</t>
registry <xref target="TLS-EXT"/>.</t>
<t>According to <xref target="RFC8447"/> the update of the “TLS ExtensionType Va
lues”
registry is “Specification Required” <xref target="RFC8126"/> which is fulfilled
by
the current document, when it is published as an RFC.</t>
<t>The TicketPinning Extension is not limited to Private use and as such
the TicketPinning Extension Value is expected to have its first byte in
the range 0-254.</t>
<t>The TicketPinning Extension Name is expected to be ticket_pinning.</t>
<t>The TicketPinning Extension Recommended value should be set to “No” with
the publication of the current document as “Experimental”.</t>
<t>The TicketPinning Extension TLS.13 column should be set to CH, EE to
indicate that the TicketPinning Extension is present in ClientHello and
EncryptedExtensions messages.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The original idea behind this proposal was published in <xref target="Oreo"/>
by
Moti Yung, Benny Pinkas and Omer Berkman. The current protocol is
but a distant relative of the original Oreo protocol, and any errors
are the responsibility of the authors of this document alone.</t>
<t>We would like to thank Adrian Farrel, Dave Garrett,
Daniel Kahn Gillmor,
Alexey Melnikov,
Yoav Nir,
Eric Rescorla, Benjamin Kaduk and Rich Salz for their comments on this document.
Special thanks to Craig Francis for contributing the HPKP deployment
script, and to Ralph Holz for several fruitful discussions.</t>
</section>
<t>The TicketPinning extension is registered as follows. (The extension is
not
limited to Private Use, and as such has its first byte in the range
0-254.)</t>
<dl>
<dt>Value:</dt><dd>32</dd>
<dt>Name:</dt><dd>ticket_pinning</dd>
<dt>Recommended:</dt><dd>No</dd>
<dt>TLS 1.3:</dt><dd>CH, EE (to indicate that the extension is present
in ClientHello and EncryptedExtensions messages)</dd>
</dl>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.perrin-tls-tack" to="TLS-TACK"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8447.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
</references>
<references>
<references title='Normative References'> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> ence.RFC.2104.xml"/>
<front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<title>Key words for use in RFCs to Indicate Requirement Levels</title> ence.RFC.5077.xml"/>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
author> ence.RFC.5246.xml"/>
<date year='1997' month='March' /> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<abstract><t>In many standards track documents several words are used to signify ence.RFC.6454.xml"/>
the requirements in the specification. These words are often capitalized. This <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
document defines these words as they should be interpreted in IETF documents. ence.RFC.6962.xml"/>
This document specifies an Internet Best Current Practices for the Internet Comm <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
unity, and requests discussion and suggestions for improvements.</t></abstract> ence.RFC.7258.xml"/>
</front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<seriesInfo name='BCP' value='14'/> ence.RFC.7469.xml"/>
<seriesInfo name='RFC' value='2119'/> <xi:include
<seriesInfo name='DOI' value='10.17487/RFC2119'/> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
</reference> 7507.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<reference anchor="RFC8126" target='https://www.rfc-editor.org/info/rfc8126'> ence.RFC.8555.xml"/>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></au
thor>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></au
thor>
<date year='2017' month='June' />
<abstract><t>Many protocols make use of points of extensibility that use constan
ts to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their alloc
ations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma
ke assignments in a given registry prudently, guidance describing the conditions
under which new values should be assigned, as well as when and how modification
s to existing values can be made, is needed. This document defines a framework
for the documentation of these guidelines by specification authors, in order to
assure that the provided guidance for the IANA Considerations is clear and addre
sses the various issues that are likely in the operation of a registry.</t><t>Th
is is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>
<reference anchor="RFC8446" target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
</author>
<date year='2018' month='August' />
<abstract><t>This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate over the
Internet in a way that is designed to prevent eavesdropping, tampering, and mess
age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs
5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2
implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>
<reference anchor="RFC8447" target='https://www.rfc-editor.org/info/rfc8447'>
<front>
<title>IANA Registry Updates for TLS and DTLS</title>
<author initials='J.' surname='Salowey' fullname='J. Salowey'><organization /></
author>
<author initials='S.' surname='Turner' fullname='S. Turner'><organization /></au
thor>
<date year='2018' month='August' />
<abstract><t>This document describes a number of changes to TLS and DTLS IANA re
gistries that range from adding notes to the registry all the way to changing th
e registration policy. These changes were mostly motivated by WG review of the
TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development p
rocess.</t><t>This document updates the following RFCs: 3749, 5077, 4680, 5246,
5705, 5878, 6520, and 7301.</t></abstract>
</front>
<seriesInfo name='RFC' value='8447'/>
<seriesInfo name='DOI' value='10.17487/RFC8447'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="RFC2104" target='https://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 authenticatio
n using cryptographic hash functions. HMAC can be used with any iterative crypto
graphic 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 underlyin
g hash function. This memo provides information for the Internet community. Th
is 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="RFC5077" target='https://www.rfc-editor.org/info/rfc5077'>
<front>
<title>Transport Layer Security (TLS) Session Resumption without Server-Side Sta
te</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 /></au
thor>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organizatio
n /></author>
<date year='2008' month='January' />
<abstract><t>This document describes a mechanism that enables the Transport Laye
r 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 obtai
ned ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5077'/>
<seriesInfo name='DOI' value='10.17487/RFC5077'/>
</reference>
<reference anchor="RFC5246" target='https://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></au
thor>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
</author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security
(TLS) protocol. The TLS protocol provides communications security over the Int
ernet. The protocol allows client/server applications to communicate in a way t
hat is designed to prevent eavesdropping, tampering, or message forgery. [STAND
ARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>
<reference anchor="RFC6454" target='https://www.rfc-editor.org/info/rfc6454'>
<front>
<title>The Web Origin Concept</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></auth
or>
<date year='2011' month='December' />
<abstract><t>This document defines the concept of an &quot;origin&quot;, which i
s often used as the scope of authority or privilege by user agents. Typically,
user agents isolate content retrieved from different origins to prevent maliciou
s web site operators from interfering with the operation of benign web sites. I
n 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 o
rigin into a string. It also defines an HTTP header field, named &quot;Origin&q
uot;, that indicates which origins are associated with an HTTP request. [STAND
ARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6454'/>
<seriesInfo name='DOI' value='10.17487/RFC6454'/>
</reference>
<reference anchor="RFC6962" target='https://www.rfc-editor.org/info/rfc6962'>
<front>
<title>Certificate Transparency</title>
<author initials='B.' surname='Laurie' fullname='B. Laurie'><organization /></au
thor>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></
author>
<author initials='E.' surname='Kasper' fullname='E. Kasper'><organization /></au
thor>
<date year='2013' month='June' />
<abstract><t>This document describes an experimental protocol for publicly loggi
ng the existence of Transport Layer Security (TLS) certificates as they are issu
ed or observed, in a manner that allows anyone to audit certificate authority (C
A) activity and notice the issuance of suspect certificates as well as to audit
the certificate logs themselves. The intent is that eventually clients would re
fuse 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='https://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'><organizatio
n /></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='https://www.rfc-editor.org/info/rfc7469'>
<front>
<title>Public Key Pinning Extension for HTTP</title>
<author initials='C.' surname='Evans' fullname='C. Evans'><organization /></auth
or>
<author initials='C.' surname='Palmer' fullname='C. Palmer'><organization /></au
thor>
<author initials='R.' surname='Sleevi' fullname='R. Sleevi'><organization /></au
thor>
<date year='2015' month='April' />
<abstract><t>This document defines a new HTTP header that allows web host operat
ors to instruct user agents to remember (&quot;pin&quot;) the hosts' cryptograph
ic identities over a period of time. During that time, user agents (UAs) will r
equire that the host presents a certificate chain including at least one Subject
Public Key Info structure whose fingerprint matches one of the pinned fingerpri
nts for that host. By effectively reducing the number of trusted authorities wh
o 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 Aut
horities.</t></abstract>
</front>
<seriesInfo name='RFC' value='7469'/>
<seriesInfo name='DOI' value='10.17487/RFC7469'/>
</reference>
<reference anchor="RFC7507" target='https://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 pr
events protocol downgrade attacks on the Transport Layer Security (TLS) and Data
gram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 434
7, 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="RFC7942" target='https://www.rfc-editor.org/info/rfc7942'>
<front>
<title>Improving Awareness of Running Code: The Implementation Status Section</t
itle>
<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></
author>
<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></au
thor>
<date year='2016' month='July' />
<abstract><t>This document describes a simple process that allows authors of Int
ernet-Drafts to record the status of known implementations by including an Imple
mentation Status section. This will allow reviewers and working groups to assig
n due consideration to documents that have the benefit of running code, which ma
y serve as evidence of valuable experimentation and feedback that have made the
implemented protocols more mature.</t><t>This process is not mandatory. Authors
of Internet-Drafts are encouraged to consider using the process for their docum
ents, and working groups are invited to think about applying the process to all
of their protocol specifications. This document obsoletes RFC 6982, advancing i
t to a Best Current Practice.</t></abstract>
</front>
<seriesInfo name='BCP' value='205'/>
<seriesInfo name='RFC' value='7942'/>
<seriesInfo name='DOI' value='10.17487/RFC7942'/>
</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 ho
st will require the server to present a signature from the signing key over the
TLS server's public key.</t></abstract>
</front> <!-- draft-ietf-draft-perrin-tls-tack-02 expired -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.draft-perrin-tls-tack-02.xml"/>
<seriesInfo name='Internet-Draft' value='draft-perrin-tls-tack-02' /> <reference anchor="Oreo">
<format type='TXT' <front>
target='http://www.ietf.org/internet-drafts/draft-perrin-tls-tack-02.txt <title>Firm Grip Handshakes: A Tool for Bidirectional Vouching</titl
' /> e>
</reference> <author initials="O." surname="Berkman">
<organization/>
</author>
<author initials="B." surname="Pinkas">
<organization/>
</author>
<author initials="M." surname="Yung">
<organization/>
</author>
<date year="2012"/>
</front>
<seriesInfo name="Cryptology and Network Security" value="pp. 142-15
7"/>
</reference>
<reference anchor="Oreo" > <reference anchor="Netcraft"
<front> target="https://news.netcraft.com/archives/2016/03/30/http-pu
<title>Firm Grip Handshakes: A Tool for Bidirectional Vouching</title> blic-key-pinning-youre-doing-it-wrong.html">
<author initials="O." surname="Berkman"> <front>
<organization></organization> <title>HTTP Public Key Pinning: You're doing it wrong!</title>
</author> <author initials="P." surname="Mutton" fullname="Paul Mutton">
<author initials="B." surname="Pinkas"> <organization/>
<organization></organization> </author>
</author> <date year="2016" month="March"/>
<author initials="M." surname="Yung"> </front>
<organization></organization> </reference>
</author>
<date year="2012"/>
</front>
<seriesInfo name="Cryptology and Network Security, pp. 142-157" value=""/>
</reference>
<reference anchor="Netcraft" target="http://news.netcraft.com/archives/2016/03/3
0/http-public-key-pinning-youre-doing-it-wrong.html">
<front>
<title>HTTP Public Key Pinning: You're doing it wrong!</title>
<author initials="P." surname="Mutton" fullname="Paul Mutton">
<organization></organization>
</author>
<date year="2016" month="March"/>
</front>
</reference>
<reference anchor="TLS-EXT" target="https://www.iana.org/assignments/tls-extensi
ontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1">
<front>
<title>TLS Extension Type Value</title>
<author initials="." surname="IANA">
<organization></organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="TLS-EXT"
target="https://www.iana.org/assignments/tls-extensiontype-va
lues/">
<front>
<title>TLS Extension Type Value</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
</references> </references>
<section anchor="previous-work" numbered="true" toc="default">
<section anchor="previous-work" title="Previous Work"> <name>Previous Work</name>
<t>The global PKI system relies on the trust of a CA issuing certificates.
<t>The global PKI system relies on the trust of a CA issuing certificates.
As a result, a corrupted trusted CA may issue a certificate for any As a result, a corrupted trusted CA may issue a certificate for any
organization without the organization’s approval (a misissued or “fake” organization without the organization's approval (a misissued or "fake"
certificate), and use the certificate to impersonate the organization. certificate), and use the certificate to impersonate the organization.
There are many attempts to resolve these weaknesses, including There are many attempts to resolve these weaknesses, including the
Certificate Transparency (CT) <xref target="RFC6962"/>, HTTP Public Key Pinning Certificate Transparency (CT) protocol <xref target="RFC6962" format="default"/>
(HPKP) <xref target="RFC7469"/>, and TACK <xref target="I-D.perrin-tls-tack"/>.< ,
/t> HTTP Public Key Pinning (HPKP) <xref target="RFC7469" format="default"/>,
and Trust Assertions for Certificate Keys (TACK) <xref target="I-D.perrin-tls-ta
<t>CT requires ck" format="default"/>.</t>
<t>CT requires
cooperation of a large portion of the hundreds of extant certificate cooperation of a large portion of the hundreds of extant certificate
authorities (CAs) before it can be used “for real”, in enforcing mode. authorities (CAs) before it can be used "for real", in enforcing mode.
It is noted that the relevant industry forum (CA/Browser Forum) is It is noted that the relevant industry forum (CA/Browser Forum) is
indeed pushing for such extensive adoption. However the public nature of CT indeed pushing for such extensive adoption. However the public nature of CT
often makes it inappropriate for enterprise use, because many organizations often makes it inappropriate for enterprise use because many organizations
are not willing to expose their internal infrastructure publicly.</t> are not willing to expose their internal infrastructure publicly.</t>
<t>TACK has some similarities
<t>TACK has some similarities to the current proposal, but work on it seems to have stalled. <xref target="ta
to the current proposal, but work on it seems to have stalled. <xref target="ta ck" format="default"/>
ck"/>
compares our proposal to TACK.</t> compares our proposal to TACK.</t>
<t>HPKP is an IETF standard, but so far has proven hard to deploy. HPKP
<t>HPKP is an IETF standard, but so far has proven hard to deploy. HPKP
pins (fixes) a public key, one of the public keys listed in the pins (fixes) a public key, one of the public keys listed in the
certificate chain. As a result, HPKP needs to be coordinated with the certificate chain. As a result, HPKP needs to be coordinated with the
certificate management process. Certificate management impacts HPKP and certificate management process. Certificate management impacts HPKP and
thus increases the probability of HPKP failures. This risk is made even thus increases the probability of HPKP failures. This risk is made even
higher given the fact that, even though work has been done at the ACME higher given the fact that, even though work has been done in the
WG to automate certificate management, in many or even most cases, Automated Certificate Management Environment (ACME)
working group to automate certificate management, in many or even most cases,
certificates are still managed manually. As a result, HPKP cannot be certificates are still managed manually. As a result, HPKP cannot be
completely automated resulting in error-prone manual configuration. Such completely automated, resulting in error-prone manual configuration. Such
errors could prevent the web server from being accessed by some clients. errors could prevent the web server from being accessed by some clients.
In addition, HPKP uses a HTTP header which makes this solution HTTPS In addition, HPKP uses an HTTP header, which makes this solution HTTPS
specific and not generic to TLS. On the other hand, the current document specific and not generic to TLS. On the other hand, the current document
provides a solution that is independent of the server’s certificate provides a solution that is independent of the server's certificate
management and that can be entirely and easily automated. <xref target="hpkp"/> management, and that can be entirely and easily automated. <xref target="hpkp" f
ormat="default"/>
compares HPKP to the current document in more detail.</t> compares HPKP to the current document in more detail.</t>
<t>The ticket pinning proposal augments these mechanisms with a much easie
<t>The ticket pinning proposal augments these mechanisms with a much easier r
to implement and deploy solution for server identity pinning, by reusing to implement and deploy solution for server identity pinning, by reusing
some of the ideas behind TLS session resumption.</t> some of the ideas behind TLS session resumption.</t>
<t>This section compares ticket pinning to two earlier proposals, HPKP and
<t>This section compares ticket pinning to two earlier proposals, HPKP and TACK. TACK.</t>
</t> <section anchor="hpkp" numbered="true" toc="default">
<name>Comparison: HPKP</name>
<section anchor="hpkp" title="Comparison: HPKP"> <t>The current IETF standard for pinning the identity of web servers is
HPKP <xref target="RFC7469" format="default"/>.</t>
<t>The current IETF standard for pinning the identity of web servers is the <t>The main differences between HPKP and the current document are the
Public Key Pinning Extension for HTTP, or HPKP <xref target="RFC7469"/>.</t>
<t>The main differences between HPKP and the current document are the
following:</t> following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>HPKP limits its scope to HTTPS, while the current document conside
<t>HPKP limits its scope to HTTPS, while the current document considers all rs all
application above TLS.</t> application above TLS.</li>
<t>HPKP pins the public key of the server (or another public key along the <li>HPKP pins the public key of the server (or another public key alon
certificate chain) and as such is highly dependent on the management of g the
certificate chain), and as such, is highly dependent on the management of
certificates. Such dependency increases the potential error surface, certificates. Such dependency increases the potential error surface,
especially as certificate management is not yet largely automated. The especially as certificate management is not yet largely automated. The
current proposal, on the other hand, is independent of certificate current proposal, on the other hand, is independent of certificate
management.</t> management.</li>
<t>HPKP pins public keys which are public and used for the standard TLS <li>HPKP pins public keys that are public and used for the standard TL
S
authentication. Identity pinning relies on the ownership of the pinning authentication. Identity pinning relies on the ownership of the pinning
key which is not disclosed to the public and not involved in the key, which is not disclosed to the public and not involved in the
standard TLS authentication. As a result, identity pinning is a standard TLS authentication. As a result, identity pinning is a
completely independent second factor authentication mechanism.</t> completely independent, second-factor authentication mechanism.</li>
<t>HPKP relies on a backup key to recover the misissuance of a key. We <li>HPKP relies on a backup key to recover the misissuance of a key.
We
believe such backup mechanisms add excessive complexity and cost. believe such backup mechanisms add excessive complexity and cost.
Reliability of the current mechanism is primarily based on its being Reliability of the current mechanism is primarily based on its being
highly automated.</t> highly automated.</li>
<t>HPKP relies on the client to report errors to the report-uri. The <li>HPKP relies on the client to report errors to the report-uri. The
current document does not need any out-of band mechanism, and the server is current document does not need any out-of-band mechanism, and the server is
informed automatically. This provides an easier and more reliable health informed automatically. This provides an easier and more reliable health
monitoring.</t> monitoring.</li>
</list></t> </ul>
<t>On the other hand, HPKP shares the following aspects with identity pi
<t>On the other hand, HPKP shares the following aspects with identity pinning:</ nning:</t>
t> <ul spacing="normal">
<li>Both mechanisms provide hard failure. With HPKP, only the client
<t><list style="symbols"> is
<t>Both mechanisms provide hard failure. With HPKP only the client is
aware of the failure, while with the current proposal both client and aware of the failure, while with the current proposal both client and
server are informed of the failure. This provides room for further server are informed of the failure. This provides room for further
mechanisms to automatically recover such failures.</t> mechanisms to automatically recover from such failures.</li>
<t>Both mechanisms are subject to a server compromise in which users are <li>Both mechanisms are subject to a server compromise in which users
provided with an invalid ticket (e.g. a random one) or HTTP Header, with are
a very long lifetime. For identity pinning, this lifetime SHOULD NOT be provided with an invalid ticket (e.g., a random one) or HTTP header with
a very long lifetime. For identity pinning, this lifetime <bcp14>SHOULD NOT</bcp
14> be
longer than 31 days. In both cases, clients will not be able to longer than 31 days. In both cases, clients will not be able to
reconnect the server during this lifetime. With the current proposal, reconnect the server during this lifetime. With the current proposal,
an attacker needs to compromise the TLS layer, while with HPKP, the an attacker needs to compromise the TLS layer, while with HPKP, the
attacker needs to compromise the HTTP server. Arguably, the TLS-level attacker needs to compromise the HTTP server. Arguably, the TLS-level
compromise is typically more difficult for the attacker.</t> compromise is typically more difficult for the attacker.</li>
</list></t> </ul>
<t>Unfortunately HPKP has not seen wide deployment yet. As of March 201
<t>Unfortunately HPKP has not seen wide deployment yet. As of March 2016, 6,
the number of servers using HPKP was less than 3000 <xref target="Netcraft"/>. the number of servers using HPKP was less than 3000 <xref target="Netcraft" form
This at="default"/>. This
may simply be due to inertia, but we believe the main reason is the may simply be due to inertia, but we believe the main reason is the
interactions between HPKP and manual certificate management which is interactions between HPKP and manual certificate management that is
needed to implement HPKP for enterprise servers. The penalty for making 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 having mistakes (e.g., being too early or too late to deploy new pins) is that
the server become unusable for some of the clients.</t> the server becomes unusable for some of the clients.</t>
<t>To demonstrate this point, we present a list of the steps involved in
deploying HPKP on a security-sensitive web server.</t>
<ol spacing="normal" type="1">
<li>
<t>Generate two public/private key pairs on a computer that is not t
he
live server. The second one is the "backup1" key pair. </t>
<sourcecode type="bash">
openssl genrsa -out "example.com.key" 2048;
<t>To demonstrate this point, we present a list of the steps involved in openssl genrsa -out "example.com.backup1.key" 2048;
deploying HPKP on a security-sensitive Web server.</t> </sourcecode>
</li>
<t><list style="numbers"> <li>
<t>Generate two public/private key-pairs on a computer that is not the <t>Generate hashes for both of the public keys. These will be used i
Live server. The second one is the “backup1” key-pair. <vspace blankLines='1'/> n
<spanx style="verb">openssl genrsa -out "example.com.key" 2048;</spanx> <vspace the HPKP header: </t>
blankLines='1'/> <sourcecode type="bash">
<spanx style="verb">openssl genrsa -out "example.com.backup1.key" 2048;</spanx>< openssl rsa -in "example.com.key" -outform der -pubout | \
/t> openssl dgst -sha256 -binary | openssl enc -base64
<t>Generate hashes for both of the public keys. These will be used in
the HPKP header: <vspace blankLines='1'/> openssl rsa -in "example.com.backup1.key" -outform der \
<spanx style="verb">openssl rsa -in "example.com.key" -outform der -pubout | ope -pubout | openssl dgst -sha256 -binary | openssl enc -base64
nssl dgst -sha256 -binary | openssl enc -base64</spanx> <vspace blankLines='1'/ </sourcecode>
> </li>
<spanx style="verb">openssl rsa -in "example.com.backup1.key" -outform der -pubo <li>
ut | openssl dgst -sha256 -binary | openssl enc -base64</spanx></t> <t>Generate a single CSR (Certificate Signing Request) for the first
<t>Generate a single CSR (Certificate Signing Request) for the first key pair, where you include the domain name in the CN (Common Name)
key-pair, where you include the domain name in the CN (Common Name) field: </t>
field: <vspace blankLines='1'/> <sourcecode type="bash">
<spanx style="verb">openssl req -new -subj "/C=GB/ST=Area/L=Town/O=Company/CN=ex openssl req -new -subj "/C=GB/ST=Area/L=Town/O=Org/ \
ample.com" CN=example.com" -key "example.com.key" -out "example.com.csr";
-key "example.com.key" -out "example.com.csr";</spanx></t> </sourcecode>
<t>Send this CSR to the CA (Certificate Authority), and go though the </li>
dance to prove you own the domain. The CA will give you back a single <li>Send this CSR to the CA and go though the
certificate that will typically expire within a year or two.</t> dance to prove you own the domain. The CA will give you a single
<t>On the Live server, upload and setup the first key-pair (and its certificate that will typically expire within a year or two.</li>
certificate). At this point you can add the “Public-Key-Pins” header, <li>
using the two hashes you created in step 2. <vspace blankLines='1'/> <t>On the live server, upload and set up the first key pair and its
Note that only the first key-pair has been uploaded to the server so far.</t> certificate. At this point, you can add the "Public-Key-Pins" header,
<t>Store the second (backup1) key-pair somewhere safe, probably using the two hashes you created in step 2. </t>
somewhere encrypted like a password manager. It won’t expire, as it’s <t>
just a key-pair, it just needs to be ready for when you need to get your Note that only the first key pair has been uploaded to the server so far.</t>
next certificate.</t> </li>
<t>Time passes… probably just under a year (if waiting for a <li>Store the second (backup1) key pair somewhere safe, probably
somewhere encrypted like a password manager. It won't expire, as it's
just a key pair; it just needs to be ready for when you need to get your
next certificate.</li>
<li>Time passes -- probably just under a year (if waiting for a
certificate to expire), or maybe sooner if you find that your server has certificate to expire), or maybe sooner if you find that your server has
been compromised and you need to replace the key-pair and certificate.</t> been compromised, and you need to replace the key pair and certificate.</li>
<t>Create a new CSR (Certificate Signing Request) using the “backup1” <li>Create a new CSR using the "backup1"
key-pair, and get a new certificate from your CA.</t> key pair, and get a new certificate from your CA.</li>
<t>Generate a new backup key-pair (backup2), get its hash, and store it <li>Generate a new backup key pair (backup2), get its hash, and store
in a safe place (again, not on the Live server).</t> it
<t>Replace your old certificate and old key-pair, and update the in a safe place (again, not on the live server).</li>
“Public-Key-Pins” header to remove the old hash, and add the new <li>Replace your old certificate and old key pair, update the
“backup2” key-pair.</t> "Public-Key-Pins" header to remove the old hash, and add the new
</list></t> "backup2" key pair.</li>
</ol>
<t>Note that in the above steps, both the certificate issuance as well as <t>Note that in the above steps, both the certificate issuance as well a s
the storage of the backup key pair involve manual steps. Even with an the storage of the backup key pair involve manual steps. Even with an
automated CA that runs the ACME protocol, key backup would be a automated CA that runs the ACME protocol <xref target="RFC8555"/>, key backup wo uld be a
challenge to automate.</t> challenge to automate.</t>
</section>
</section> <section anchor="tack" numbered="true" toc="default">
<section anchor="tack" title="Comparison: TACK"> <name>Comparison: TACK</name>
<t>Compared with HPKP, TACK <xref target="I-D.perrin-tls-tack" format="d
<t>Compared with HPKP, TACK <xref target="I-D.perrin-tls-tack"/> is a lot more s efault"/> is more similar
imilar
to the current document. It can even be argued that this document is a to the current document. It can even be argued that this document is a
symmetric-cryptography variant of TACK. That said, there are still a symmetric-cryptography variant of TACK. That said, there are still a
few significant differences:</t> few significant differences:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Probably the most important difference is that with TACK, validati
<t>Probably the most important difference is that with TACK, validation of on of
the server certificate is no longer required, and in fact TACK specifies the server certificate is no longer required, and in fact TACK specifies
it as a “MAY” requirement (Sec. 5.3). With ticket pinning, certificate it as a "<bcp14>MAY</bcp14>" requirement (<xref target="I-D.perrin-tls-tack" sec
validation by the client remains a MUST requirement, and the ticket acts tionFormat="comma" section="5.3" format="default"/>). With ticket pinning, cert
ificate
validation by the client remains a <bcp14>MUST</bcp14> requirement, and the tick
et acts
only as a second factor. If the pinning secret is compromised, the only as a second factor. If the pinning secret is compromised, the
server’s security is not immediately at risk.</t> server's security is not immediately at risk.</li>
<t>Both TACK and the current document are mostly orthogonal to the server <li>Both TACK and the current document are mostly orthogonal to the se
rver
certificate as far as their life cycle, and so both can be deployed with certificate as far as their life cycle, and so both can be deployed with
no manual steps.</t> no manual steps.</li>
<t>TACK uses ECDSA to sign the server’s public key. This allows <li>TACK uses Elliptic Curve Digital Signature Algorithm
(ECDSA) to sign the server's public key. This allows
cooperating clients to share server assertions between themselves. This cooperating clients to share server assertions between themselves. This
is an optional TACK feature, and one that cannot be done with pinning is an optional TACK feature, and one that cannot be done with pinning
tickets.</t> tickets.</li>
<t>TACK allows multiple servers to share its public keys. Such sharing is <li>TACK allows multiple servers to share its public keys. Such sharin
disallowed by the current document.</t> g is
<t>TACK does not allow the server to track a particular client, and so disallowed by the current document.</li>
has better privacy properties than the current document.</t> <li>TACK does not allow the server to track a particular client, and s
<t>TACK has an interesting way to determine the pin’s lifetime, setting o
has better privacy properties than the current document.</li>
<li>TACK has an interesting way to determine the pin's lifetime, setti
ng
it to the time period since the pin was first observed, with a hard it to the time period since the pin was first observed, with a hard
upper bound of 30 days. The current document makes the lifetime explicit, upper bound of 30 days. The current document makes the lifetime explicit,
which may be more flexible to deploy. For example, Web sites which are which may be more flexible to deploy. For example, web sites that are
only visited rarely by users may opt for a longer period than other only visited rarely by users may opt for a longer period than other
sites that expect users to visit on a daily basis.</t> sites that expect users to visit on a daily basis.</li>
</list></t> </ul>
</section>
</section> </section>
</section>
<section anchor="document-history" title="Document History">
<section anchor="draft-sheffer-tls-pinning-ticket-12" title="draft-sheffer-tls-p
inning-ticket-12">
<t><list style="symbols">
<t>IETF-Conflict Review comments.</t>
<t>IANA: removed request for a specific extension value.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-11" title="draft-sheffer-tls-p
inning-ticket-11">
<t><list style="symbols">
<t>Comments by Ben Kaduk. Specifically, changed the derivation of the pinning
proof
to make it more in line with the TLS 1.3 key schedule.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-10" title="draft-sheffer-tls-p
inning-ticket-10">
<t><list style="symbols">
<t>ISE comments by Adrian Farrel, the ISE.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-09" title="draft-sheffer-tls-p
inning-ticket-09">
<t><list style="symbols">
<t>ISE comments by Yoav Nir.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-08" title="draft-sheffer-tls-p
inning-ticket-08">
<t><list style="symbols">
<t>ISE comments by Rich Salz.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-07" title="draft-sheffer-tls-p
inning-ticket-07">
<t><list style="symbols">
<t>Refer to published RFCs.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-06" title="draft-sheffer-tls-p
inning-ticket-06">
<t><list style="symbols">
<t>IANA Considerations in preparation for Experimental publication.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-05" title="draft-sheffer-tls-p
inning-ticket-05">
<t><list style="symbols">
<t>Multiple comments from Eric Rescorla.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-04" title="draft-sheffer-tls-p
inning-ticket-04">
<t><list style="symbols">
<t>Editorial changes.</t>
<t>Two-phase rotation of protection key.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-03" title="draft-sheffer-tls-p
inning-ticket-03">
<t><list style="symbols">
<t>Deleted redundant length fields in the extension’s formal definition.</t>
<t>Modified cryptographic operations to align with the current state of TLS 1.
3.</t>
<t>Numerous textual improvements.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-02" title="draft-sheffer-tls-p
inning-ticket-02">
<t><list style="symbols">
<t>Added an Implementation Status section.</t>
<t>Added lengths into the extension structure.</t>
<t>Changed the computation of the pinning proof to be more robust.</t>
<t>Clarified requirements on the length of the pinning_secret.</t>
<t>Revamped the HPKP section to be more in line with current practices, and ad
ded recent
statistics on HPKP deployment.</t>
</list></t>
</section>
<section anchor="draft-sheffer-tls-pinning-ticket-01" title="draft-sheffer-tls-p
inning-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 secti
on.</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-p
inning-ticket-00">
<t>Initial version.</t>
</section>
</section>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The original idea behind this proposal was published in <xref target="O
reo" format="default"/> by
Moti Yung, Benny Pinkas, and Omer Berkman. The current protocol is
but a distant relative of the original Oreo protocol, and any errors
are the responsibility of the authors of this document alone.</t>
<t>We would like to thank Adrian Farrel, Dave Garrett,
Daniel Kahn Gillmor,
Alexey Melnikov,
Yoav Nir,
Eric Rescorla, Benjamin Kaduk, and Rich Salz for their comments on this document
.
Special thanks to Craig Francis for contributing the HPKP deployment
script, and to Ralph Holz for several fruitful discussions.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAMyOE10AA8V963IbV3bu//0UHeiHSQ8ASZQs25o4FYqSLJWtyxHpcVxx
jtIAGkQPG91Id4MURuN3Oc9ynuysb132pQFKmlSqjmoSE0D3vq69rt9aezKZ
uL7sq+JxdvHzeXZetNdFm71cFDV9u8velnVd1pfZTdmvsotyflX0nctns7a4
fux/tO8XzbzO19TSos2X/aRbFctl0U76qpts5NFJz49O7p+4ed4Xl027e5wV
HzZuu1nQ5+6xa2ZdUxX8pys37eOsb7ddf3Lv3vf3TlzeFvnj7MeiLtq8cjdN
e3XZNtvNY3dV7OjT4nH2su6LtqYenmIIznV9Xi/e51VT07B2Rec25WOXZe1y
Xiy6flfpt1nWN/Poz7LGAtgXXdP2bbHs/OfdOvnYt+XcPzxv1mt61/9a1lVZ
h26KD/2kKjtand161lT02KT5+k/O5dt+1bQY24T+D6/RT79Ns3NZRP5OFve3
vG3q5Pumvczr8m95XzY1L8G27PmHYp2X1eNstMMry2lZ9Mt/vcR3UxrlKO3r
6TR7VV7m26qP+npK7RZV8kPa2TOaetc1ddLdgt+aruWtfy30GenU1U27prev
C0z23fOzk/v3v9c/v7t/8sj+fPgw+vNbUEO93Hvz3kP985t7335rf574Nx89
/MYeePT9oxP989uTb76zPx8+sr6/pSbsz+8f8rMvJ0+nm6Jty5ppuM/nV/j6
TVs0j3nCenBGz8t2nf3YlpvsBZFbt8qviH6z0+yiaaqMRp09KRdlW8yxZnmV
/aXZzld0GkbcCAj/cXZyj84EPgZCwL+JbM6bafakaK/WeZ1+/2SKQ3iVd+nX
r6bZb9v6kr/saPmLDov3ODtrd5u+qZrLXUbjzF4XPc4QHfr5tqXTPs42m2l2
/+HJ5P4339LL9Pscx+jx3sAm2p9QyVva5uzVtu+VDmxZXlxcvM3ebmdVOc9+
KjwzIRJutl+1RbZowD3KPrsh8rz8p3g5XuXtfJU9uDfGwjySVvP2sqBjtur7
zeO7d+vippvWOkKQ1l28QsTR3cUrd+89uPvg3l08PNnwECbEJDwf2jXbtpjw
ACZlP+EBTFf9uqKuiA9Onv3bRbrFYI7PPvRF3dEeZhe7TZH9Ja+2xWAPv7t9
D1+evj7dm0hHM7m5uZmWeZ1P6WjdzbuuvKyZg9wF0RXWZ09dTq7R5e0/TD9g
Cndu+3ly37nJZJLlM2JZ+ZzY46uyK7tuWyyysEbZvGj7clmCQXfZPK+zDXF7
GhALiHlVYmzZsm3WWb7ZtM2mLenJascsDGKDXsS+0gd+o2ORQpyMGiG2neUV
WDSf486t8usimxUFOmk2TUcj6ZtsQQJg3lMLZZd1Zb9lZsMka0PJdSAyjoLY
PA2/w6Fyufba8U6x4JKvCrxPO95n0UipQ3mkzsqqKi7LviQeU7jD6zHNLlZF
V2TrYr4iJtetu4xkUlZQCyQ166Z3N+WC1oJmsKmaHTVOh78q12UvE5NWs5ti
ls3a5oaO5eXUuQvMk4TnFttuC9FBLtLZxXe0an4/O7SD6fCwm03+X1sarUpi
Ea80KPpfdpPvuM+y5r2Qffiqy0oV7lP3lI49vYW51zRx6iZaurELb2FQ1/Re
h2ebtrwswceKeg6GAupJ+p+6l3XWbWddQWNTurH98FuFeY2z7Ya+I85YlJs+
a5Y80LSxvWHQIEpMcVZW0FCYXHgcB152oJl+te34t+aGFAciks2wJ2q2F+6c
0YZPaUMKoy/Qf93cZF2+xL7Om3pebRcFvZ73EYnL5Ggb/fyKheMd4tETm4zO
AraHx2MLGbUxdW/qwsZXrjekeuRKFCBDmjz/Rj0JndDbZcejIcGakYDY0jf0
n/yyYGrKeVpCpi3tB4mhxVTYwLpcLKrCuTtQGdpmseVH3X+HK3z8qCL7jz8S
DuESDpF9hkPwOShBuuCB3Fndu7bsrjKlYVp+aFC2PpdVM6Pp6qnCKEnOtTlx
N5oLMfjs6O1PL4/HTAUdncIqb2kUEMgVeHDWzXNaADmrzHLRcDJRbCH1XUCt
pGnQJv1/PK9gPsJz8/nKYa1oWKSpMmuZERvKO26ByKbS3aeJy/TG/HdbbDHS
rlmDxvhkUevU+6ygaS4SYm6Lbrve8KHg7YWK9ccfU4gwJxq/Pz+yZwXtziJb
EsXRAhulRztODa0LEowLHkrZEcH2ge3zEoBp0FS3fcG7hPEdbkH5ETVTOyMj
7H/xAYz5khj1q4b2v9sUc97LqqIV6MOxbmoiBF4L+tJvh620H+eStj071D6m
3G3nc1qr5ZYad6SAbGC3LKakNxKPZIEAm6QbJ6xm2AW1g7E4Ih2ot5AYvG71
QEjFLII0M+JXwoJ0J1S1IhOMpsTrSlQUUXLmtWcVpBhfscQagX20W5zO2sHu
2RRs/Az2M90GHIIDJHABWy17U2ekENMfv5CkPLp48/yX4yAwx3KUhXm6JT93
mFZ0ZbJZDvKgL+gsJ1MipaZc8LNjN9v2TDF5jfNdVc3NhN7QBeuSrad2l9uW
94dOqEhAjGXvvIWek+N4i+AxaUXTyxeLkqdAj7C1U+2NfW85VRQfkMNDkRlN
BQydfsXS6z44GYaoRWHYRDK/eEl7bbxXX4+eyy7ZtibO53yTIISWmrxZlaSS
l8Ln5r3nOtuaJMGCLGAapBzbTUFiVo4AHc68Tg5emw4LZ2XbkkDpivSgaK/E
JmxMC5nVJm9JnPbowk4jMTm/j3tHdUzszmnvLAhkphBh1jJskKphLiG8KRyD
StmuvEXHvBbp0h3QNjIv8OsCnCFvd8m5o/WiKZE5dl24/anSYoSO0EptClYX
EZiycZJudcq79GfqI1ptU23JqmjmZR6ralW5LEjXLVieFXtfZ2wyYCVUEmJj
V6QIVY2uc1DJ1iUz0sbRuPJEek26cmEjn+hsVMsaK0HlOKxQ6dCAcVFZXNLK
mnlTBaY7b1pY0bpLrAyyLphISGcb3KxJ72YxeMQcTxbIJnjMjG+3EeFgp5wY
Nr1KovGmKK4g69/UcxnNkPt7hm/s1BYEukFB4nfhEg6eHFx/zDzZHSB9atfN
SdKLkBrqA8sSJwDSnuj0w8H3SX0pKjK4OneAVpnOWfXwpBGRxK8gv4TTTIJm
C35D5ve+nRWGSWy+p42oFwfPiRKpMYEBayqVyemRM2LPseGkn9H/rkgjr4rF
ZTFU5P1JirfNfdG2rVgLKgZyN941R1sxv0onJEOSIVKbs13c5LYzniQNfNW5
jmRpdAhtvC+XRvHUGnELbHpCMOBWZns4b3sYxbFQm2/pcIBh4cEa5gw6bzLW
E1mMqwrNZ0hPyZ42yyKXdMyqLLzmen/6YOp+hZ1egXcF8Q3dkYeWVx3Lglk+
v5osy75nzYxeL0jjJkLNqCtRhptlcrbHGUlux/bMTbOtFmajxBZAJrvXiWlU
fMixg2b16ABPVEc9YRMEJ2ev50WTqcIJzZHIiQ8h2Q20NCLRaWzepHUr8+RF
qvwYOt8KB4t630I5gBbF5NzmdQdjLWLVylnXOasE1zQTMsoS+03YGyt8NlxP
GU219ZbbY+e+ZuHg34G6FezPinalEg2f1Wio7hUTBWZMn9hDzRLbsVNO3+V9
VnWL25ge6KdtZtDqaJJKbi/fjrOzSJc5ZW8XFvDo7FStrcgks93LYuYMel3l
cELRFvwtnJwvNNHHzmsjdRH5Jxap/JtaPINOxLK83LYy1aBBONtPvHN26nlC
NPx1blNgHteQopkvl3a89gWwLR2WkrkQrNn6kijWdyt8SEZEQz4KJEPc3cun
cQaTn0fsWGetxIJu4J9axFoJUdeaFEc49aCq1wU1io2fqRWirNlFbgFaXZzV
7SY1d+lt0u5o6iVr9h0m8TxYc8R+Oiwbye5CbElereID9Y0liOzEgSVO+4WT
Qs3yw9ywhY+Ktm3Q5oYtTpIxOyVg/MgqHw18Aif8qpiI0yI7evXy4tUx0TGc
8t3YgQkR/xHHIZ1eTN1oKtL9YqnDfE+1j6Wfo2gs0g5WnhYKXVlPytPZfTBh
9wG1m1c72r5ODiCvdt3ILrDGx9qFM7cImKIuMU/UMw1eBuIZp9i7ghWSoqV9
ZX/9Y1Kzq5KYkWxp4A6sbsEY3eTzgvdF+BxZgtkotjiUTEfZEc11FBG4/UAE
R3Obp7oXKK+hR6/LZtulcptoNfGM/oq3iqUazBh7NlIR7i0qPwix7vn43vjZ
BHPAvkkUgcj5F0y0nelS7MhUCcqCoRSp2Rb5Qv0gzNqJPUWOS+XU2Wlgm9Jn
GLJKeBaITe2VEPel3sTsRXNTsErEE2YvlbItFwwYrz8FOwlaTo0ZQiFiy6XB
jHCyaQ2Kio6wcB/26N25k501NTxyTBcsnYw4TLqLQMII2DORjV79cn4xGst/
s9dv+O93z/7XLy/fPXuKv89fnP78s//D6RPnL9788vPT8Fd48+zNq1fPXj+V
l+nbLPnKjV6d/jaSuYzevL14+eb16c+jvVGyr1Jsy1L8bqKvdW5RdPO2nMnM
npy9/b//5/5DYjr/pFFE4jry4bv73z6kD8RzaumNtRr5SGu8g1uSBC5aIQZA
i7ope1JhxpAE3QqrDm5Fi4pVPZ8TH8YePwv+PXGUppqTDY595Id9gXaAILOD
nOBmOqWYRbEs64LlA/h5yU5JXaDQKE8K1pgS+a4sSHeiPScpEZucxFSJFmu4
FBKuiolnHBvP24VZgJHMp7mQ/lUwyclhWsYKp/cyddsN868y9UtEZvYSCwxR
g7nn5g7hcIzZ58FPTl8VYiDScnu5qXJCHU5hMWdF5DGh6XXoOuH5HIgwb8w4
NSrjWdLQmEJoxYv6sjfbJziY7Ijv+4iORomfbHQ8dQkv8b5YbYcE7LVEu9S2
ZeEHqoP2q+oaK2812aCkfvIuaICWrZe8DWrOgeWcuh/La5kAxPNNIzEvIu4i
pd9MZWa7rb31u6EXDUJBv/U3MIhAipgtLfb+/qbz65SWLhsala5ZRLUlixCx
20FWpNdOstdNPVE6Cl10UR8SvNjWonaB2U3A6tjEuWYhoAP9TCvQZdlBQeu3
rRccsOPlm5ctnWEchzmZXVBVWMjG5pd0N5CApJxIhItI54gkBMc07ZF9hQ6b
T2/ROcyhFGAaz3xcQaMxs+ZD4U0V5n7tdtOL2TGP5oyXQ5gm0eHYQdRcbpnN
TPIbLN6gcU9iiEJeyRb7pscaNAP5wC0ny2+alZFKoIS7QT+E7jTNzg6svdEa
nRX6TAoanwLxr/PkOJbUeSXNdibeZtgxjYSvnrOLl7VuIvAd8XK2q4JHPgtB
nbEPI+Cg3ZSVBow6xIU992YuR+rnOoc9Ih6TQLm0jUu4wurLTpU8agWrOFuX
fcpXiPeyl5CWQs0NNsneWpzjPHDdO/hW3npDq3JdFjcDVswNdRKX4qO8woY8
5h7Fd86+uhy2BRHclvRS76yISDb3XhnekxCZtfW1kxubpXqaxPJgFuNNYpGU
6lzK7k3eXVxEP07dk4J2B7ooVHo++P2BCF4uLfsX2ReASFRO2iaEsxu2bGxy
ZvoZKeDKcaJwHHepQS6N+pUcOfVyRk21EOFyPj6RJTpGHPgyPU4YgCkFqX61
KAHKUnTEgUBahBvwjNOUv6gv16jVJtp+eIsM2r2I1sD+NNlMJlHb7jggQpwN
IYfg6ItAETZIHyhXDROOfSJXJ5bRcCJj9uM3ia8ssbtfkvZCivf4kIXMohZ0
QKxYLO99IIE6xhLXtL5urpfU12Zyxd2CDYCGoj6DtTi3btPf3VB/dy62a72f
0JCKPJI4AB45m6Ot53jnjep3/M55MZ9mJ9MT9B+9r5apJ2i2qQqIpmQceSe4
Da/rEbv074ghV/ZhmfNsTbzTgQk228tVtii7+Va2FYwTFFLRNh8YOKYzK+Y5
Lbrb/3VGCsqS1twJyUdeO++9YA0YnBSTUCSpOu1Et6Sz2hND3cPO5OZN42h1
doNjzE6XaHnYreR1Y/TgItYUpABLoCLvSkQUIYgmTEQg76F1ih3/NYzywfjQ
SaYufXgwZ6azYsUMxtXR2/OfjlWvh/3c0qpf8jqwbhAxWbKak47SMylC00WQ
EnU/IJrIzr4hVoa/JT2EDgSP1c46DYj4ZGSIRjImYXgDQ2yxoGY0So43ZsSy
4BJZH1Q9QLnbbqz+aHCRYaiQF2zbs48ld9G7E1nMA7E7c7jWPInUUKdvXCQd
zIqlhw2kE3lv/dFT2+4OcC8SbT3zYlAjHwFexkL2sCwtDwVgDXg0Y3tkofCq
gqhmd5shY9AMxD/Yv4H5QqAbRMNbHTIamv0GKvnYZKoPP9zSAU2WgYiimGX/
2D/xoCYtvKDT1Si4MfsTNuw9U3/4Cnwgh9/vfV5dwje8Wnfh13SY9m+i//7F
Zf+dfzLOZGj/2L8DE/mSfx+fmfDy8NDuHx7AYE3++IcGEPni3wk9fv0PNXCg
nX+wgfjVvxAbXu4+38A/234PmnoOTzaxOm3g0Khu7y68PexuQF3/fhqFPp7m
ff4fw3H9S3bLgy6Z2dfwWVqMvNmovIPSZLjViccSDJdkDYzAZaGBLFhZ4Jl5
dZPvOvZmTNO+Pv4R9eVfVnXFCwei4j0CJFuEeMsiwEKKzYqUT8BxTdNKXvn3
//gf62mdd2zkWTcvl4G7ehMDD97m5mHfrTmcGC9MOu1Qpxwqt3EkWj1LUQhY
rDPxKUbg12ANTbM3rHm3pDE0qqTqmBEPCiMZ4m5iyaMvwJxBIKPasgSHfjoY
PJu1UKmdWEjALcTx+MPAWGuYZKyCOn85AKa9VeZEujO8Slt2HbhU/86OPn40
xLx888cfx2pE3hLbd9Er8g29Ein4fncOe8v3Xwf4lJpQdMy+LbBn1rgBhGW2
U8U/mjG9RBpOp9KTxWk5syCwwlgsdn94oKoWs3wH7ik2NWpaUDYkBijPCKQE
ZbVZeHiNt2b2Nz/GoOwRgJoiHiGVbOsnUELmZjlAa+wavoVqXLEmPXFhqmKR
HZB9xi5ow34tJJQl7M3ddsC92jYrxIcb1B8aCkv0d0Xf7lS4JYR+PdwlU4Sj
A+jbz+dwL0PB2pLCX7n+H4H1JLAQj9gYwkvAGUITMUJ0f0ikIwF/ie1R5W8P
SC9s6KY0cJx3R+qBjc3WgBrKNCzD4KGDyCALc6dUsVQOtLBA+R55Dl7wNMpn
Uwcnnbt5VRBr3W5k3BjJQg6kRy4gH8OA7r6jiOwRewmuqqCjd/vwJOHgzMIi
Lh6r69h1nBeg1hHLrHa0YNTIEf1/sr4ZREUzI8Ma8xaE1U6WjD2Yx6zv68KC
+R06VhLVzA3RepBnjQ/BvG5ZV9voBN+YwEF1AZ1NK/XpsN9WdPGD5p0Q0Mjy
EEauqRl31MA9AFt7Cy8pPbPWfB8O1xqICxOFNKRjGyCaMlARZAJICpkNLoIs
8AkgHtAaLsknQ+ha/P5e10e4uOkTLuJg3Iawb+/TulXeqfNH5HPHiJrTOFwc
y0MQLgIEHCGLPYb85E3exbEmjez/2Vv2YFuMhyq/BP72VeeOdKWOI9xJ4mHl
9akvOV0uAYJfeNBY2QHesQAAZBcWh0OoPOMFQnhDK3U4FR8248VZwqmxx5Eu
DNIkuhHTfFvws0ah3s/nijyKW4jXZEP6YT7fPebDed2UyfpiSVik4iAvyw/F
wpC7AfQ4zX5dlcBdHBxgti4vV+y+pEX5W9E2WcUhvbETr0QUkBbwpOhr1lgM
5EW0so7bkK8xJ2c2uCi0Ke1ABmjosFANQ7l7EE65DdQ4H8MSFAMWAU587Ncc
q8MjxMHKfKYgEhettc7B+0d+f7/MywpZMXlF9tM4lhRVo241fUTPaiytrtnQ
MkdQs5T3iahoXfEWO0cWTdY1YxVvcBCR2L9tAOLBspHHVMI8GUfIffwoQ3jP
YVJRA1/yPobUKH96dbTeVqAVhN8FoLeRD0OPQOoNlB6j1tudJkHKJBQcS3Xa
C9ImNiQcpiQFQ76I2aFOtSG8xytYDpDAJlF6VQViDpsz1hr7qIZBq8yO1dGU
TY4BJaryuc3Ks1OPRTytgF67XMlGlwpT8PxRI/wW16uAm9mxyMxj8Za72KxK
1BnDasDXTJvPjspbVD7N2vGOLTtO6tUW2h+b23kv+k48hKNsHuDNOCsk+yT4
y2xIw4eozZlYRKxzCj+S0B4pBW2+3rxfNDe1aAX4iEnhG498MCCTiwmHXYui
UBiJddnHO17JcO4ZGCNydA5ZMExU4OkR0DsRX1m+JspwHB3qslXT9ZyJPQ5O
3SOICRraU/rvsaDlabSu3pIC396eoiTpG5jXxdnbuw8fPjABL4GtQhNuBYG8
1PbRjzf39xr5jlqxtNl4QnCzDdzDbVEV17lsZ4wOFRXRvPQJMcCCj6VknAmc
ikr16/rFsjgS63UqLJkoRd+QsGUt+Qv0rQJJX+NNdY0wqzp//fI4YhoSjXDs
ai49w5AgpKijvxaz7A0fTgn6oEbBH39I7DOwLrZPNQhNqhhHTtgc+uXdz4bX
2baIKPN67OVi7eURRjkScKE7c6EjPhjnqAyDFYcwL5HB5iJnSllnRuG0Dpx/
F8LSMIBevo0iCpw3bV4ohhzQIGYlWZdoJqN1HeSpAY+a2IrDc/PyrfPNT7Nz
y/ccA9iLHWd4a9Cw9g+e4gzjPkKQyM6zEFqCC2YAtxkt2Svl+E89DXTuMMaL
o/i88p/x1jD6XtLaxKemXRCpeHhSHEFUZ54kmxpZvBcq+ed70+nJ/77/aHL/
X/58+DkW7/LYd9FTguXNPprHr6PTSp+P3jVVcRy+zpiRKtt9HLsH03Fk+8PJ
7t5t1B1Bc7rfxfgEN2hf9upg+6IQD2dBjdeNoTf3Wv/vDxNSgUVC3MaWhOGD
E2/H/dl+Ezf1H+k+e98JrbQ60R7vq+r7anrWtNnhzBPJgwo+Mt3gATb+IomO
MdVruBhJFpxmdQ9OyfvmwCK64vXj4S2KtUAUJQycBuMVfxuMKHO1JYqwSw+4
vSUJK8TbzI71HJ/tQW+DbaVahIuz+EztQdrel04wuy/Twvxsx5xgbLwn5Kis
NSG2O963F1kRkeiguJgalpYLZ54/ZcXLbS/K9R0txXLZ5hsS7Nkbi5VDTWCX
WvPHgGn4CgwLeCerzgOxkoaa0JDPKHYzr7aLcsD5maKmGAb/XNb2452BuzdN
DvQ5mZHBbwlsnwLba7bGushr455IKbH8AS6PUNabraxhtJ+KhWCR7PidxNkw
M8Ip4vBfFuncHQPA8jiDzpkPILtVqfbu5TqMb1mxvSZNuQPdAfQyBJum66YT
cGnGLKiGhDBE5U6VsmHS7CB14bZNsdhLyDt7yt9MdHeX2zqhJaYMjz1IcADn
SnUj1O05h/NuWxWjw3JmMJAf0l6PfEkkJbJxNkrfGI3TIFIUZJ5Op9FKHyck
q0IykKyGG9wh0FACNxpm3x0MLDifUpRSdooAFcJWz3+nODdJIiXOFPu3Drhg
lfA6U/uTpELiX4mixkPwSnGHhJNb4kKWMPY2+brzHqEQjJFc5764BLh4Mgzv
EXOHlZEymBDPn36ii9CUTg2W7IRzQvbDKY5rrtzSWHDQ3BKHefk0EwBqSWqk
2Dd8SBuap5yv22M4Znaw74dDaF8fIoZXp7/5ccgBTSD2g4z/2C9sFCbGhz6U
JxB9EXfiowMAaE7bt9xWDg7d4obTiDodaKgRgdmBKQqXZG8I6IyPNrvXpodO
wVedqZsaqdDyGEbjkW9Y7JGbwnl/GVxk8nJkzohjsghVPAwKZ8VC4gP7Niw+
uMrw4HKgLx32YLusIsQB+J+mx7QoQUf69kFwuq8GMk0S1YBJRsk+1VHM33DT
gC47XQjsn5yK02enT6NToAmzlqugw4wq7ajdqb+bgsSZXRywAP+FgbFGagYS
W6/Ltt9yYF6g09yt+6wNGlXYuCn07NLIwv7RdgHCB+8CMhH7Yri8GAU7bBtf
gUjKdRg/k2w5ty4vNd9qOFQD4gdvgf1ywy7bq6LYxIFRFCe6hj50yvRomFtN
M4RVnOadwFkyR4+85PoYIrbrHAX1LGd6MC9jSt2unq9oWSTfVIcKvyC73ZoF
o74RqRQdjqudhaCTZ/xYfR0PrErEObHFMXy37DyIcZwJ7nBn5X0Wjeq4HDFu
OWNgf8zqZSnMfzGJskujNNhQlMMcdvEkp8jddJow/ZiFdSyw34fG3qPPH7IX
Pz19Pnn2YUOn6ShgHQfPjb8AGjTaP8GjcfbzMR8HrkRljf8etf77ez0+UURg
sC6G4Strl2CznyDf81OtsgvMXKaDH1FX9DbOoow0nyFnxdISzbXMm4jU2zW8
VHMiIct2zjgdRDh1mnYrdtCtAxXI86LNbzhpyrLcfergjQHgZaiYNofrtC6G
ynYfAvQFpupFILi4HMTvw93VFAGo64i/UD/5ZZHkY1kGI2eoZKhuKlI+VRRm
qCyzgbpSzpETIBsPq64kqcxMKuFNjKf5zOJ8chdZ6t80Y1KvbfHZy+PBVcb3
4LUXsC67UbVTdT0qw9Lcv0h0EZcZyiYOuyWGeQCjB/M4GLaG13BDxMghJU7K
vLRacOGg0uq0XoTaRalZgQb4F0Xzc3hgB6bgPWNDbSXGTnzJNMU8OmwLpcZQ
2SdjMSqQiALHu0xkq764hL0Qpy8jRW/GpvtATw6RYR/y8Cf3ZSy7xDWIJztf
Co+Lvt0y4Vmz5UPj64v5sHoamI1SqRPXtPimhgy3WWrA5ocvtpJkRPeHZtLn
TCXumF8lxv7q9OzI1ue9Dac73NPJKPvTfleH5pD9KXuRd6sjmfB7WQmcxeNj
l2nKP7oW4YhyvaRvWdU1fjVoUsGvUxeXTV8qZIFXP0oR8qYwxPAKLbDw6xoF
l/sEHR8r4kGxjcG6va3C7+89I0mABpxuESX6hZ/MnIvRjbc65/ZQFKUW5cod
InwDa1C6tmwIPR67AP+w5CnBCbhQ5S6KB/+u6y/MUMs3yUo/ffYO518yo8xj
7FLiHSfF8sSnsp39lRisVPAllf0lWS1ZKK6Yd5OS3UjBfSVY+pD71kUlUNa0
qdfqLZRqg9GUkrzcYLtZyMGzKCvBIZFS9c1r1cvg+5pmr4Zfcbyp23acYKzs
d7VdQzlDaFlNYRlSLibAfo2EMcL7TrNIQhKlljnIZi1RAz02ehxzyVkhcEB6
MufAsXbvpApjyyooWE7PLs0WaRRwJK6U9cPb1qRziV01e8UVMq/NBHtRy1jG
Cx5XemUMUi8VOiDYM4Msz7kOBdxTqg0frKLikzTOTsNo0liLejN85kbalClN
2COpcyHCqULtBpaTie4u+Wymwe/7yUJtozt3hlbnuW9Iuv54x6wNIVVeuDh1
KZIUYgaKZl9aIlJCuJIqH1esLWMso3Y1Hmi1nZSA4b/MqW2KnCpwx5+3Yswc
WgOkyVQkGsInk/qjjKaDCvcg54yxG/uGRkgVT8cwhsDnosxIPkt8GQsyMmmD
ECVsGE7QDTbGx0KtkApjmRBMoP8VDfKMiunl1A2X0irBoBxOOWPuSeoEsVw6
g1utcUMspO0yK8s0t1qoZZu1CLJxBIVLGBNZE8eo87Zs0B+jmZIp+m1Rlc6p
8Wh6954jDMxfS1LFtbBimw6p0E4M5jJkx6n7AfWXyQCwJmJ3uZwzyYZDYUtv
z3rXJT75PKM8G9FgRsO8URrhB1JVyz7Qq9O5CrSxl9znv0pCFHrzEJNXZTc4
2HntD3EiledVQ9aN4Keb5RKyM5eqOo6U8q2aSgwtNYHCvjHizKJW5MO2aBzr
0D0Z3py6qsbvWAnoPueKm1oh4ZhIp9jRbNeZlQUqlPdwQUJF2WvgWKowiaic
xrBGTgzvhU3we2swT6S8IQpWatKEB7ZwLEQSP24co32sH59lDqjpdqMLzk4X
QMs8gQXrhnPj4dHX2gek6DNb9hRMTBe24xpKZhIOScSS7UOmvlRURNYGNdOa
tASjPZ1kzkJSk7NpPLTlEl7ljeO15jY703SU8odw14FmHeAhiMhFQqAzNSJI
AHM0NQZjklMa8JtoQd1SczE8PIuwaAnOJhuS3izcd2Qp6Wj7ImI0EvGzxQ55
mYbJG1HGQlyacs9wDDU0nffaDoJU+2478d3qqRt7Bt9H1TDz2gpvJBVCzTZF
sSGLkrFKOoD6O8NUoRzYxlcL1zOjNpSfs6LaZkFKf8tb8eC+W+Q7jT3GNeTe
ERO7yatB+QNlY9kQ4scHAyEdYulc5Dm/4j0Uc1YrHNqacqWJm1VCJ2ntKvHY
0gAY2C9wMBSvBOo+wtQoMCeBjKTFws0ZJx4FhsfeMOEKBDuNwn4q77bzOuVQ
Ax4hOzmUf/aV4AtED80rw9GA4Mk6AKFzSc30fQN4HLOouNpBbDI4KTKlPvBb
lMtDe33dzH0JpbQkTwo/Olzt2YdlsUO8DGNXLm/fXZ8m01LHVwXfycBBF+Gk
XOGAVHGB0+m+7cMbEZXp+PSoU5jhw5Cnl3m74Nx56Hj1Tk/KxJxQVtBCFuIp
MS9av4CNJA004AxR/W0Yu9jXNHk8mn828viTEVlYC1ZlvPoqstJXj/RwBTk4
MWBBlmKYsBQHKdkjEArwWsiSQ5Vp+6E6FGQXuzFF7xlAyWmyjJfNNTpAdoeV
7eEDvmJFJ5F2EKasSpqmvyw4zTjAFLG6OMbhiPjCe/iglXVUCZJxDbMv9Bmr
4QxbLxTzWzfqj9sD2MYlL+JkQQQ9YEWFqLz2w0lIbPZ51IlI/y6qGZcb4EP4
hKFBPn7UQB+CJFLMgMnPQD9pzBrDCOaqvsn1ZAuurJt43BVsIQuq5ohsPOg5
Ptrg4y+7bst66YEd9nDWFR3rog3iQZzYzDVIg8h3LFI9IYOosPQBtzF8H8JM
4m5cEsq22MI3GiGypKCFDm4/vdOTG49HNNuuEP+431/fq95IULbDc6K5SkL9
Z81aS2JrrmuUZCnfiy0mZsGe7/FA4Mq1gPlh/9dky8tVGhKWjDQHflZmkBzp
WE90xs/pYI2jAS2kzokv3BTp+XwG8X9pnmtnFZDYs3O9rWCCqP4Yl8u0YTad
HUbZA2dKSCqqudFolv6cBlB8ZFKFunH0c7WLcEGH19MSkOA5ZBJbsBdLax2X
nyriaJmBul7O4i1ig0pqjdVTbTY7ES9kXJIUkvJg63xhkjPIAdZQ30lJrB0A
+hXfDBRUzVjRisxg9ITIzCbR9HZWL8QX2ZJxLaynI4EZyGld5yhBioyxXOtr
HWeF7MFG/LNrR2bLNHsi02qIVddZCp2K7zPQauLMW8QW1eCkh235UWdczq6w
yvqpK3SchVFqPozzJZwjYweUoum3TO44Svs9kXAW8PHUip+E0jgJmkDzDtIb
KJLKflzR3Is2K1PtXdFcPpmNJVigrLTlnE+cYM+geIUVIkp4RxKjSOr/6UGJ
3S4Hys+IGQrBh6o+vj4gVKISMXUN41mrKKZW7Sz8EtYHp5OODF/UQIqPlNmM
igOIS+GZ16CNNDVwnW6dXvkzHOXhHHIm2IC0hpLA++UrcknXfDtRiuI4p/9u
O1OCG1zYlz1blLRFj7MNLM8iiOkIP6lYQTmDemtIIDXR2M067BtZf1wEyCiW
BImJ89UqWqTjwVhN+npYDnFY7txF5Z+0bK/63DWs7I1VdkA3UlZZy4y59HJL
TcAa1CHSO6ES4+LfdSr/oTW45UdfaHM4Zl9SOKQ8xRcN4YY6uTTEvXx28Zxh
/0huN7eASu/CGNglwm6cN4NRd7pl8Ai/5d1ydWTNwIb0k5bchAVxpwWc+QM0
D7uBfLUz/Ijw96JpuyK2rDFG6uu5XPmy5koLpGkWyyUyVLxtQBvB4D4X5bnF
KC0NnhRW8t0ngm5ZfvCOoiskRIhXoWk7K07lo+W6irnWio5jonqziDH5sYO7
q8+RmYeluCYVUEIiQwozpURVYXRqXAX+dJJCpSpxYaEVxTZoCjofp5tANZ+D
yNWqxhEDAY2zkZTqZzWD0xEEpsadwWPVtGyJ87WsfCWI3GeYLbaF9wf5y1DM
3lXG7hEAWlMM8263onYAW2FoFwyTGRHzKmA0NTuGEXFYo2GlU4Q3liQ/pQ6t
74uFMm90VIvPjmonhsaaF9WnHW43prpEhLk3a0U288GJrl1S7DM0TJreSBSB
V7iQ8Dm1gE93okKQp1A4r4yD8GOK1R1sHKC7JHzI6mMqTO+H5SRLTzyYud46
eUnK03bGF2fK9bB31yWn/mIUTwOHcL6OWZ4M6LaxSCBN1YQQlwm3siwG6ABz
SIneHt0M0emFkdselTlKjQ95WG7uS4AaxOYW5c1D5aMqpXpLwcDeTWubcjVT
WY+fTbq/AjnAHRMWhQeMWzb12TMoXzQaVjahB7SpiyMiNn3jL+rMh+lAqyiF
SPj1ActTLTSXCCarv5+9avneic2hnEM7oMPEtKQlxMWQLjvZWw7weGqRIrmk
F5FKT3wZr4dJ0phIcX8Z6Ntx5iSXWfU5CjMUAuUQsd0xeyA+nIhW0H7nt94r
NjkndyawKpWrjDsdZl/KRWTNgYvIODUeFsqpWCjDqqe8paPe3peKa3ScR1HN
vriEkS8/nRRcxdhGLRIGRllULu5GtNYoKpRfAq/aCwRGjCauH6rXZMVOZI4+
DTJoeCxlKFDnvMKbHUkMV0XpHBGvIj0IE8ngiopuHPtR4uLsnciknA2Y/SEP
ITpdqDCoaeGhNHdSQM/yeznqd7AWrTu4hLJ8yCH393qIpwt1fSWb/kazR0Xo
+TsXoC0gdc47cGB3bq3gKAljeEIk3BddDGlGrEvqH4tPTE3UL6ud7vHWqaGM
hWAAbLr7JOUa1ktIIa8mEhfhAI0HXA9wTrEVpZAwz4BzwcjsJVBHsA9GW8DP
HvG+cMWQtHeTh0uEovSbJHbB7Ehd4JxAof4XU68j94sE5um1vOPpNzXUdwzf
nQsoItwxrqoSe/EZMTFHeBB3Whu+Af/VltahJSH1shUiLvstU4Ko9SfffOfr
rIph23MBSQ4KosVm6aQM20R36Pz8ZyzFhxL61ZM0LR2Mxfvgx6mvNrqQ0e4d
QkFeY2ulBpm5zjYty9sDM2F9hxFOn3DhRT5Cd8BHCEMq+Kgm5xjIM8a9PLWb
TrKPdxTGJbUWnPulLulkVsMp2Z0padhKr2xOnK2qM8PMUj9PAkf1iX8aspek
Z3NyXJc0rLU41eMDcuDsc72WroiWUiqGGkKeG9H6Kc57proYBrmHN7T7XuQg
NM1VhuoKWh5rSfpZIEOLn+Rdr8EOEQ1vGzpjglkF+bwV8mHECde02PDvtNA/
42IXTl4EpYyVzK2KelsEA96XxlUEFU3cKHM3dQmwUyj94aPvGUYvgUf2lHj2
w/q7V4Gw6M785z4owvny/GawBjjjL5PRSzzQouxks5CobbPTS8z/6JfTY+TO
WKu+L7lKEO3esGfQiqUk1WQBCirrKFPCMZQBCKmJWdEipvN6voJ/RhwZGSfP
5clv2WxbVv0EzQmc85dTvgaHFZyKsTy0uz2O/rHcHCuYFC/lkQGkblWr5npr
OTMphAxS1LUDFxZnbFQ1xpNJfBifWO1zTyN2FtOqtBGGg+jC7o1tP11mVi9k
5l0oFrFaMqiNEW4+83WE4KMBGnln1xsNZu8L0UqFtuwplypiKxPFy9TBTmZZ
0yW1EbEdxKNQfBEVWiRWNDigIvbw4n5p9m+/ufdtcNC020qYyUrVELby6uJS
LmaQYAFrAwmbYo2AF0dPVcTs5RY7lrrJ3RhYGeJQBQNxcp+nAr1jXjjNYolP
+R+mA0gaP98TfGEccIiGh6+e74dXBENVzlpcJnot/o3oDjszoRGPlvwS1XAU
DrLhS7yY9fdNVUg1TTqyuHJI9o404POeNI399NdOhG7J10P81XJHo7r0Xufw
SMBQr5lXY//WUXPy+mzmujFz35Q+rweJp3YvJtmGqJQ4kmO9JeYBQUChrEso
B1FaDflKlaol1iMpc+OSGxViOKHxdhXAH++YjD1gSOxpglpxp4Xy5qepFaN8
hM3tZ1H5MtNxGobhjL1BHC+Dr0sdV5YeFLnaoorioEKXKkUS/XPizoaGkVTy
sGp0iNhNELEb5mkNlR4HpScubFTHo9X4ZRec6b5+D8h5sZ0LTJaLhYG+3FD9
sT2Ni3uZCRVUFC1IdajSl5NuxBLKrKRhaZFBD2nS0XgnrZbxZDmiSe5xpkCT
1lRqi7DL6QV+LF9Q8ErGGIJsHD/lEmQajPAWoUWP/WWCC6nbVLn4pITisG/0
ih8+H2Dx48HyhCKp4aLs6CbRCPkMFPxV9KS5OTVmjIq6PI2bQZVGwXOxdRdh
KKJRHCGaNmapVpp5cyyr4NMjFRADRdy9HDgwFXaU+0Ip0BY4dQQ1GbbsUfRQ
7qIUJ2itBSS4ajOXLhqefH83SrjrywhcNBHui0tKyP0mBl/U6PBLH2aQhZiY
1z/NAw7ZWnoVag7ROaR1p17/we1qCRJtgHl+5RPQoEiUlRGwcbsoI1hqCB5M
CI5FlFMwanJFfXS/s9zGwRYBijiIUaciMhSEBwwuhOCWTXtrgxpn/fHs1ZjJ
ekXWfrVzqT1dsxXP11KOg19Lby1gfGjOt1OI/hDQrV3BxeBigbznGpfg9aqB
GnL67HxCI8n0unkkBDuEA0nHC5XGFkRyLiTSstrTcmkx5v9QSKQI5VtQmywa
Itk8B65WhAsdbwNW8/Rg8tD6kbypy7nYI4yAVKYuj+rK8XUEoeaddOOD8DXW
uxYv3gBAqdDfl0+lXB+HgAUNzwWzuU/Om//RYMgtPUgaMHfRcYQxlHnsmgkw
s6Cvsu1XCzAMpFlJ/Twnd7l6QPNaq8LI0qzzD+V6u/bY3IBPDZf22gE6Ovn6
60cPmaSwW/dPvsOOHQehEKSMO+A0/oljs19np3W8XyrPlVGG+6J7DzSnBf2J
tnNVXmVPVnl7mV8zL8SNJKL2IThz3iMfQFk7RjZDdpyE6AE1GP30+3v5ODJB
ySXVpJhmfCb8QuXZyTePuJ148fltTSF6nP2U/eCQ33vkmx/j6jV67O9/z0bU
8UiisnX2WjOBDz3pRtz0iMykX0SV7wor68uOpJDQaNmEelyOfqJWxo64S36s
wlVGqUFq7npmiqvMHJcqa6Ulf4mtB48hMnz6+nTPocxfag4+6UAatKxgtfJS
CY809F0wj+zCe4tuOF+X6WK3AWrxEnhhEIaVQEFsPq7lFYFKan+TtQS4/L1m
CirbuZj1G1ny0BE+2vjaoSPoE+lI/sLLPYKvl0dEtgZuenv2bxdsCiWRu3io
LBClZT3kX9I4reToPIlSv9PiBiNt/f7JI75sU8Gvy221LOWM75I6wJEowV6L
6qJXsXkIBjWoPtV0n56F2pEiqSpS6HVz3yqkAgxR78BmNbH/RCt/sfy4uAYh
24sIZovbf7YDNrhWdBoqvd2bnHzz8DPje63FBQfFDYVufdbhZxp5Z0UpioUV
JPRXn3VSQnj0uhmF4qARrsGrnYN1Z1hxdIlpNfrMIIg6pvcfEAuptut6fwBn
L8bZs2ew4a2IbYjif2Lz/J1wdZy+yjHCT5STl0TD0zlgFkRbos5oeqF3iPN9
9D65UJHRjIeAAzuQGtvnb9qiIbolIn3V9GX22xZK4ZOirtmDcpXLoX2zLuCX
aa9IM9J0ywMpi47FHGcU5GzQ6F2QuhN+gOgzinCKSN3pJaAcZxA3yuBGAlGc
9AbD4aVzXCYWLqVfzc/CF0WzcM/rq+x00ZZ0sJ7nsDzG2VPQ+I/40Pdj9zSv
y6IiqbWqsx/p1JLIHbvTqvgAtbGo6vKquR6735r8Ontd0k/PWtJa3xUdsZgq
5+X6a76m5fwpX2yveD7vwAbO8+pvEV5SaDm6ydbf3uWYtQBFi7GyDDkjvfcy
e04Hbi5hycxDKkx9efH2p7fR3V5OgtVjq3LwLq82q+xFo2OwYOKy3ZY93w3p
7z4DVeEKGjie5D5GLaP+KwfksduXVTOjl3HlluYHhbugWcxJqBCG+dkpGz6s
6CdxsST1MY+iT/wy/ZfehPFkFmrsBl2KmunimEiSBhv/8FUHPCMZ3TTiozy6
pgt3fsPHPYov3dKrPAwVOki3JxWY1MnGJy7E/XDOE+RcqxlOcUEMmmhTXZty
gEtsa8YDRdA+F+cDXEDM41rbmsyco7OLYy2M+v2jE/iuX1xcvM0kB5mtGWUq
7ghUcJz6uTGdi9Ozn+jbl5OnU5pAi3vjq24CZwuLx7MLk8wwQAJUnndQon98
iWzgoytSUFtkLkLV/MAHPFoqJ+dSAApHZ6fdsUHN9G5mQ1GPpFI6sV0uqlNA
/nO5ZsD2yUg0G4w9OcpGfVkK4mhbFsf0EunA1M/dJ+ogfI5vjiXgtgBIdLOV
8rdM+3y3qnBTuEAXckVRepmlRgPlxi7M8uzCSVhszWExDuUyXZExajRZhKtr
2eCyfBFJeIsDeM5uNkL8VvWS4AouW6kcrWWx2jwkmMu4KgbuYlOhcu/d6umh
xIErM8vXwk2MWGFloyuKdeelPDHqihMFiFSENpxertzxDfRectAL6BzBbXAd
qZvNwDe7P1t66hBEavWOiQaOU7IANIMQjGrKXIsdstkRStsToeRJIDZYi0mV
WgDiQhrWXoRkmFnNo4wzbYnIoQ4mdyMlzUT1aRS7Byz44QcktaiTXiRrfNuJ
TZjH9wTmQXbxo1r53SPiiG4kZRMQLE54hUkP488ur5ZgM2f3iB9aq5fzjnrj
C2nEBps8PXv1zP36I6v7kqCZ8rQwDT6ASqjS+BploTl0OHZJTldAG8vrC602
wAVG9xfe357q7BYYZCnoaBbpDews9VF1ry6shEGSPSsJnE5vCJfkTdzzIWl7
RYQVl5hTgEN3WsYoDiQO7kLn0bLXNRcOu2LMoIfYSTgc0ByreYSnzp13XYHV
YqpshNJnnBPSF7Nb/IxDZdT5CEAeurACGGBkemfaHnQhZr0RYYqBlXuWK8Cr
SsKv6rf0+4ACcKvN1SY+9LwgA17iVSwuXyEoEMBPRDMYVN32HCPfXhqqEQIw
uvNXjf41M2UaE2DXTfA1yVVnzC3CmizD9drDSg9j7DH8XRCHXeRjgx7cmSIc
O6QDvnoIavbrMJgVVuSm8VdT2CS7sWcBxh4ZFYZGSlIaHsvPH+/wMuttErqq
CfMUj6t1tkrrvCfZEFJ4dV8RiKwLtAUy5euJZQBBO5hGtUhCJnAoWufnc9h2
0pualnbzODvv+B22RDu2GyVRktaMD8tYE9sONmhoWE42d3l0y6DUGsNh8l1s
fOnSW4oNcTg7rzUuFx6SKyQOCo7j2FbG8opTNYuOnjneovplCXeEN2vL9U+1
XMhuKAqaXjIhtMpKt22JrRdjx5c1CDYs727h0mbp75AiDsUsPcIMZd+X+s0+
/9nnKIeZyGC9YyEsbDH3SokpzovgUjSChusoTSQB3nVYpCU1Im69i5pLvpln
hQMOZLtUTRdBIMN4BGN+DeXb6wvxsLK9YSUCbK+QDHSdWI7Fi5jkxgwTZzzL
Cysa5uszpbQCq6YrCamJwZL76w4kMe1XBEUrrofDxKoNRJyVBBuucQObuy70
BrYPDBxlHyiQOe+ohTw1qY16wu3v7DMo15L16RMrcLRZujo9I4EMD0wwwTeg
7hKAFSrFddPky8m2LQd0vB9h4rwvLSIxoXHPOHEgFPscXFPHZoAiQtIyFZnF
p1Xs1iqCJBOh4aqMWCFiWKQLVP3KBQza4fghz5tL6Rl0ziDZBtdlgTekK+ac
XLAx2kCDNLDSbLcQZXI9NvcTcswtOunym7z1Mk/fMZ7rcwOHHEJqJu4D09GU
X7m0TVNa/dq1DalbOPhLySpx0USC9qmVtIy+mXK9HnxoDVjXlJpbUojjQOqo
hR+4UlQKiBftovaJ7SrJOaiKYy6hAdI2jzOVk9kLVvrG4kbMAWbZcanm6Ga/
5wduSFdE4LDcg14JggYMg/HgfsYFHxjxLyvPSnaa6a0pMFZDByum4eEIU2A3
4EUdG4EctP9cBDQOBlG0lurnz1AWsU3oBgTHaqv7bAO8jB5lctpeIgNFL3uE
V57zAl2a/NvvNkobolSSMoJ4c+9lifWKqy5Bkv22lnxYPgkwfiS9Hml5ODTR
Nfc74CbA1zlZoSVKObl3/9GYfcQhYpbUFpZW4SEVQAzv271790h5el30cyQY
AEEqN9tw8o0kWyHfXm6VKGvI09yKRmfGrPtVelec6nBs7+daVndP/TJT6LBO
YMLQYUNECgb9WUzN1DlhIXxBSRc1cbadVo274spU8NnC2pFzIkZU34jKywYi
PlTqFFPtXHPdu2PWm/ge3rjoF5d8A0RjK8BHj6ZMACEMKxhWCuXyf6XG281V
nrMTwGt8fbHpYkHvQkkyZZXMOwRjPPE5oXz1kMcy3Z+GkC00fNEj7kbpqZNN
XrYqsjWMaFd7CAFiL39GwzEQXRUDGLVaCWUk4vr+yDeqFwf8JzB1XVfBhmy7
PJvApTlSMCkyk6YISxIBP/zuz//5pa9oZ+mr7iSaLRDxhXiWmSPt+1zsvirL
15A6JxIIkiPIfPPxYEw8INQD3JsChsnAcpjYE+oJw/57Zi8uLml3JyRJT755
lE1mZQ2wX/iZFGv6lvjmo4fDZTjYZbIE/5NdP4hW0ePQzs7fZUexu+i8vGT1
Ue/rDVF3jqo5I4KxVvLaNdvk2mwSUmAZckeXKB1nr6kHBotwdO3YLcuiWtDy
Dxaj+K9sgqM5gRTNRnfPfvjxyd3zix9Oif/c/fmHC1Kz7775ga3Uenf37PUP
0aqNkpKnE47EH9zH9Ot5145AYQ+BS7ewE5ZENb2z03RxTtVbvFPn+2WT+Wv5
CrfIFZchpZqwNMgqDsuiIShqlWkT3jJ+SqusyJYktp5kqnJZMi92BBVmVSFz
KYqGTbpp6Gh+45040eEeZ1viMflCL//u9WJfCZTalmZHWgcgiTJAHvURa+MB
w00DpZ0ZhBj1EzLqJ7gqb6Tna+yimik3jR1cfl2z1ZFAQewwOxGWEqq+eHVx
MELvOZTpBDvKkgPZjQt4waMpMLOW4y9c7UiP1nFoEHxdCLnLl3IF3wwqgAs/
hAs3ODIHbGnX4eI9FWytpJfeNPVXve4N1z4p+68691eGsWfh1JR9xt/FPl4p
yYhzxqF1rJDVi7gseMFbx3X9on2hOX5LjI5hjDnfmTad+tFLF5oAKPRxVCIP
qOwttJC7QcBIRn7MzhdSExAobkgMcDYYRrQszUeH8diC04Y43pC4HgnIKJ6E
3G0pW+FXnk27ZD7fTbMzJgyt+PJ51hQIzEupiEHxAeULLbl+TByVg8OVp3F2
Sh1/nzBGPBxsXD0Z8sXJ8ZhbhEUJctY6Db3EixyfRtCRZpsccbIdl9E0yzI6
k8cQ4/emNBt5mseDYi3Dyhz4Lp1VQJi4207fsN4RtRFGbEcX5ZN05U4S+R5O
ovJwraAP3WWsdesHMUdv+YcygKJU0epoDXp8jLwHvLKqCJneyD1YzQqxiFxw
wBPjlCqYW3WoIWgQReTRqnbgK+0Toa8QLAIAJIot7Ls8JfJ4h8NJzskvZpeJ
SfGp2KSknlYAYYIaNMY1DG/5yDmzDHBRjl9gmGR7hNhhDBBgP063W69RT34+
ier0o0400AGsW7IfF/IF1X/yUhz3GuTVykIOhVQBguM9w3CCI5XE8QTIU+Ef
rPojqBIu6o3KL1qtXF4a9DuO67s1SQXdQaG+usnUwLRLViznXCJGvMR2sU2H
W585AWf06vS3UVLM9+i8mE+zb6YPjr0Zmbi+x4mXMBpeWltLr5xBkpqUifM9
BN+Mwd4Bfpa6VZ1o6MGFxpm8kefPyjCmhYfEKPWxkJBHaIX/QukkEHnZXU1p
U9jPwOvySfc2tostnsM3gCbsHojGvNVEj1JKc2Xz3byyyjONWftSjdfy1tjR
UDfpYaUh8ug4HPXs7Ok5g+AYa5mEfoKGrs4syUQMYXyPsGa5yJ4poyJIuDa1
OKntdVcQ69CquU5iuxIhp8HxmLSqhsyqqa2MlYX5JADJZDyokOVnpemSHsBu
trcfIddNio0P9qnjN3HCcv6cgl5nu8PcwDoLN8h6DHxA+AtuP0ltsSQS2TMn
2lHfc6RHcOea2FoW6hn4ZPcrAfGxgV9IHRe79qaQTD5/mcVXwY0zNmwyTqvS
XJxeIYlA+h47KkSpa2Y8t8U43HXeLtx2s4EJzrc3EFd7cM88UBeHCH/tE3+9
N4v0GNTG6scu1BuZKRp5Cbeyv71D4vpJCqQY2WUoBwoXHZ/567JjwGKbc1xy
tlMfHppHfoLchaG8TWfOK84uVydtMvUJslBfp4Fwy2KnL3J1XGtl/qc2zxcl
xOiOZdZna0bcPwEvR5xuctbUS1qNHlU7Sy6iJ1AubDngqo9VR1gY3lbn4ePE
A4Dt9AtHcB8jODPcGC3Wk0JRZnQ+oosKxlo8Xvga16VKQJBJVVPHpUIk2Za3
M7m/xvyBqGrC9Yz12sMvHfI9XrTzZwHuRsMeoO/QBz3yhU3e+/5Qk4bG+9JG
vjvUiIfpfWkr36KVdyiRxfapx1JyLacvbOORU6oZgLYlpV2u57E4bgxUjdGt
X9rXN+jrlTFdP3VW3BMU45c2+BANSqExBDT1zgJmfTfNZLPiwmPRhcx7xQe/
qJcH6OUpl9VecLpZvYDuBO2TSJT9Hj7j3B8tu9ivysLF4xjYq2Yh+S63XhLL
0HhOahj60eWSBaiFciTQ3mviJS3gkT11rSW54KhQjvBlM2TecsqlpYGkOlTc
zVAJU/+kzD9Kxw1sxePF8PRZxAzEZ3k7N1DbWUJfzWzbsRw7A7CMFy0B8Kv1
pfuQNmc3yEz5hFyTINARSIBMiSDqLb02ywcu9K4sb2EVkrtZ9y7j7bBbP+sh
APZLl16ZKtdi0CH6K8Rx5tgYIOk26fhWh+tizlXMwn75yeCCBqsrqQEuibWK
8XTLK/5yyniZ2TjsDJfSZdHlMBKL91kVdoOJN7n26SSPToBm+4Wr2/UGpGN5
/K9bSw7hjQWeIVTYsmX50pW9h8umuNqNXc0wdf8PaC0aM1vDAAA=
</rfc> </rfc>
 End of changes. 184 change blocks. 
1633 lines changed or deleted 799 lines changed or added

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