rfc9963.original.xml   rfc9963.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
4) --> -ietf-tls-tls13-pkcs1-07" number="9963" updates="" obsoletes="" xml:lang="en" ca
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft tegory="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="
-ietf-tls-tls13-pkcs1-07" category="std" consensus="true" submissionType="IETF" true" symRefs="true" version="3">
tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.31.0 -->
<front> <front>
<title abbrev="Legacy PKCS#1 codepoints for TLS 1.3">Legacy RSASSA-PKCS1-v1_ <title abbrev="Legacy PKCS #1 Code Points for TLS 1.3">Legacy RSASSA-PKCS1-v
5 codepoints for TLS 1.3</title> 1_5 Code Points for TLS 1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-tls13-pkcs1-07"/> <seriesInfo name="RFC" value="9963"/>
<author initials="D." surname="Benjamin" fullname="David Benjamin"> <author initials="D." surname="Benjamin" fullname="David Benjamin">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>davidben@google.com</email> <email>davidben@google.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Popov" fullname="Andrei Popov"> <author initials="A." surname="Popov" fullname="Andrei Popov">
<organization>Microsoft Corp.</organization> <organization>Microsoft Corp.</organization>
<address> <address>
<email>andreipo@microsoft.com</email> <email>andreipo@microsoft.com</email>
</address> </address>
</author> </author>
<date year="2025" month="December" day="02"/> <date year="2026" month="April"/>
<area>Security</area>
<workgroup>Transport Layer Security</workgroup> <area>SEC</area>
<abstract> <workgroup>tls</workgroup>
<?line 76?>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract>
<t>This document allocates code points for the use of RSASSA-PKCS1-v1_5 with <t>This document allocates code points for the use of RSASSA-PKCS1-v1_5 with
client certificates in TLS 1.3. This removes an obstacle for some deployments client certificates in TLS 1.3. This removes an obstacle for some deployments
to migrate to TLS 1.3.</t> to migrate to TLS 1.3.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
tlswg.github.io/tls13-pkcs1/draft-ietf-tls-tls13-pkcs1.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/"/>.
</t>
<t>
Discussion of this document takes place on the
Transport Layer Security Working Group mailing list (<eref target="mailt
o:tls@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/tls/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/tls/"/>
.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/tlswg/tls13-pkcs1"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 82?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>TLS 1.3 <xref target="RFC8446"/> removed support for RSASSA-PKCS1-v1_5 <xref target="RFC8017"/> in <t>TLS 1.3 <xref target="RFC8446"/> removed support for RSASSA-PKCS1-v1_5 <xref target="RFC8017"/> in
CertificateVerify messages in favor of RSASSA-PSS. While RSASSA-PSS is a CertificateVerify messages in favor of RSASSA-PSS. While RSASSA-PSS is a
long-established signature algorithm, some legacy hardware cryptographic devices long-established signature algorithm, some legacy hardware cryptographic devices
lack support for it. While uncommon in TLS servers, these devices are sometimes lack support for it. While uncommon in TLS servers, these devices are sometimes
used by TLS clients for client certificates.</t> used by TLS clients for client certificates.</t>
<t>For example, Trusted Platform Modules (TPMs) are ubiquitous hardware <t>For example, Trusted Platform Modules (TPMs) are ubiquitous hardware
cryptographic devices that are often used to protect TLS client certificate cryptographic devices that are often used to protect TLS client certificate
private keys. However, a large number of TPMs are unable to produce RSASSA-PSS private keys. However, a large number of TPMs are unable to produce RSASSA-PSS
signatures compatible with TLS 1.3. TPM specifications prior to 2.0 did not signatures compatible with TLS 1.3. TPM specifications prior to 2.0 did not
define RSASSA-PSS support (see Section 5.8.1 of <xref target="TPM12"/>). TPM 2.0 define RSASSA-PSS support (see Section 5.8.1 of <xref target="TPM12"/>). TPM 2.0
includes RSASSA-PSS, but only those TPM 2.0 devices compatible with US FIPS includes RSASSA-PSS, but only those TPM 2.0 devices compatible with US FIPS
186-4 can be relied upon to use the salt length matching the digest length, as 186-4 can be relied upon to use the salt length matching the digest length, as
required for compatibility with TLS 1.3 (see Appendix B.7 of <xref target="TPM2" />).</t> required for compatibility with TLS 1.3 (see Appendix B.7 of <xref target="TPM2" />).</t>
<t>TLS connections that rely on such devices cannot migrate to TLS 1.3. St aying on <t>TLS connections that rely on such devices cannot migrate to TLS 1.3. St aying on
TLS 1.2 leaks the client certificate to network attackers TLS 1.2 leaks the client certificate to network attackers
<xref target="PRIVACY"/> and additionally prevents such <xref target="PRIVACY"/> and additionally prevents such
deployments from protecting traffic against retroactive decryption by an deployments from protecting traffic against retroactive decryption by an
attacker with a quantum computer <xref target="I-D.ietf-tls-hybrid-design"/>.</t > attacker with a quantum computer <xref target="RFC9954"/>.</t>
<t>Additionally, TLS negotiates protocol versions before client certificat es. <t>Additionally, TLS negotiates protocol versions before client certificat es.
Clients send ClientHellos without knowing whether the server will request to Clients send ClientHellos without knowing whether the server will request to
authenticate with legacy keys. Conversely, servers respond with a TLS authenticate with legacy keys. Conversely, servers respond with a TLS
version and CertificateRequest without knowing if the client will then version and CertificateRequest without knowing if the client will then
respond with a legacy key. If the client and server, respectively, offer and respond with a legacy key. If the client and server, respectively, offer and
negotiate TLS 1.3, the connection will fail due to the legacy key, when it negotiate TLS 1.3, the connection will fail due to the legacy key, when it
previously succeeded at TLS 1.2.</t> previously succeeded at TLS 1.2.</t>
<t>To recover from this failure, one side must globally disable TLS 1.3 or the <t>To recover from this failure, one side must globally disable TLS 1.3 or the
client must implement an external fallback. Disabling TLS 1.3 impacts client must implement an external fallback. Disabling TLS 1.3 impacts
connections that would otherwise be unaffected by this issue, while external connections that would otherwise be unaffected by this issue, while external
fallbacks break TLS's security analysis and may introduce vulnerabilities fallbacks break TLS's security analysis and may introduce vulnerabilities
<xref target="POODLE"/>.</t> <xref target="POODLE"/>.</t>
<t>This document allocates code points to use these legacy keys with clien t <t>This document allocates code points to use these legacy keys with clien t
certificates in TLS 1.3. This reduces the pressure on implementations to select certificates in TLS 1.3. This reduces the pressure on implementations to select
one of these problematic mitigations and unblocks TLS 1.3 deployment.</t> one of these problematic mitigations and unblocks TLS 1.3 deployment.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>
OULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
xref target="RFC8174"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
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="pkcs1-v15-signaturescheme-types"> <section anchor="pkcs1-v15-signaturescheme-types">
<name>PKCS#1 v1.5 SignatureScheme Types</name> <name>PKCS#1 v1.5 SignatureScheme Types</name>
<t>The following SignatureScheme values are defined for use with TLS 1.3.< /t> <t>The following SignatureScheme values are defined for use with TLS 1.3.< /t>
<artwork><![CDATA[ <artwork><![CDATA[
enum { enum {
rsa_pkcs1_sha256_legacy(0x0420), rsa_pkcs1_sha256_legacy(0x0420),
rsa_pkcs1_sha384_legacy(0x0520), rsa_pkcs1_sha384_legacy(0x0520),
rsa_pkcs1_sha512_legacy(0x0620), rsa_pkcs1_sha512_legacy(0x0620),
} SignatureScheme; } SignatureScheme;]]></artwork>
]]></artwork>
<t>The above code points indicate a signature algorithm using RSASSA-PKCS1 -v1_5 <t>The above code points indicate a signature algorithm using RSASSA-PKCS1 -v1_5
<xref target="RFC8017"/> with the corresponding hash algorithm as defined in <xref target="RFC8017"/> with the corresponding hash algorithm as defined in
<xref target="SHS"/>. They are only defined for signatures in <xref target="SHS"/>. They are only defined for signatures in
the client CertificateVerify message and are not defined for use in other the client CertificateVerify message and are not defined for use in other
contexts. In particular, servers intending to advertise support for contexts. In particular, servers that intend to advertise support for
RSASSA-PKCS1-v1_5 signatures in the certificates themselves should use the RSASSA-PKCS1-v1_5 signatures in the certificates themselves should use the
<tt>rsa_pkcs1_*</tt> constants defined in <xref target="RFC8446"/>.</t> <tt>rsa_pkcs1_*</tt> constants defined in <xref target="RFC8446"/>.</t>
<t>Clients MUST NOT advertise these values in the <tt>signature_algorithms <t>Clients <bcp14>MUST NOT</bcp14> advertise these values in the <tt>signa
</tt> extension ture_algorithms</tt> extension
of the ClientHello. They MUST NOT accept these values in the server of the ClientHello. They <bcp14>MUST NOT</bcp14> accept these values in the serv
er
CertificateVerify message.</t> CertificateVerify message.</t>
<t>Servers that wish to support clients authenticating with legacy <t>Servers that wish to support clients authenticating with legacy
RSASSA-PKCS1-v1_5-only keys MAY send these values in the RSASSA-PKCS1-v1_5-only keys <bcp14>MAY</bcp14> send these values in the
<tt>signature_algorithms</tt> extension of the CertificateRequest message and ac cept <tt>signature_algorithms</tt> extension of the CertificateRequest message and ac cept
them in the client CertificateVerify message. Servers MUST NOT accept these code them in the client CertificateVerify message. Servers <bcp14>MUST NOT</bcp14> ac cept these code
points if not offered in the CertificateRequest message.</t> points if not offered in the CertificateRequest message.</t>
<t>Clients with such legacy keys MAY negotiate the use of these signature <!-- [rfced] Please clarify whether "them" refers to the "legacy keys" or "signa
algorithms if offered by the server. Clients SHOULD NOT negotiate them with ture algorithms". May we update the text as follows?
Original (the full paragraph included for context):
Clients with such legacy keys MAY negotiate the use of these
signature algorithms if offered by the server. Clients SHOULD NOT
negotiate them with keys that support RSASSA-PSS, though this may not
be practical to determine in all applications. For example,
attempting to test a key for support might display a message to the
user or have other side effects.
Perhaps:
... Clients with such legacy keys MAY negotiate the use of these
signature algorithms if offered by the server. Clients SHOULD NOT
negotiate the use of these signature algorithms with keys that support RSASSA
-PSS, though it may not
be practical to determine which keys support RSASSA-PSS in all applications.
In addition, please clarify "display" in the last sentence - we wonder whethe
r "might result in" or "might expose" might be more clear.
-->
<t>Clients with such legacy keys <bcp14>MAY</bcp14> negotiate the use of these s
ignature
algorithms if offered by the server. Clients <bcp14>SHOULD NOT</bcp14> negotiat
e them with
keys that support RSASSA-PSS, though this may not be practical to determine in keys that support RSASSA-PSS, though this may not be practical to determine in
all applications. For example, attempting to test a key for support might all applications. For example, attempting to test a key for support might
display a message to the user or have other side effects.</t> display a message to the user or have other side effects.</t>
<t>TLS implementations SHOULD disable these code points by default. See <t>TLS implementations <bcp14>SHOULD</bcp14> disable these code points by default. See
<xref target="security-considerations"/>.</t> <xref target="security-considerations"/>.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The considerations in <xref target="introduction"/> do not apply to ser ver keys, so these new <t>The considerations in <xref target="introduction"/> do not apply to ser ver keys, so these new
code points are forbidden for use with server certificates. RSASSA-PSS continues code points are forbidden for use with server certificates. RSASSA-PSS continues
to be required for TLS 1.3 servers using RSA keys. This minimizes the impact to to be required for TLS 1.3 servers using RSA keys. This minimizes the impact to
only those cases necessary to unblock TLS 1.3 deployment.</t> only those cases in which it is necessary to unblock deployment of TLS 1.3.</t>
<t>When implemented incorrectly, RSASSA-PKCS1-v1_5 admits signature <t>When implemented incorrectly, RSASSA-PKCS1-v1_5 admits signature
forgeries <xref target="MFSA201473"/>. Implementations producing or verifying si gnatures forgeries <xref target="MFSA201473"/>. Implementations producing or verifying si gnatures
with these algorithms MUST implement RSASSA-PKCS1-v1_5 as specified in section with these algorithms <bcp14>MUST</bcp14> implement RSASSA-PKCS1-v1_5 as specifi
8.2 of <xref target="RFC8017"/>. In particular, clients MUST include the mandato ed in <xref target="RFC8017" section="8.2"/>. In particular, clients <bcp14>MUST
ry NULL </bcp14> include the mandatory NULL
parameter in the DigestInfo structure and produce a valid DER <xref target="X690 "/> parameter in the DigestInfo structure and produce a valid DER <xref target="X690 "/>
encoding. Servers MUST reject signatures which do not meet these requirements.</ t> encoding. Servers <bcp14>MUST</bcp14> reject signatures which do not meet these requirements.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to create the following entries in the <t>IANA has created the following entries in the
TLS SignatureScheme registry. The "Recommended" column "TLS SignatureScheme" registry. The "Recommended" column
should be set to "N", and the "Reference" column should be set to this document. has been set to "N", and the "Reference" column refers to this document.</t>
</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Description</th> <th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0420</td> <td align="left">0x0420</td>
skipping to change at line 178 skipping to change at line 188
<tr> <tr>
<td align="left">0x0620</td> <td align="left">0x0620</td>
<td align="left"> <td align="left">
<tt>rsa_pkcs1_sha512_legacy</tt></td> <tt>rsa_pkcs1_sha512_legacy</tt></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
le> 017.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="March" year="1997"/> 446.xml"/>
<abstract>
<t>In many standards track documents several words are used to sig <reference anchor="X690" target="https://www.itu.int/rec/T-REC-X.690">
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8017">
<front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname="
Moriarty"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
<author fullname="A. Rusch" initials="A." surname="Rusch"/>
<date month="November" year="2016"/>
<abstract>
<t>This document provides recommendations for the implementation o
f public-key cryptography based on the RSA algorithm, covering cryptographic pri
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f
or representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from R
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing
this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 3447.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8017"/>
<seriesInfo name="DOI" value="10.17487/RFC8017"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="X690">
<front> <front>
<title>Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2002"/> <date year="2021" month="February"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="8825-1:2002"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="ISO/IEC" value="8825-1:2021"/>
</reference> </reference>
<reference anchor="TPM12" target="https://trustedcomputinggroup.org/wp-c ontent/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf"> <reference anchor="TPM12" target="https://trustedcomputinggroup.org/wp-c ontent/uploads/TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf">
<front> <front>
<title>TPM Main Specification Level 2 Version 1.2, Revision 116, Par t 2 - Structures of the TPM</title> <title>TPM Main, Part 2 - Structures of the TPM</title>
<author> <author>
<organization>Trusted Computing Group</organization> <organization>Trusted Computing Group</organization>
</author> </author>
<date year="2011" month="March" day="01"/> <date year="2011" month="March" day="01"/>
</front> </front>
<refcontent>Level 2, Version 1.2, Revision 116</refcontent>
</reference> </reference>
<reference anchor="TPM2" target="https://trustedcomputinggroup.org/wp-co ntent/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf"> <reference anchor="TPM2" target="https://trustedcomputinggroup.org/wp-co ntent/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf">
<front> <front>
<title>Trusted Platform Module Library Specification, Family 2.0, Le vel 00, Revision 01.59, Part 1: Architecture</title> <title>Trusted Platform Module Library, Part 1: Architecture</title>
<author> <author>
<organization>Trusted Computing Group</organization> <organization>Trusted Computing Group</organization>
</author> </author>
<date year="2019" month="November" day="08"/> <date year="2019" month="November" day="08"/>
</front> </front>
<refcontent>Family 2.0, Level 00, Revision 01.59</refcontent>
</reference> </reference>
<reference anchor="RFC8174"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 174.xml"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle> <reference anchor="SHS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/N
<author fullname="B. Leiba" initials="B." surname="Leiba"/> IST.FIPS.180-4.pdf">
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="SHS">
<front> <front>
<title>Secure hash standard</title> <title>Secure Hash Standard</title>
<author> <author>
<organization/> <organization abbrev="NIST">National Institute of Standards and Te chnology</organization>
</author> </author>
<date year="2015"/> <date month="August" year="2015"/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/nist.fips.180-4"/> <seriesInfo name="NIST FIPS" value="180-4"/>
<refcontent>National Institute of Standards and Technology (U.S.)</ref <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
content>
</reference> </reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="MFSA201473" target="https://www.mozilla.org/en-US/sec urity/advisories/mfsa2014-73/"> <reference anchor="MFSA201473" target="https://www.mozilla.org/en-US/sec urity/advisories/mfsa2014-73/">
<front> <front>
<title>RSA Signature Forgery in NSS</title> <title>Mozilla Foundation Security Advisory 2014-73: RSA Signature F orgery in NSS</title>
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine De lignat-Lavaud"> <author initials="A." surname="Delignat-Lavaud" fullname="Antoine De lignat-Lavaud">
<organization/> <organization/>
</author> </author>
<date year="2014" month="September" day="23"/> <date year="2014" month="September" day="24"/>
</front> </front>
</reference> </reference>
<reference anchor="POODLE" target="https://security.googleblog.com/2014/ 10/this-poodle-bites-exploiting-ssl-30.html"> <reference anchor="POODLE" target="https://security.googleblog.com/2014/ 10/this-poodle-bites-exploiting-ssl-30.html">
<front> <front>
<title>This POODLE bites: exploiting the SSL 3.0 fallback</title> <title>This POODLE bites: exploiting the SSL 3.0 fallback</title>
<author initials="B." surname="Moeller" fullname="Bodo Moeller"> <author initials="B." surname="Moeller" fullname="Bodo Moeller">
<organization/> <organization/>
</author> </author>
<date year="2014" month="October" day="14"/> <date year="2014" month="October" day="14"/>
</front> </front>
<refcontent>Google Security Blog</refcontent>
</reference> </reference>
<reference anchor="PRIVACY"> <reference anchor="PRIVACY">
<front> <front>
<title>Push away your privacy: Precise user tracking based on TLS cl ient certificate authentication</title> <title>Push away your privacy: Precise user tracking based on TLS cl ient certificate authentication</title>
<author fullname="Matthias Wachs" initials="M." surname="Wachs"> <author fullname="Matthias Wachs" initials="M." surname="Wachs">
<organization/> <organization/>
</author> </author>
<author fullname="Quirin Scheitle" initials="Q." surname="Scheitle"> <author fullname="Quirin Scheitle" initials="Q." surname="Scheitle">
<organization/> <organization/>
</author> </author>
<author fullname="Georg Carle" initials="G." surname="Carle"> <author fullname="Georg Carle" initials="G." surname="Carle">
<organization/> <organization/>
</author> </author>
<date month="June" year="2017"/> <date month="June" year="2017"/>
</front> </front>
<seriesInfo name="2017 Network Traffic Measurement and Analysis Confer ence (TMA)" value="pp. 1-9"/> <refcontent>2017 Network Traffic Measurement and Analysis Conference ( TMA). pp. 1-9</refcontent>
<seriesInfo name="DOI" value="10.23919/tma.2017.8002897"/> <seriesInfo name="DOI" value="10.23919/tma.2017.8002897"/>
<refcontent>IEEE</refcontent>
</reference> </reference>
<reference anchor="I-D.ietf-tls-hybrid-design"> <!-- [rfced] draft-ietf-tls-hybrid-design is currently in AUTH48 as RFC-to-be 99
<front> 54. We have updated the reference to point to RFC 9954, in hopes it will comple
<title>Hybrid key exchange in TLS 1.3</title> te AUTH48 around the same time as this document.
<author fullname="Douglas Stebila" initials="D." surname="Stebila"> -->
<organization>University of Waterloo</organization> <reference anchor="RFC9954" target="https://www.rfc-editor.org/info/rfc9954">
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
</author>
<author fullname="Shay Gueron" initials="S." surname="Gueron">
<organization>University of Haifa and Meta</organization>
</author>
<date day="7" month="September" year="2025"/>
<abstract>
<t> Hybrid key exchange refers to using multiple key exchange al
gorithms
simultaneously and combining the result with the goal of providing
security even if a way is found to defeat the encryption for all but
one of the component algorithms. It is motivated by transition to
post-quantum cryptography. This document provides a construction for
hybrid key exchange in the Transport Layer Security (TLS) protocol
version 1.3.
</t> <front>
</abstract> <title>Hybrid Key Exchange in TLS 1.3</title>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-hybrid-design- <author initials="D." surname="Stebila" fullname="Douglas Stebila">
16"/> <organization />
</reference> </author>
<author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
<organization />
</author>
<author initials="S." surname="Gueron" fullname="Shay Gueron">
<organization />
</author>
<date month="April" year="2026" />
</front>
<seriesInfo name="RFC" value="9954" />
<seriesInfo name="DOI" value="10.17487/RFC9954"/>
</reference>
<!--
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-tls-hybrid-design.xml"/>
-->
</references> </references>
</references> </references>
<?line 200?>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Thanks to Rifaat Shekh-Yusef, Martin Thomson, and Paul Wouters for prov iding feedback on this document.</t> <t>Thanks to <contact fullname="Rifaat Shekh-Yusef"/>, <contact fullname=" Martin Thomson"/>, and <contact fullname="Paul Wouters"/> for providing feedback on this document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA71Za3PjthX9jl+BKh+a7YjUw4+13ek08mOzmvpVy5ttZjrj
hUhIQkwSDEHKq3jd395zAVCkZDnpp3omWYkELu7z3HOhIAhYqcpEnvDOpZyL
aMXvJqPJZBTc/uNsMgiWg4cDHulY5lplpeEzXfD7ywkfhHsdJqbTQi6bnbTl
u8GbyyNRyrkuVifclDFjsY4ykeLguBCzMlCynAVlYui/wV6QP0ZmEPTfM1NN
U2WM0lm5yrF6fHH/gfPvuEiMxtEqw2ES/8vKTpd3ZKxKXSiR0Jfx6BT/QIXO
+O7+Q4dlVTqVxQmLocgJi3RmZGYqc8LLopIMhuwxUUgBqRMZVYUqVx32pIvH
eaGrHE/vC5GZXBclvxQrWfBm1VJmFURy/sdLOXd2dD5Dssrm/EfaQs9ToRI8
h/0/kDNCXczpsSiiBR4vyjI3J70eraJHainDelmPHvSmhX4ysof9Pdo3V+Wi
mjqBT/Ney630NoEPTNmSa1eFblOodHt97+0IhYsyTTqMiapcaLiWB5DNucrg
1c55yE9l9otIVdaxj128O+diqeKtV7BCZOo3USLQWPKj1vNE8svLM/daOufE
tHMqsx/m9n0Y6XTzyFHIb3WulxvnjbK4kKr9Yuu0KxUV2uhZyc90kYcbRwq7
Odc/pPUieyrLdJFi/9KG/e7D2XAwOPYfj/qD9/XH/f1D+vivw+P+iRVbV9s4
mzkJOuOljBaZTvR8xQM+mlyHAy4zlBGlx12VSFg2yWWkZipyG/SMnwqjIn6x
sYx/f3px967Lz0SmM6xNXr0/w3syiZ8rU+J5pcxCxq+WnWOZ84KtFT7s94f2
6zrO3LsRBXn/Kbi3D4wslDQKhtULxpOb3vji7IQfHQ0PgsGJl3N/ezUYbroD
j/iVUNmWoZdyKRM+5D/JgiAAQDLs8ju5VO7b4LDLbwWqbAjHTVDGUVkVMAD+
KReSztm0YgBI2Qv6g7dsuS8qU8IfZzrNq3JdnU5TUcwlKmZdMG5tVC+1pW+r
8SkPAC4lIKlX5YkWselBk4DMC0jbYBjQ90bfhyXsegCWwqCH/qC/R5qGeTxz
vtp2lVfyFjVMOcSvdFxRsahpIYrVpge7/AOKLFnxYdjvenf2+y0f9gfhwbH3
4uCEjwhakI+k15bvjgNy39H/33dnPz6QFx6KQX5w/ECaDh7aej7kgCzyFlN1
UbmyvPowGUHx/fd7mx5Ei+MTNc8E7eYfcK6E35B815NJZ4d9a2w5l4ndFlyK
pajijn+/xpkSbU/uXrV2437QPw6Gezv98vT0FKb6N5UkwnpDZsGnSc/45tET
MYKmqch66cwIK+z9Xg+ibm9uzi8vtvJkoYx/wafwFWyQX+FTZYND9TGZXPK9
sM9nIkmmInp82/bTEFkmk0QWWzaf6lhvvmoZOugHg/2dhtYmhQ7Ip8A+gtUe
besN+r0Suge51nEiA6t70KgeGJMEe33belgYhoyxIAi4mJqyEFHJmDUc9KJK
kUYgCokm6mEsMeEtZkIuqIwktNgiPf8G63lCK2RRokhGJIvSlRTEIE88pwm5
PaqQqV7ihQAwQwkRoRhJvtGp5KAniV6RJoaVmqdqXkAKx8daiFM/VTGMZew7
Ps7KAhUdUfnCGLeKPz/7dvLy4g+MualyyzHosB0WuC1oRtiiMnbWGAE4VbMV
T6UxYu5MmoklpLRcMZmE/PNCwZbmCYe1giUaQQB7ENPEtQ+zriWRgOHBcWnX
WZ84ZrgQRfwEbsWjYpWXGi7IF+heMUAokoYlyL0NY1RZn12hM6UpcMp7HT1m
iV7QpeAZWUvgJJsOLBVsYghqzKcru8FF0AV8RzThfdQ/CkOkeSK7/A1wRU8E
BJl39qBqqn6twDMrszaM7TQMSorSbgFtkBm3eiHyeaEJulr6tXVieaGWlCOP
cmVC/lE/AbWLLhcgbagi7mgshYpUchpliIX0opE67ZixdXSoAtIc6EhrKb1b
eYz2a9p9w0CSohrR1Dl4DMKW6ZLFckYI18qIOmzfGymJ5tq2fRAegcNAw+dn
2+tfXt65MyALIB0lVQxtGildPq1KrjP0KWCPkfXatSO3Ff804R/GtxM2ODoM
9nmEyptKlAV8GfMqJ0qlbWlTiRuRlEjEbI596A3oGx7+YoXcr1/Bv4YVEoEt
IMNmiz9TJQCqDX85Y0c5DR7qKz8N369ttaa6qkUfy5w/fCJAvxWMhMuiRWOZ
yODYXbgAQiNWpCtgwD0bQlfxaKzyr/OG9maypImFixIw9IhCYc/Pf7+9G/80
Ovv5b+c343DQD4d7x4Pj3v3VKATavg+PwMmOjgkjiBeKGBMUVAZqrpACyDwq
HtKYtZCMzwqd1mls3YkJAVpwMQfJMWQqMAxgjEYMS21xUF6gJkXGauWcTwX/
tRJZWaXc0QE8h87j4DxcDxyL1bRQcYCcQSq/vMC/o5aaXeuxDLNlqSxAk146
0glfOtZokBwI6C6fof7PPEBgGAR5sV8+op1pY9XTyMvHTD+RkU8LCc+7vuFw
CEuShFPWUCKV2s5BEODiYc3zCOhq+UxnpJMkpT2SYTcGRRztnQFbmNfbBqSF
2nf+nG291KydEVYl0oJtSW40Cfl4Ywud49TpWnWkDRwpqWczWIn3bO3fOj+7
TsI6yd3BMwxNPK5sMtL75tAu+Q84XjJKKwX0RIYhsSIpY1ScKL3gIZWPhh6R
Jg/bTCM6YEUDxaAUEMgo9PIUWM3niZ7abI2VsShYF6nr8HULt2sVgbxjBRkw
H7mGDFrTn5CmImpq8GktBDuQxoa9KuYnXSUx15QQTwpIM7UoDHdFpWs+Vmdl
TCXJcupl9YGsPhCJWaCg6bA/UwI6TgTdRLIy1GoRl1QQMy09rC+rJJOFsJgE
GojqdgTPFsX/wnsaXDTt4Lhk9/nA/ojukCoOhRBKWEgNLmuc6xsIjkKmwx+M
AuZGMkNbNKJEJD0C6pVq7peTsVUGJkh+qd3fYE5I1MjWT9asP6d2ZIHAkPm2
ZSIyRWww1H+a3NMtEP3Lr2/s57uLf34a312c0+fJx9Hl5fpDvWLy8ebTJd4z
/6nZeXZzdXVxfe424ynfenQ1+hn/kFadm9v78c316LJDzqM8YE1UClsayBaE
QxbwH6WLQNykiQo1xRfsOT275YN9R+DoYgHg/Pz8J2Jzg/f7Ly+MKsmdZXum
+wr3InfQlERBMhB/NJdclSIx1Ny4WeinjCNfpfWlv63D6HnQDEOTaIEQ8vtV
Lr1HZxp5ZGFme9FSJJWnXo4WuLZJ6bVBLhj7D/7cnQq4C3/2EwTnhREP9hrp
wSzE8ODwwSXk9/2v/f1h/11398K9o/3WwoO3Fx4Mhq2Fh+uFL9um/NVpaO0V
U8DORskoNHmL52IX0YW99uLkFf1mbfptHeLwsvCwTLsWwixaomwaOE+CryPi
k4+Tumsfokv3rseT+5CITzg46gfIBCpJirqtQMLAViBavA/SWnD/5iDgGABk
ESPZjilSyqIds/P51xLtbJzxHNO4iiow06ajUWY7+5DpmFnpOAhoEXy2Y1rZ
UNf5qg1DeJACTmjOQiIT9nocY1+aoP/lCzUkTCYUt8aV7eEJ6Vh3/BoZWjo6
iPKZ7dX4stbsYR0q88WieUZtmvnbphZ38GFpDkCXy8ud0p3T3h7OoO/E+9X1
HYxcFlq9N+v5psU8LFdpuMcOZwc2WSzuA7Yc9dmhHPsj0+uLth0kZSOlrPmU
guk6tn+QimC/3urdTqQCZXWBzmzCWq7i4v37OrVSwLrJ8vF2LySfNHyndU3g
zl47hTVOISVqBWzzryMbcl4f1nSUTempu2uwR9sY17FtD0hE+eYLxyqIE5DF
U+qmxLLpqhc5EaOZFCkNaCh4wn90g6Qe6EK+MeiChMs0L32V0o8BwDdqnxY6
vAKYShYY+pTJExwp1kH15A5eKYhmLQQg04KD42XS0iDj56BtXuDdUNO1Jp41
4E4tjokqKSkLJICwpkZ0N0gnFE6UrWa0svrXFeIHrdcO0De3ODRQrSsWoHOs
rTvJWytHWyy5p4DQPYZXMZNPrK0mASWcNVVxDF670fq8gI1Boz00E4SqDDnJ
HBfYmDtr7lPD6brB+CHCkjBEWaXqN0/DHEulAaQ1Q0fC4DVYKwWtsIZ5frWb
Xn229LwOli0k262ikiaBHYgtYvA30yqHmb1JBS+Fi5u7V+pS460ccNcUdrgt
aExD5dOXpgewumOaVq/1YNCw+F1Kmfoiw0GBcaydHWF6tkP6uim/6l9Ruy/4
Wwrr3hQgJkoNH15/urxk2CNSKrUaas7tRQL9osNNfalvga++jRGEqwp89eIO
GtCPQSBx9U88W1BXyF/obqjVDjE90IWBS9JUyhoDfdbYidwVwnh0PXpVBPah
5e0WBd0VVITBw2Nbw/AgyEbPoz9lyTbpK+RcwcaV7XCgxZKu5+j317iDrE6q
NGO+PU8JASknwZY9MS7dFkLJLJL1Bv5qQ9keZGDZN/4TtSXOv3FQfuLJ7jph
99839i3wf+sPv/eH9dwxTsj/8gYn/cL9soMdyxpGul52uGNZw0dpmbv2pTGQ
IjeKaJpPZDx38WTPJ+6eT8Z/62BeNLLzQngmskc7Wd2pmUCnmCzk4yL4GcAz
6/IrymVMawudGu3ng1vAKP+s6VrF3YEiJZfKkrMZBm86nma3LY//F7805bkX
IAAA
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 49 change blocks. 
269 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.48.