rfc8773xml2.original.xml   rfc8773.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2104 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/refere
nce.RFC.2104.xml'>
<!ENTITY RFC2119 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml'>
<!ENTITY RFC4086 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/refere
nce.RFC.4086.xml'>
<!ENTITY RFC5246 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/refere
nce.RFC.5246.xml'>
<!ENTITY RFC8017 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/refere
nce.RFC.8017.xml'>
<!ENTITY RFC8174 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml'>
<!ENTITY RFC8446 PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml/refere
nce.RFC.8446.xml'>
<!ENTITY C2PQ PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/refer
ence.I-D.hoffman-c2pq.xml'>
<!ENTITY IMPORTER PUBLIC '' 'https://xml2rfc.ietf.org/public/rfc/bibxml3/refer
ence.I-D.ietf-tls-external-psk-importer.xml'>
]>
<rfc submissionType="IETF"
docName="draft-ietf-tls-tls13-cert-with-extern-psk-07"
category="exp"
ipr="trust200902">
<?rfc compact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
<?rfc text-list-symbols="o*+-"?> docName="draft-ietf-tls-tls13-cert-with-extern-psk-07" category="exp"
<?rfc subcompact="no"?> ipr="trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true"
<?rfc sortrefs="yes"?> symRefs="true" version="3" number="8773" consensus="true" tocInclude="true"
<?rfc symrefs="yes"?> >
<?rfc strict="yes"?> <!-- xml2rfc v2v3 conversion 2.39.0 -->
<front> <front>
<title abbrev="Certificate with External PSK">TLS 1.3 Extension for <title abbrev="Certificate with External PSK">TLS 1.3 Extension for
Certificate-based Authentication with an External Pre-Shared Key</title> Certificate-Based Authentication with an External Pre-Shared Key</title>
<seriesInfo name="RFC" value="8773"/>
<author fullname="Russ Housley" initials="R." surname="Housley"> <author fullname="Russ Housley" initials="R." surname="Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<postal> <postal>
<street>516 Dranesville Road</street> <street>516 Dranesville Road</street>
<city>Herndon</city> <city>Herndon</city>
<region>VA</region> <region>VA</region>
<code>20170</code> <code>20170</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date month="March" year="2020"/>
<date day="23" month="December" year="2019"/> <keyword>cryptography</keyword>
<abstract> <abstract>
<t> <t>
This document specifies a TLS 1.3 extension that allows a server to This document specifies a TLS 1.3 extension that allows a server to
authenticate with a combination of a certificate and an external authenticate with a combination of a certificate and an external
pre-shared key (PSK). pre-shared key (PSK).
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" anchor="section-intro"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
The TLS 1.3 <xref target="RFC8446"/> handshake The TLS 1.3 <xref target="RFC8446" format="default"/> handshake
protocol provides two mutually exclusive forms of server protocol provides two mutually exclusive forms of server
authentication. First, the server can be authenticated by authentication. First, the server can be authenticated by
providing a signature certificate and creating a valid digital providing a signature certificate and creating a valid digital
signature to demonstrate that it possesses the corresponding signature to demonstrate that it possesses the corresponding
private key. Second, the server can be authenticated private key. Second, the server can be authenticated
by demonstrating that it possesses a pre-shared key (PSK) that by demonstrating that it possesses a pre-shared key (PSK) that
was established by a previous handshake. A PSK that was established by a previous handshake. A PSK that
is established in this fashion is called a resumption PSK. A is established in this fashion is called a resumption PSK. A
PSK that is established by any other means is called an external PSK that is established by any other means is called an external
PSK. This document specifies a TLS 1.3 extension permitting PSK. This document specifies a TLS 1.3 extension permitting
certificate-based server authentication to be combined with certificate-based server authentication to be combined with
an external PSK as an input to the TLS 1.3 key schedule. an external PSK as an input to the TLS 1.3 key schedule.
</t> </t>
<t> <t>
Several implementors wanted to gain more experience with this Several implementors wanted to gain more experience with this
specification before producing a standards-track RFC. As a specification before producing a Standards Track RFC. As a
result, this specification is being published as an Experimental result, this specification is being published as an Experimental
RFC to enable interoperable implementations and gain deployment RFC to enable interoperable implementations and gain deployment
and operational experience. and operational experience.
</t> </t>
</section> </section>
<section anchor="term" numbered="true" toc="default">
<section title="Terminology" anchor="section-term"> <name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="motive" numbered="true" toc="default">
<section title="Motivation and Design Rationale" anchor="motive"> <name>Motivation and Design Rationale</name>
<t> <t>
The development of a large-scale quantum computer would pose a serious The development of a large-scale quantum computer would pose a serious
challenge for the cryptographic algorithms that are widely deployed challenge for the cryptographic algorithms that are widely deployed
today, including the digital signature algorithms that are used today, including the digital signature algorithms that are used
to authenticate the server in the TLS 1.3 handshake protocol. It to authenticate the server in the TLS 1.3 handshake protocol. It
is an open question whether or not it is feasible to build is an open question whether or not it is feasible to build
a large-scale quantum computer, and if so, when that might a large-scale quantum computer, and if so, when that might
happen. However, if such a quantum computer is invented, many happen. However, if such a quantum computer is invented, many
of the cryptographic algorithms and the security protocols that of the cryptographic algorithms and the security protocols that
use them would become vulnerable. use them would become vulnerable.
</t> </t>
<t> <t>
The TLS 1.3 handshake protocol employs key agreement algorithms The TLS 1.3 handshake protocol employs key agreement algorithms
and digital signature algorithms that could be broken by the and digital signature algorithms that could be broken by the
development of a large-scale quantum computer development of a large-scale quantum computer
<xref target="I-D.hoffman-c2pq"/>. The key agreement algorithms <xref target="I-D.hoffman-c2pq" format="default"/>. The key agre
include Diffie-Hellman (DH) <xref target="DH1977"/> and ement algorithms
Elliptic Curve Diffie-Hellman (ECDH) <xref target="IEEE1363"/>; include Diffie-Hellman (DH) <xref target="DH1976" format="default
the digital signature algorithms include RSA <xref target="RFC801 "/> and
7"/> Elliptic Curve Diffie-Hellman (ECDH) <xref target="IEEE1363" form
and Elliptic Curve Digital Signature Algorithm (ECDSA) at="default"/>;
<xref target="FIPS186"/>. As a result, an adversary that the digital signature algorithms include RSA <xref target="RFC801
7" format="default"/>
and the Elliptic Curve Digital Signature Algorithm (ECDSA)
<xref target="FIPS186" format="default"/>. As a result, an adver
sary that
stores a TLS 1.3 handshake protocol exchange today could stores a TLS 1.3 handshake protocol exchange today could
decrypt the associated encrypted communications in the decrypt the associated encrypted communications in the
future when a large-scale quantum computer becomes future when a large-scale quantum computer becomes
available. available.
</t> </t>
<t> <t>
In the near-term, this document describes TLS 1.3 extension to protect In the near term, this document describes a TLS 1.3 extension to protect
today's communications from the future invention of a large-scale today's communications from the future invention of a large-scale
quantum computer by providing a strong external PSK as an input to quantum computer by providing a strong external PSK as an input to
the TLS 1.3 key schedule while preserving the authentication provided the TLS 1.3 key schedule while preserving the authentication provided
by the existing certificate and digital signature mechanisms. by the existing certificate and digital signature mechanisms.
</t> </t>
</section> </section>
<section anchor="over" numbered="true" toc="default">
<section title="Extension Overview" anchor="section-over"> <name>Extension Overview</name>
<t> <t>
This section provides a brief overview of the This section provides a brief overview of the
"tls_cert_with_extern_psk" extension. "tls_cert_with_extern_psk" extension.
</t> </t>
<t> <t>
The client includes the "tls_cert_with_extern_psk" extension in the The client includes the "tls_cert_with_extern_psk" extension in the
ClientHello message. The "tls_cert_with_extern_psk" extension MUST ClientHello message. The "tls_cert_with_extern_psk" extension <bcp14>MU
be accompanied by the "key_share”, "psk_key_exchange_modes", and ST</bcp14>
"pre_shared_key" extensions. The client MAY also find it useful be accompanied by the "key_share", "psk_key_exchange_modes", and
"pre_shared_key" extensions. The client <bcp14>MAY</bcp14> also find it
useful
to include the "supported_groups" extension. Since the to include the "supported_groups" extension. Since the
"tls_cert_with_extern_psk" extension is intended to be used only "tls_cert_with_extern_psk" extension is intended to be used only
with initial handshakes, it MUST NOT be sent alongside the with initial handshakes, it <bcp14>MUST NOT</bcp14> be sent alongside th e
"early_data" extension. These extensions are all described in "early_data" extension. These extensions are all described in
Section 4.2 of <xref target="RFC8446"/>, which also requires <xref target="RFC8446" sectionFormat="of" section="4.2"/>, which also re
the "pre_shared_key” extension to be the last extension in the quires
the "pre_shared_key" extension to be the last extension in the
ClientHello message. ClientHello message.
</t> </t>
<t> <t>
If the client includes both the "tls_cert_with_extern_psk" extension If the client includes both the "tls_cert_with_extern_psk" extension
and the "early_data" extension, then the server MUST terminate the and the "early_data" extension, then the server <bcp14>MUST</bcp14> term inate the
connection with an "illegal_parameter" alert. connection with an "illegal_parameter" alert.
</t> </t>
<t> <t>
If the server is willing to use one of the external PSKs listed in the If the server is willing to use one of the external PSKs listed in the
"pre_shared_key” extension and perform certificate-based authentication, "pre_shared_key" extension and perform certificate-based authentication,
then the server includes the "tls_cert_with_extern_psk" extension in the then the server includes the "tls_cert_with_extern_psk" extension in the
ServerHello message. The "tls_cert_with_extern_psk" extension MUST be ServerHello message. The "tls_cert_with_extern_psk" extension <bcp14>MU ST</bcp14> be
accompanied by the "key_share" and "pre_shared_key" extensions. If none accompanied by the "key_share" and "pre_shared_key" extensions. If none
of the external PSKs in the list provided by the client is acceptable of the external PSKs in the list provided by the client is acceptable
to the server, then the "tls_cert_with_extern_psk" extension is to the server, then the "tls_cert_with_extern_psk" extension is
omitted from the ServerHello message. omitted from the ServerHello message.
</t> </t>
<t> <t>
When the "tls_cert_with_extern_psk" extension is successfully When the "tls_cert_with_extern_psk" extension is successfully
negotiated, the TLS 1.3 key schedule processing includes negotiated, the TLS 1.3 key schedule processing includes
both the selected external PSK and the (EC)DHE shared secret both the selected external PSK and the (EC)DHE shared secret
value. As a result, the Early Secret, Handshake Secret, and value. (EC)DHE refers to Diffie-Hellman over either finite fields
Master Secret values all depend upon the value of the selected or elliptic curves. As a result, the Early Secret, Handshake
external PSK. Of course, the Early Secret does not depend upon Secret, and Master Secret values all depend upon the value of the
the (EC)DHE shared secret. selected external PSK. Of course, the Early Secret does not
depend upon the (EC)DHE shared secret.
</t> </t>
<t> <t>
The authentication of the server and optional authentication of The authentication of the server and optional authentication of
the client depend upon the ability to generate a signature that the client depend upon the ability to generate a signature that
can be validated with the public key in their certificates. The can be validated with the public key in their certificates. The
authentication processing is not changed in any way by the authentication processing is not changed in any way by the
selected external PSK. selected external PSK.
</t> </t>
<t> <t>
Each external PSK is associated with a single hash algorithm, which Each external PSK is associated with a single hash algorithm, which
is required by Section 4.2.11 of <xref target="RFC8446"/>. The is required by <xref target="RFC8446" sectionFormat="of"
hash algorithm MUST be set when the PSK is established, with a section="4.2.11"/>. The
hash algorithm <bcp14>MUST</bcp14> be set when the PSK is established, w
ith a
default of SHA-256. default of SHA-256.
</t> </t>
</section> </section>
<section anchor="extn" numbered="true" toc="default">
<section title="Certificate with External PSK Extension" anchor="section-ext <name>Certificate with External PSK Extension</name>
n">
<t> <t>
This section specifies the "tls_cert_with_extern_psk" extension, This section specifies the "tls_cert_with_extern_psk" extension,
which MAY appear in the ClientHello message and ServerHello message. It which <bcp14>MAY</bcp14> appear in the ClientHello message and ServerHel
MUST NOT appear in any other messages. The "tls_cert_with_extern_psk" lo message. It
extension MUST NOT appear in the ServerHello message unless the <bcp14>MUST NOT</bcp14> appear in any other messages. The "tls_cert_wit
h_extern_psk"
extension <bcp14>MUST NOT</bcp14> appear in the ServerHello message unle
ss the
"tls_cert_with_extern_psk" extension appeared in the preceding "tls_cert_with_extern_psk" extension appeared in the preceding
ClientHello message. If an implementation recognizes the ClientHello message. If an implementation recognizes the
"tls_cert_with_extern_psk" extension and receives it in any other "tls_cert_with_extern_psk" extension and receives it in any other
message, then the implementation MUST abort the handshake with an message, then the implementation <bcp14>MUST</bcp14> abort the handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
</t> </t>
<t> <t>
The general extension mechanisms enable clients and servers to The general extension mechanisms enable clients and servers to
negotiate the use of specific extensions. Clients request negotiate the use of specific extensions. Clients request
extended functionality from servers with the extensions field extended functionality from servers with the extensions field
in the ClientHello message. If the server responds with a in the ClientHello message. If the server responds with a
HelloRetryRequest message, then the client sends another HelloRetryRequest message, then the client sends another
ClientHello message as described in Section 4.1.2 of ClientHello message as described in <xref target="RFC8446"
<xref target="RFC8446"/>, including the same sectionFormat="of" section="4.1.2"/>, including the same
"tls_cert_with_extern_psk" extension as the original "tls_cert_with_extern_psk" extension as the original
ClientHello message, or aborts the handshake. ClientHello message, or aborts the handshake.
</t> </t>
<t> <t>
Many server extensions are carried in the EncryptedExtensions Many server extensions are carried in the EncryptedExtensions
message; however, the "tls_cert_with_extern_psk" extension is message; however, the "tls_cert_with_extern_psk" extension is
carried in the ServerHello message. Successful negotiation of carried in the ServerHello message. Successful negotiation of
the "tls_cert_with_extern_psk" extension affects the key used for the "tls_cert_with_extern_psk" extension affects the key used for
encryption, so it cannot be carried in the EncryptedExtensions encryption, so it cannot be carried in the EncryptedExtensions
message. Therefore, the "tls_cert_with_extern_psk" extension message. Therefore, the "tls_cert_with_extern_psk" extension
is only present in the ServerHello message if the server is only present in the ServerHello message if the server
recognizes the "tls_cert_with_extern_psk" extension and the recognizes the "tls_cert_with_extern_psk" extension and the
server possesses one of the external PSKs offered by the client server possesses one of the external PSKs offered by the client
in the "pre_shared_key" extension in the ClientHello message. in the "pre_shared_key" extension in the ClientHello message.
</t> </t>
<t> <t>
The Extension structure is defined in <xref target="RFC8446"/>; The Extension structure is defined in <xref target="RFC8446" format="def ault"/>;
it is repeated here for convenience. it is repeated here for convenience.
</t> </t>
<figure>
<artwork><![CDATA[ <sourcecode type="tls-presentation"> struct {
struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1&gt;; opaque extension_data<0..2^16-1&gt;;
} Extension; } Extension;
]]> </sourcecode>
</artwork>
</figure>
<t> <t>
The "extension_type" identifies the particular extension type, The "extension_type" identifies the particular extension type,
and the "extension_data" contains information specific to the and the "extension_data" contains information specific to the
particular extension type. particular extension type.
</t> </t>
<t> <t>
This document specifies the "tls_cert_with_extern_psk" extension, This document specifies the "tls_cert_with_extern_psk" extension,
adding one new type to ExtensionType: adding one new type to ExtensionType:
</t> </t>
<figure>
<artwork> <sourcecode type="tls-presentation"> enum {
<![CDATA[ tls_cert_with_extern_psk(33), (65535)
enum {
tls_cert_with_extern_psk(TBD), (65535)
} ExtensionType; } ExtensionType;
]]> </sourcecode>
</artwork>
</figure>
<t> <t>
The "tls_cert_with_extern_psk" extension is relevant when the The "tls_cert_with_extern_psk" extension is relevant when the
client and server possess an external PSK in common that can be client and server possess an external PSK in common that can be
used as an input to the TLS 1.3 key schedule. The used as an input to the TLS 1.3 key schedule. The
"tls_cert_with_extern_psk" extension is essentially a flag to "tls_cert_with_extern_psk" extension is essentially a flag to
use the external PSK in the key schedule, and it has the use the external PSK in the key schedule, and it has the
following syntax: following syntax:
</t> </t>
<figure>
<artwork> <sourcecode type="tls-presentation" > struct {
<![CDATA[
struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: Empty; case client_hello: Empty;
case server_hello: Empty; case server_hello: Empty;
}; };
} CertWithExternPSK; } CertWithExternPSK;
]]> </sourcecode>
</artwork>
</figure>
<section title="Companion Extensions" anchor="other-extns"> <section anchor="other-extns" numbered="true" toc="default">
<t> <name>Companion Extensions</name>
Section 4 lists the extensions that are required to accompany the <t>
"tls_cert_with_extern_psk" extension. Most of those extensions are <xref target="over"/> lists the extensions that are required to accompan
y the
"tls_cert_with_extern_psk" extension. Most of those extensions
are not impacted in any way by this specification. However, this are not impacted in any way by this specification. However, this
section discusses the extensions that require additional consideration. section discusses the extensions that require additional consideration.
</t> </t>
<t> <t>
The "psk_key_exchange_modes" extension is defined in Section 4.2.9 The "psk_key_exchange_modes" extension is defined in
of <xref target="RFC8446"/>. The "psk_key_exchange_modes" of <xref target="RFC8446" sectionFormat="of" section="4.2.9"/>. The
"psk_key_exchange_modes"
extension restricts the use of both the PSKs offered in this extension restricts the use of both the PSKs offered in this
ClientHello and those that the server might supply via a subsequent ClientHello and those that the server might supply via a subsequent
NewSessionTicket. As a result, when the "psk_key_exchange_modes" NewSessionTicket. As a result, when the "psk_key_exchange_modes"
extension is included in the ClientHello message, clients MUST extension is included in the ClientHello message, clients <bcp14>MUST</b
include psk_dhe_ke mode. In addition, clients MAY also include cp14>
include psk_dhe_ke mode. In addition, clients <bcp14>MAY</bcp14> also i
nclude
psk_ke mode to support a subsequent NewSessionTicket. When the psk_ke mode to support a subsequent NewSessionTicket. When the
"psk_key_exchange_modes" extension is included in the ServerHello "psk_key_exchange_modes" extension is included in the ServerHello
message, servers MUST select the psk_dhe_ke mode for the initial message, servers <bcp14>MUST</bcp14> select the psk_dhe_ke mode for the
handshake. Servers MUST select a key exchange mode that is listed initial
handshake. Servers <bcp14>MUST</bcp14> select a key exchange mode that
is listed
by the client for subsequent handshakes that include the resumption by the client for subsequent handshakes that include the resumption
PSK from the initial handshake. PSK from the initial handshake.
</t> </t>
<t> <t>
The "pre_shared_key" extension is defined in Section 4.2.11 The "pre_shared_key" extension is defined in <xref target="RFC8446"
of <xref target="RFC8446"/>. The syntax is repeated below for sectionFormat="of" section="4.2.11"/>. The
convenience. All of the listed PSKs MUST be external PSKs. If a syntax is repeated below for
convenience. All of the listed PSKs <bcp14>MUST</bcp14> be external PSK
s. If a
resumption PSK is listed along with the "tls_cert_with_extern_psk" resumption PSK is listed along with the "tls_cert_with_extern_psk"
extension, the server MUST abort the handshake with an extension, the server <bcp14>MUST</bcp14> abort the handshake with an
"illegal_parameter" alert. "illegal_parameter" alert.
</t> </t>
<figure>
<artwork> <sourcecode type="tls-presentation"> struct {
<![CDATA[ opaque identity&lt;1..2^16-1&gt;;
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age; uint32 obfuscated_ticket_age;
} PskIdentity; } PskIdentity;
opaque PskBinderEntry<32..255&gt;; opaque PskBinderEntry<32..255&gt;;
struct { struct {
PskIdentity identities<7..2^16-1>; PskIdentity identities&lt;7..2^16-1&gt;;
PskBinderEntry binders<33..2^16-1>; PskBinderEntry binders&lt;33..2^16-1&gt;;
} OfferedPsks; } OfferedPsks;
struct { struct {
select (Handshake.msg_type) { select (Handshake.msg_type) {
case client_hello: OfferedPsks; case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity; case server_hello: uint16 selected_identity;
}; };
} PreSharedKeyExtension; } PreSharedKeyExtension;
]]> </sourcecode>
</artwork>
</figure> <t>
<t> "OfferedPsks" contains the list of PSK identities and
The OfferedPsks contains the list of PSK identities and
associated binders for the external PSKs that the client is associated binders for the external PSKs that the client is
willing to use with the server. willing to use with the server.
</t> </t>
<t> <t>
The identities are a list of external PSK identities that the The identities are a list of external PSK identities that the
client is willing to negotiate with the server. Each external client is willing to negotiate with the server. Each external
PSK has an associated identity that is known to the client PSK has an associated identity that is known to the client
and the server; the associated identities may be known to other and the server; the associated identities may be known to other
parties as well. In addition, the binder validation (see below) parties as well. In addition, the binder validation (see below)
confirms that the client and server have the same key associated confirms that the client and server have the same key associated
with the identity. with the identity.
</t> </t>
<t> <t>
The obfuscated_ticket_age is not used for external PSKs. As The "obfuscated_ticket_age" is not used for external PSKs. As
stated in Section 4.2.11 of <xref target="RFC8446"/>, clients stated in <xref target="RFC8446" sectionFormat="of"
SHOULD set this value to 0, and servers MUST ignore the value. section="4.2.11"/>, clients
</t> <bcp14>SHOULD</bcp14> set this value to 0, and servers <bcp14>MUST</bcp1
<t> 4> ignore the value.
The binders are a series of HMAC <xref target="RFC2104"/> values, one </t>
<t>
The binders are a series of HMAC <xref target="RFC2104" format="default"
/> values, one
for each external PSK offered by the client, in the same order as the for each external PSK offered by the client, in the same order as the
identities list. The HMAC value is computed using the binder_key, which identities list. The HMAC value is computed using the binder_key, which
is derived from the external PSK, and a partial transcript of the curren t is derived from the external PSK, and a partial transcript of the curren t
handshake. Generation of the binder_key from the external PSK is handshake. Generation of the binder_key from the external PSK is
described in Section 7.1 of <xref target="RFC8446"/>. The described in <xref target="RFC8446" sectionFormat="of" section="7.1"/>. The
partial transcript of the current handshake includes a partial partial transcript of the current handshake includes a partial
ClientHello up to and including the PreSharedKeyExtension.identities ClientHello up to and including the PreSharedKeyExtension.identities
field as described in Section 4.2.11.2 of <xref target="RFC8446"/>. field, as described in <xref target="RFC8446"
</t> sectionFormat="of" section="4.2.11.2"/>.
<t> </t>
The selected_identity contains the index of the external PSK <t>
The "selected_identity" contains the index of the external PSK
identity that the server selected from the list offered by the identity that the server selected from the list offered by the
client. As described in Section 4.2.11.2 of <xref target="RFC8446"/>, client. As described in <xref target="RFC8446"
the server MUST validate the binder value that corresponds to the sectionFormat="of" section="4.2.11"/>,
the server <bcp14>MUST</bcp14> validate the binder value that correspond
s to the
selected external PSK, and if the binder does not validate, the selected external PSK, and if the binder does not validate, the
server MUST abort the handshake with an "illegal_parameter" alert. server <bcp14>MUST</bcp14> abort the handshake with an "illegal_paramete
</t> r" alert.
</section> </t>
</section>
<section title="Authentication" anchor="authn"> <section anchor="authn" numbered="true" toc="default">
<t> <name>Authentication</name>
<t>
When the "tls_cert_with_extern_psk" extension is successfully When the "tls_cert_with_extern_psk" extension is successfully
negotiated, authentication of the server depends upon the ability to negotiated, authentication of the server depends upon the ability to
generate a signature that can be validated with the public key in generate a signature that can be validated with the public key in
the server's certificate. This is accomplished by the server the server's certificate. This is accomplished by the server
sending the Certificate and CertificateVerify messages as described sending the Certificate and CertificateVerify messages, as described
in Sections 4.4.2 and 4.4.3 of <xref target="RFC8446"/>. in Sections <xref target="RFC8446" sectionFormat="bare"
</t> section="4.4.2"/> and <xref target="RFC8446"
<t> sectionFormat="bare" section="4.4.3"/> of <xref target="RFC8446"/>.
</t>
<t>
TLS 1.3 does not permit the server to send a CertificateRequest message TLS 1.3 does not permit the server to send a CertificateRequest message
when a PSK is being used. This restriction is removed when the when a PSK is being used. This restriction is removed when the
"tls_cert_with_extern_psk" extension is negotiated, allowing "tls_cert_with_extern_psk" extension is negotiated, allowing
certificate-based authentication for both the client and the server. If certificate-based authentication for both the client and the server. If
certificate-based client authentication is desired, this is accomplished certificate-based client authentication is desired, this is accomplished
by the client sending the Certificate and CertificateVerify messages as by the client sending the Certificate and CertificateVerify messages as
described in Sections 4.4.2 and 4.4.3 of <xref target="RFC8446"/>. described in Sections <xref target="RFC8446" sectionFormat="bare"
</t> section="4.4.2"/> and <xref target="RFC8446"
</section> sectionFormat="bare" section="4.4.3"/> of <xref target="RFC8446"/>.
</t>
<section title="Keying Material" anchor="keying"> </section>
<t> <section anchor="keying" numbered="true" toc="default">
Section 7.1 of <xref target="RFC8446"/> specifies the <name>Keying Material</name>
TLS 1.3 Key Schedule. The successful negotiation of the <t>
<xref target="RFC8446" sectionFormat="of" section="7.1"/> specifies the
TLS 1.3 key schedule. The successful negotiation of the
"tls_cert_with_extern_psk" extension requires the key schedule "tls_cert_with_extern_psk" extension requires the key schedule
processing to include both the external PSK and the (EC)DHE shared processing to include both the external PSK and the (EC)DHE
secret value. shared secret value.
</t> </t>
<t> <t>
If the client and the server have different values associated If the client and the server have different values associated
with the selected external PSK identifier, then the client and with the selected external PSK identifier, then the client and
the server will compute different values for every entry in the the server will compute different values for every entry in the
key schedule, which will lead to the client aborting the key schedule, which will lead to the client aborting the
handshake with a "decrypt_error" alert. handshake with a "decrypt_error" alert.
</t> </t>
</section> </section>
</section> </section>
<section anchor="IANA-con" numbered="true" toc="default">
<section title="IANA Considerations" anchor="section-IANA"> <name>IANA Considerations</name>
<t> <t>
IANA is requested to update the TLS ExtensionType Registry <xref target= IANA has updated the "TLS ExtensionType Values" registry
"IANA"/> <xref target="IANA" format="default"/>
to include "tls_cert_with_extern_psk" with a value of TBD and the list o to include "tls_cert_with_extern_psk" with a value of 33 and the list of
f
messages "CH, SH" in which the "tls_cert_with_extern_psk" extension may messages "CH, SH" in which the "tls_cert_with_extern_psk" extension may
appear. appear.
</t> </t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section title="Security Considerations" anchor="section-security"> <name>Security Considerations</name>
<t> <t>
The Security Considerations in <xref target="RFC8446"/> The Security Considerations in <xref target="RFC8446" format="default"/>
remain relevant. remain relevant.
</t> </t>
<t> <t>
TLS 1.3 <xref target="RFC8446"/> does not permit TLS 1.3 <xref target="RFC8446" format="default"/> does not permit
the server to send a CertificateRequest message when a PSK the server to send a CertificateRequest message when a PSK
is being used. This restriction is removed when the is being used. This restriction is removed when the
"tls_cert_with_extern_psk" extension is offered by the client "tls_cert_with_extern_psk" extension is offered by the client
and accepted by the server. However, TLS 1.3 does not and accepted by the server. However, TLS 1.3 does not
permit an external PSK to be used in the same fashion as a permit an external PSK to be used in the same fashion as a
resumption PSK, and this extension does not alter those resumption PSK, and this extension does not alter those
restrictions. Thus, a certificate MUST NOT be used with restrictions. Thus, a certificate <bcp14>MUST NOT</bcp14> be used with
a resumption PSK. a resumption PSK.
</t> </t>
<t> <t>
Implementations must protect the external pre-shared key (PSK). Implementations must protect the external pre-shared key (PSK).
Compromise of the external PSK will make the encrypted session Compromise of the external PSK will make the encrypted session
content vulnerable to the future development of a large-scale content vulnerable to the future development of a large-scale
quantum computer. However, the generation, distribution, and quantum computer. However, the generation, distribution, and
management of the external PSKs is out of scope for this management of the external PSKs is out of scope for this
specification. specification.
</t> </t>
skipping to change at line 443 skipping to change at line 434
management of the external PSKs is out of scope for this management of the external PSKs is out of scope for this
specification. specification.
</t> </t>
<t> <t>
Implementers should not transmit the same content on a connection Implementers should not transmit the same content on a connection
that is protected with an external PSK and a connection that is that is protected with an external PSK and a connection that is
not. Doing so may allow an eavesdropper to correlate the not. Doing so may allow an eavesdropper to correlate the
connections, making the content vulnerable to the future connections, making the content vulnerable to the future
invention of a large-scale quantum computer. invention of a large-scale quantum computer.
</t> </t>
<t> <t>
Implementations must generate external PSKs with a secure key management Implementations must generate external PSKs with a secure key-management
technique, such as pseudo-random generation of the key or derivation of technique, such as pseudorandom generation of the key or derivation of
the key from one or more other secure keys. The use of inadequate the key from one or more other secure keys. The use of inadequate
pseudo-random number generators (PRNGs) to generate external PSKs can pseudorandom number generators (PRNGs) to generate external PSKs can
result in little or no security. An attacker may find it much easier result in little or no security. An attacker may find it much easier
to reproduce the PRNG environment that produced the external PSKs and to reproduce the PRNG environment that produced the external PSKs and
search the resulting small set of possibilities, rather than brute-force search the resulting small set of possibilities, rather than brute-force
searching the whole key space. The generation of quality random searching the whole key space. The generation of quality random
numbers is difficult. <xref target="RFC4086"/> offers important numbers is difficult. <xref target="RFC4086" format="default"/> offers important
guidance in this area. guidance in this area.
</t> </t>
<t> <t>
If the external PSK is known to any party other than the client and If the external PSK is known to any party other than the client and
the server, then the external PSK MUST NOT be the sole basis for the server, then the external PSK <bcp14>MUST NOT</bcp14> be the sole ba sis for
authentication. The reasoning is explained in Section 4.2 of authentication. The reasoning is explained in Section 4.2 of
<xref target="K2016"/>. When this extension is used, authentication <xref target="K2016" format="default"/>. When this extension is used, a uthentication
is based on certificates, not the external PSK. is based on certificates, not the external PSK.
</t> </t>
<t> <t>
In this extension, the external PSK preserves confidentiality if the In this extension, the external PSK preserves confidentiality if the
(EC)DH key agreement is ever broken by cryptanalysis or the future (EC)DH key agreement is ever broken by cryptanalysis or the future
invention of a large-scale quantum computer. As long as the attacker invention of a large-scale quantum computer. As long as the attacker
does not know the PSK and the key derivation algorithm remains does not know the PSK and the key derivation algorithm remains
unbroken, the attacker cannot derive the session secrets even if they unbroken, the attacker cannot derive the session secrets, even if they
are able to compute the (EC)DH shared secret. Should the attacker be are able to compute the (EC)DH shared secret. Should the attacker be
able compute the (EC)DH shared secret, the forward secrecy advantages able compute the (EC)DH shared secret, the forward-secrecy advantages
traditionally associated with ephemeral (EC)DH keys will no longer be traditionally associated with ephemeral (EC)DH keys will no longer be
relevant. Although the ephemeral private keys used during a given TLS relevant. Although the ephemeral private keys used during a given TLS
session are destroyed at the end of a session, preventing the attacker session are destroyed at the end of a session, preventing the attacker
from later accessing them, these private keys would nevertheless be from later accessing them, these private keys would nevertheless be
recoverable due to the break in the algorithm. However, a more recoverable due to the break in the algorithm. However, a more
general notion of "secrecy after key material is destroyed" would still general notion of "secrecy after key material is destroyed" would still
be achievable using external PSKs, if they are managed in a way that be achievable using external PSKs, if they are managed in a way that
ensures their destruction when they are no longer needed, and with ensures their destruction when they are no longer needed, and with
the assumption that the algorithms that use the external PSKs remain the assumption that the algorithms that use the external PSKs remain
quantum-safe. quantum-safe.
</t> </t>
<t> <t>
TLS 1.3 key derivation makes use of the HKDF algorithm, which depends TLS 1.3 key derivation makes use of the HMAC-based Key Derivation
upon the HMAC <xref target="RFC2104"/> construction and a hash Function (HKDF) algorithm, which depends
upon the HMAC <xref target="RFC2104" format="default"/> construction and
a hash
function. This extension provides the desired protection for the function. This extension provides the desired protection for the
session secrets as long as HMAC with the selected hash function is session secrets, as long as HMAC with the selected hash function is
a pseudorandom function (PRF) <xref target="GGM1986"/>. a pseudorandom function (PRF) <xref target="GGM1986" format="default"/>
.
</t> </t>
<t> <t>
This specification does not require that the external PSK is known only by This specification does not require that the external PSK is known only by
the client and server. The external PSK may be known to a group. Since the client and server. The external PSK may be known to a group. Since
authentication depends on the public key in a certificate, knowledge of authentication depends on the public key in a certificate, knowledge of
the external PSK by other parties does not enable impersonation. Since the external PSK by other parties does not enable impersonation. Since
confidentiality depends on the shared secret from (EC)DH, knowledge of confidentiality depends on the shared secret from (EC)DH, knowledge of
the external PSK by other parties does not enable eavesdropping. Howeve r, the external PSK by other parties does not enable eavesdropping. Howeve r,
group members can record the traffic of other members, and then decrypt it group members can record the traffic of other members and then decrypt i t
if they ever gain access to a large-scale quantum computer. Also, when if they ever gain access to a large-scale quantum computer. Also, when
many parties know the external PSK, there are many opportunities for the ft many parties know the external PSK, there are many opportunities for the ft
of the external PSK by an attacker. Once an attacker has the external P SK, of the external PSK by an attacker. Once an attacker has the external P SK,
they can decrypt stored traffic if they ever gain access to a large-scal e they can decrypt stored traffic if they ever gain access to a large-scal e
quantum computer in the same manner as a legitimate group member. quantum computer, in the same manner as a legitimate group member.
</t> </t>
<t> <t>
TLS 1.3 <xref target="RFC8446"/> takes a conservative approach to PSKs;
TLS 1.3 <xref target="RFC8446" format="default"/> takes a conservative a
pproach to PSKs;
they are bound to a specific hash function and KDF. By contrast, they are bound to a specific hash function and KDF. By contrast,
TLS 1.2 <xref target="RFC5246"/> allows PSKs to be used with any hash TLS 1.2 <xref target="RFC5246" format="default"/> allows PSKs to be used with any hash
function and the TLS 1.2 PRF. Thus, the safest approach is to use a PSK function and the TLS 1.2 PRF. Thus, the safest approach is to use a PSK
exclusively with TLS 1.2 or exclusively with TLS 1.3. Given one PSK, exclusively with TLS 1.2 or exclusively with TLS 1.3. Given one PSK,
one can derive a PSK for exclusive use with TLS 1.2 and derive another one can derive a PSK for exclusive use with TLS 1.2 and derive another
PSK for exclusive use with TLS 1.3 using the mechanism specified in PSK for exclusive use with TLS 1.3 using the mechanism specified in
<xref target="I-D.ietf-tls-external-psk-importer"/>. <xref target="I-D.ietf-tls-external-psk-importer" format="default"/>.
</t> </t>
<t> <t>
TLS 1.3 <xref target="RFC8446"/> has received careful security analysis, TLS 1.3 <xref target="RFC8446" format="default"/> has received careful s ecurity analysis,
and the following informal reasoning shows that the addition of this and the following informal reasoning shows that the addition of this
extension does not introduce any security defects. This extension extension does not introduce any security defects. This extension
requires the use of certificates for authentication, but the processing requires the use of certificates for authentication, but the processing
of certificates is unchanged by this extension. This extension places of certificates is unchanged by this extension. This extension places
an external PSK in the key schedule as part of the computation of the an external PSK in the key schedule as part of the computation of the
Early Secret. In the initial handshake without this extension, the Early Secret. In the initial handshake without this extension, the
Early Secret is computed as: Early Secret is computed as:
<figure> </t>
<artwork>
<![CDATA[ Early Secret = HKDF-Extract(0, 0)]]> <sourcecode>
</artwork> Early Secret = HKDF-Extract(0, 0)
</figure> </sourcecode>
<t>
With this extension, the Early Secret is computed as: With this extension, the Early Secret is computed as:
<figure> </t>
<artwork>
<![CDATA[ Early Secret = HKDF-Extract(External PSK, 0)]]> <sourcecode>
</artwork> Early Secret = HKDF-Extract(External PSK, 0)
</figure> </sourcecode>
<t>
Any entropy contributed by the external PSK can only make the Early Any entropy contributed by the external PSK can only make the Early
Secret better; the External PSK cannot make it worse. For these two Secret better; the External PSK cannot make it worse. For these two
reasons, TLS 1.3 continues to meet its security goals when this extensio n reasons, TLS 1.3 continues to meet its security goals when this extensio n
is used. is used.
</t> </t>
</section> </section>
<section anchor="privacy" numbered="true" toc="default">
<section title="Privacy Considerations" anchor="section-privacy"> <name>Privacy Considerations</name>
<t> <t>
Appendix E.6 of <xref target="RFC8446"/> discusses identity exposure <xref target="RFC8446" sectionFormat="of" section="E.6"/> discusses iden tity-exposure
attacks on PSKs. The guidance in this section remains relevant. attacks on PSKs. The guidance in this section remains relevant.
</t> </t>
<t> <t>
This extension makes use of external PSKs to improve resilience against This extension makes use of external PSKs to improve resilience against
attackers that gain access to a large-scale quantum computer in the attackers that gain access to a large-scale quantum computer in the
future. This extension is always accompanied by the "pre_shared_key" future. This extension is always accompanied by the "pre_shared_key"
extension to provide the PSK identities in plaintext in the ClientHello extension to provide the PSK identities in plaintext in the ClientHello
message. Passive observation of the these PSK identities will aid an message. Passive observation of the these PSK identities will aid an
attacker to track users of this extension. attacker in tracking users of this extension.
</t> </t>
</section> </section>
</middle>
<back>
<displayreference target="I-D.hoffman-c2pq" to="TRANSITION" />
<displayreference target="I-D.ietf-tls-external-psk-importer" to="IMPORT" />
<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.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8446.xml"/>
</references>
<references>
<name>Informative References</name>
<section title="Acknowledgments" anchor="section-acks"> <!-- draft-hoffman-c2pq-06 exists -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
rence.I-D.hoffman-c2pq.xml"/>
<reference anchor="DH1976" target="https://ieeexplore.ieee.org/document/
1055638">
<front>
<title>New Directions in Cryptography</title>
<author initials="W" surname="Diffie" fullname="Whitfield Diffie"/>
<author initials="M" surname="Hellman" fullname="Martin Hellman"/>
<date month="November" year="1976"/>
</front>
<refcontent>IEEE Transactions on Information Theory</refcontent>
<refcontent>Vol. 22, No. 6</refcontent>
<seriesInfo name="DOI" value="10.1109/TIT.1976.1055638"/>
</reference>
<reference anchor="GGM1986">
<front>
<title>How to construct random functions</title>
<author initials="O" surname="Goldreich" fullname="Oded Goldreich"/>
<author initials="S" surname="Goldwasser" fullname="Shafi Goldwasser
"/>
<author initials="S" surname="Micali" fullname="Silvio Micali"/>
<date year="1986" month="August"/>
</front>
<refcontent>Journal of the ACM</refcontent>
<refcontent>Vol. 33, No. 4</refcontent>
<refcontent>pp. 792-807</refcontent>
<seriesInfo name="DOI" value="10.1145/6490.6503"/>
</reference>
<reference anchor="FIPS186">
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>NIST</organization>
</author>
<date year="2013" month="July"/>
</front>
<seriesInfo name="Federal Information Processing Standards Publicati
on (FIPS)" value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
</reference>
<reference anchor="IANA" target="https://www.iana.org/assignments/tls-ex
tensiontype-values/tls-extensiontype-values.xhtml">
<front>
<title>TLS ExtensionType Values</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<reference anchor="IEEE1363" target="https://ieeexplore.ieee.org/documen
t/891000">
<front>
<title>IEEE Standard Specifications for Public-Key Cryptography</tit
le>
<author>
<organization>IEEE</organization>
</author>
<date year="2000" month="August"/>
</front>
<seriesInfo name="IEEE Std" value="1363-2000"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2000.92292"/>
</reference>
<!-- draft-ietf-tls-external-psk-importer-03 exists -->
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D
.ietf-tls-external-psk-importer.xml"/>
<reference anchor="K2016" target="https://dl.acm.org/doi/10.1145/2976749
.2978325">
<front>
<title>A Unilateral-to-Mutual Authentication Compiler for Key
Exchange (with Applications to Client Authentication in TLS
1.3)</title>
<author initials="H" surname="Krawczyk" fullname="Hugo Krawczyk"/>
<date month="October" year="2016"/>
</front>
<refcontent>CCS '16: Proceedings of the 2016 ACM Communications Secu
rity</refcontent>
<refcontent>pp. 1438-50</refcontent>
<seriesInfo name="DOI" value="10.1145/2976749.2978325"/>
</reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2104.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5246.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8017.xml"/>
</references>
</references>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgments</name>
<t> <t>
Many thanks to Many thanks to
Liliya Akhmetzyanova, <contact fullname="Liliya Akhmetzyanova"/>,
Roman Danyliw, <contact fullname="Roman Danyliw"/>,
Christian Huitema, <contact fullname="Christian Huitema"/>,
Ben Kaduk, <contact fullname="Ben Kaduk"/>,
Geoffrey Keating, <contact fullname="Geoffrey Keating"/>,
Hugo Krawczyk, <contact fullname="Hugo Krawczyk"/>,
Mirja Kühlewind, <contact fullname="Mirja Kühlewind"/>,
Nikos Mavrogiannopoulos, <contact fullname="Nikos Mavrogiannopoulos"/>,
Nick Sullivan, <contact fullname="Nick Sullivan"/>,
Martin Thomson, and <contact fullname="Martin Thomson"/>, and
Peter Yee <contact fullname="Peter Yee"/>
for their review and comments; their efforts have improved this document . for their review and comments; their efforts have improved this document .
</t> </t>
</section> </section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC8174;
&RFC8446;
</references>
<references title="Informative References">
&C2PQ;
<reference anchor="DH1977">
<front>
<title>New Directions in Cryptography</title>
<author initials="W" surname="Diffie" fullname="Whitfield Diffie"/>
<author initials="M" surname="Hellman" fullname="Martin Hellman"/>
<date month="June" year="1977" />
</front>
<seriesInfo name="IEEE Transactions on Information Theory" value="V.IT-2
2 n.6"/>
</reference>
<reference anchor="GGM1986">
<front>
<title>How to construct random functions</title>
<author initials="O" surname="Goldreich" fullname="Oded Goldreich"/>
<author initials="S" surname="Goldwasser" fullname="Shafi Goldwasser"/
>
<author initials="S" surname="Micali" fullname="Silvio Micali"/>
<date year="1986" />
</front>
<seriesInfo name="J. ACM" value="1986 (33), pp. 792-807"/>
</reference>
<reference anchor="FIPS186">
<front>
<title>Digital Signature Standard (DSS)</title>
<author><organization>National Institute of Standards and Technology</
organization></author>
<date year="2013" month="July" />
</front>
<seriesInfo name="Federal Information Processing Standards Publication (
FIPS PUB)" value="186-4"/>
</reference>
<reference anchor="IANA" target="https://www.iana.org/assignments/tls-exte
nsiontype-values/tls-extensiontype-values.xhtml">
<front>
<title>IANA Registry for TLS ExtensionType Values</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="IEEE1363">
<front>
<title>IEEE Standard Specifications for Public-Key Cryptography</title
>
<author><organization>Institute of Electrical and Electronics Engineer
s</organization></author>
<date year="2000" />
</front>
<seriesInfo name="IEEE Std" value="1363-2000"/>
</reference>
&IMPORTER;
<reference anchor="K2016">
<front>
<title>A Unilateral-to-Mutual Authentication Compiler for Key Exchange
(with Applications to Client Authentication in TLS 1.3)</title>
<author initials="H" surname="Krawczyk" fullname="Hugo Krawczyk"/>
<date day="10" month="August" year="2016" />
</front>
<seriesInfo name="IACR ePrint" value="2016/711"/>
</reference>
&RFC2104;
&RFC4086;
&RFC5246;
&RFC8017;
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 89 change blocks. 
312 lines changed or deleted 363 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/