rfc9954v1.txt		rfc9954.txt
	skipping to change at line 80 ¶		skipping to change at line 80 ¶
	7.2. Informative References		7.2. Informative References
	Appendix A. Related Work		Appendix A. Related Work
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	This document gives a construction for hybrid key exchange in TLS		This document gives a construction for hybrid key exchange in TLS
	1.3. The overall design approach is a simple, "concatenation"-based		1.3. The overall design approach is a simple, "concatenation"-based
	approach: Each hybrid key exchange combination should be viewed as a		approach: Each hybrid key exchange combination should be viewed as a
	single new key exchange method, negotiated and transmitted using the		single new key exchange method that should be negotiated and
	existing TLS 1.3 mechanisms.		transmitted using the existing TLS 1.3 mechanisms.
	This document does not propose specific post-quantum mechanisms; see		This document does not propose specific post-quantum mechanisms; see
	Section 1.3 for more on the scope of this document.		Section 1.3 for more on the scope of this document.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	skipping to change at line 105 ¶		skipping to change at line 105 ¶
	cryptographic algorithms into two classes:		cryptographic algorithms into two classes:
	* "Traditional" algorithms: Algorithms that are widely deployed		* "Traditional" algorithms: Algorithms that are widely deployed
	today but may be deprecated in the future. In the context of TLS		today but may be deprecated in the future. In the context of TLS
	1.3, examples of traditional key exchange algorithms include		1.3, examples of traditional key exchange algorithms include
	Elliptic Curve Diffie-Hellman (ECDH) using secp256r1 or x25519 or		Elliptic Curve Diffie-Hellman (ECDH) using secp256r1 or x25519 or
	finite field Diffie-Hellman.		finite field Diffie-Hellman.
	* "Next-generation" (or "next-gen") algorithms: Algorithms that are		* "Next-generation" (or "next-gen") algorithms: Algorithms that are
	not yet widely deployed but may eventually be widely deployed. An		not yet widely deployed but may eventually be widely deployed. An
	additional facet of these algorithms may be that the cryptographic		additional facet of these algorithms is that the cryptographic
	community has less confidence in their security due to them being		community may have less confidence in their security due to them
	relatively new or less studied. This includes "post-quantum"		being relatively new or less studied. This includes "post-
	algorithms.		quantum" algorithms.
	In this context, "hybrid" key exchange means the use of two (or more)		In this context, "hybrid" key exchange means the use of two (or more)
	key exchange algorithms based on different cryptographic assumptions,		key exchange algorithms based on different cryptographic assumptions,
	e.g., one traditional algorithm and one next-generation algorithm,		e.g., one traditional algorithm and one next-generation algorithm,
	with the purpose of the final session key being secure as long as at		with the purpose of the final session key being secure as long as at
	least one of the component key exchange algorithms remains unbroken.		least one of the component key exchange algorithms remains unbroken.
	When one of the algorithms is traditional and one is post-quantum,		When one of the algorithms is traditional and one is post-quantum,
	this is a Post-Quantum Traditional Hybrid Scheme [PQUIP-TERM]; while		this is a Post-Quantum Traditional Hybrid Scheme [PQUIP-TERM]; while
	this is the initial use case for this document, the document is not		this is the initial use case for this document, the document is not
	limited to this case. This document uses the term "component"		limited to this case. This document uses the term "component"
	skipping to change at line 211 ¶		skipping to change at line 211 ¶
	1.4. Goals		1.4. Goals
	The primary goal of a hybrid key exchange mechanism is to facilitate		The primary goal of a hybrid key exchange mechanism is to facilitate
	the establishment of a shared secret that remains secure as long as		the establishment of a shared secret that remains secure as long as
	one of the component key exchange mechanisms remains unbroken.		one of the component key exchange mechanisms remains unbroken.
	In addition to the primary cryptographic goal, there may be several		In addition to the primary cryptographic goal, there may be several
	additional goals in the context of TLS 1.3:		additional goals in the context of TLS 1.3:
	* *Backwards compatibility*: Clients and servers who are "hybrid-		* Backwards compatibility: Clients and servers who are "hybrid-
	aware", i.e., compliant with whatever hybrid key exchange standard		aware", i.e., compliant with whatever hybrid key exchange standard
	is developed for TLS, should remain compatible with endpoints and		is developed for TLS, should remain compatible with endpoints and
	middleboxes that are not hybrid-aware. The three scenarios to		middleboxes that are not hybrid-aware. The three scenarios to
	consider are:		consider are:
	1. Hybrid-aware client, hybrid-aware server: These parties should		1. Hybrid-aware client, hybrid-aware server: These parties should
	establish a hybrid shared secret.		establish a hybrid shared secret.
	2. Hybrid-aware client, non-hybrid-aware server: These parties		2. Hybrid-aware client, non-hybrid-aware server: These parties
	should establish a non-hybrid shared secret (assuming the		should establish a non-hybrid shared secret (assuming the
	skipping to change at line 233 ¶		skipping to change at line 233 ¶
	only).		only).
	3. Non-hybrid-aware client, hybrid-aware server: These parties		3. Non-hybrid-aware client, hybrid-aware server: These parties
	should establish a non-hybrid shared secret (assuming the		should establish a non-hybrid shared secret (assuming the
	hybrid-aware server is willing to downgrade to non-hybrid-		hybrid-aware server is willing to downgrade to non-hybrid-
	only).		only).
	Ideally, backwards compatibility should be achieved without extra		Ideally, backwards compatibility should be achieved without extra
	round trips and without sending duplicate information; see below.		round trips and without sending duplicate information; see below.
	* *High performance*: Use of hybrid key exchange should not be		* High performance: Use of hybrid key exchange should not be
	prohibitively expensive in terms of computational performance. In		prohibitively expensive in terms of computational performance. In
	general, this will depend on the performance characteristics of		general, this will depend on the performance characteristics of
	the specific cryptographic algorithms used and, as such, is		the specific cryptographic algorithms used and, as such, is
	outside the scope of this document. See [PST] for preliminary		outside the scope of this document. See [PST] for preliminary
	results about performance characteristics.		results about performance characteristics.
	* *Low latency*: Use of hybrid key exchange should not substantially		* Low latency: Use of hybrid key exchange should not substantially
	increase the latency experienced to establish a connection.		increase the latency experienced to establish a connection.
	Factors affecting this may include the following:		Factors affecting this may include the following:
	- The computational performance characteristics of the specific		- The computational performance characteristics of the specific
	algorithms used. See above.		algorithms used. See above.
	- The size of messages to be transmitted. Public key and		- The size of messages to be transmitted. Public key and
	ciphertext sizes for post-quantum algorithms range from		ciphertext sizes for post-quantum algorithms range from
	hundreds of bytes to over one hundred kilobytes, so this impact		hundreds of bytes to over one hundred kilobytes, so this impact
	can be substantial. See [PST] for preliminary results in a		can be substantial. See [PST] for preliminary results in a
	laboratory setting and [LANGLEY] for preliminary results on		laboratory setting and [LANGLEY] for preliminary results on
	more realistic networks.		more realistic networks.
	- Additional round trips added to the protocol. See below.		- Additional round trips added to the protocol. See below.
	* *No extra round trips*: Attempting to negotiate hybrid key		* No extra round trips: Attempting to negotiate hybrid key exchange
	exchange should not lead to extra round trips in any of the three		should not lead to extra round trips in any of the three hybrid-
	hybrid-aware/non-hybrid-aware scenarios listed above.		aware/non-hybrid-aware scenarios listed above.
	* *Minimal duplicate information*: Attempting to negotiate hybrid		* Minimal duplicate information: Attempting to negotiate hybrid key
	key exchange should not mean having to send multiple public keys		exchange should not mean having to send multiple public keys of
	of the same type.		the same type.
	The tolerance for lower performance and increased latency due to use		The tolerance for lower performance and increased latency due to use
	of hybrid key exchange will depend on the context and use case of the		of hybrid key exchange will depend on the context and use case of the
	systems and the network involved.		systems and the network involved.
	2. Key Encapsulation Mechanisms		2. Key Encapsulation Mechanisms
	This document models key agreement as key encapsulation mechanisms		This document models key agreement as key encapsulation mechanisms
	(KEMs), which consist of three algorithms:		(KEMs), which consist of three algorithms:
	skipping to change at line 290 ¶		skipping to change at line 290 ¶
	* Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as		* Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as
	input a secret key sk and ciphertext ct and outputs a shared		input a secret key sk and ciphertext ct and outputs a shared
	secret ss or, in some cases, a distinguished error value.		secret ss or, in some cases, a distinguished error value.
	The main security property for KEMs is indistinguishability under		The main security property for KEMs is indistinguishability under
	adaptive chosen ciphertext attack (IND-CCA2), which means that shared		adaptive chosen ciphertext attack (IND-CCA2), which means that shared
	secret values should be indistinguishable from random strings even		secret values should be indistinguishable from random strings even
	given the ability to have other arbitrary ciphertexts decapsulated.		given the ability to have other arbitrary ciphertexts decapsulated.
	IND-CCA2 corresponds to security against an active attacker, and the		IND-CCA2 corresponds to security against an active attacker, and the
	public key and secret key pair can be treated as a long-term key or		public key and secret key pair can be treated as a long-term key or
	reused (see, for example, [KATZ] or [HHK] for definitions of IND-CCA2		reused. A common design pattern for obtaining security under key
	and IND-CPA security). A common design pattern for obtaining		reuse is to apply the Fujisaki-Okamoto (FO) transform [FO] or a
	security under key reuse is to apply the Fujisaki-Okamoto (FO)		variant thereof [HHK].
	transform [FO] or a variant thereof [HHK].
	A weaker security notion is indistinguishability under chosen		A weaker security notion is indistinguishability under chosen
	plaintext attack (IND-CPA), which means that the shared secret values		plaintext attack (IND-CPA), which means that the shared secret values
	should be indistinguishable from random strings given a copy of the		should be indistinguishable from random strings given a copy of the
	public key. IND-CPA roughly corresponds to security against a		public key. IND-CPA roughly corresponds to security against a
	passive attacker and sometimes corresponds to one-time key exchange.		passive attacker and sometimes corresponds to one-time key exchange.
			See [KATZ] or [HHK] for definitions of IND-CCA2 and IND-CPA security.
	Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key		Key exchange in TLS 1.3 is phrased in terms of Diffie-Hellman key
	exchange in a group. DH key exchange can be modeled as a KEM, with		exchange in a group. DH key exchange can be modeled as a KEM, with
	KeyGen corresponding to selecting an exponent x as the secret key and		(1) KeyGen corresponding to selecting an exponent x as the secret key
	computing the public key g^x, encapsulation corresponding to		and computing the public key g^x, (2) encapsulation corresponding to
	selecting an exponent y and computing the ciphertext g^y and the		selecting an exponent y and computing the ciphertext g^y and the
	shared secret g^(xy), and decapsulation as computing the shared		shared secret g^(xy), and (3) decapsulation corresponding to
	secret g^(xy). See [HPKE] for more details of such Diffie-Hellman-		computing the shared secret g^(xy). See [HPKE] for more details of
	based key encapsulation mechanisms. Diffie-Hellman key exchange,		such Diffie-Hellman-based key encapsulation mechanisms. Diffie-
	when viewed as a KEM, does not formally satisfy IND-CCA2 security but		Hellman key exchange, when viewed as a KEM, does not formally satisfy
	is still safe to use for ephemeral key exchange in TLS 1.3; see, for		IND-CCA2 security but is still safe to use for ephemeral key exchange
	example, [DOWLING].		in TLS 1.3; see, for example, [DOWLING].
	TLS 1.3 does not require that ephemeral public keys be used only in a		TLS 1.3 does not require that ephemeral public keys be used only in a
	single key exchange session; some implementations may reuse them, at		single key exchange session; some implementations may reuse them, at
	the cost of limited forward secrecy. As a result, any KEM used in		the cost of limited forward secrecy. As a result, any KEM used in
	the manner described in this document MUST explicitly be designed to		the manner described in this document MUST explicitly be designed to
	be secure in the event that the public key is reused. Finite field		be secure in the event that the public key is reused. Finite field
	and elliptic curve Diffie-Hellman key exchange methods used in TLS		and elliptic curve Diffie-Hellman key exchange methods used in TLS
	1.3 satisfy this criteria. For generic KEMs, this means satisfying		1.3 satisfy this criteria. For generic KEMs, this means satisfying
	IND-CCA2 security or having a transform like the Fujisaki-Okamoto		IND-CCA2 security or having a transform like the Fujisaki-Okamoto
	transform [FO] [HHK] applied. While it is recommended that		transform [FO] [HHK] applied. While it is recommended that
	skipping to change at line 445 ¶		skipping to change at line 446 ¶
	key_exchange: mypqkem_key_share		key_exchange: mypqkem_key_share
	},		},
	KeyShareEntry {		KeyShareEntry {
	NamedGroup: 'MyECDHMyPQKEM',		NamedGroup: 'MyECDHMyPQKEM',
	key_exchange: myecdh_mypqkem_key_share		key_exchange: myecdh_mypqkem_key_share
	},		},
	}		}
	3.3. Shared Secret Calculation		3.3. Shared Secret Calculation
	Here, this document also takes a simple "concatenation approach": The		This document also takes a simple "concatenation approach" for the
	two shared secrets are concatenated together and used as the shared		calculation of shared secrets: The two shared secrets are
	secret in the existing TLS 1.3 key schedule. Again, this document		concatenated together and used as the shared secret in the existing
	does not add any additional structure (length fields) in the		TLS 1.3 key schedule. Again, this document does not add any
	concatenation procedure; for both the traditional groups and post		additional structure (length fields) in the concatenation procedure;
	quantum KEMs, the shared secret output length is fixed for a specific		for both the traditional groups and post quantum KEMs, the shared
	elliptic curve or parameter set.		secret output length is fixed for a specific elliptic curve or
			parameter set.
	In other words, if the NamedGroup is MyECDHMyPQKEM, the shared secret		In other words, if the NamedGroup is MyECDHMyPQKEM, the shared secret
	is calculated as:		is calculated as:
	concatenated_shared_secret = MyECDH.shared_secret || MyPQKEM.shared_secret		concatenated_shared_secret = MyECDH.shared_secret
			|| MyPQKEM.shared_secret
	and inserted into the TLS 1.3 key schedule in place of the (EC)DHE		and inserted into the TLS 1.3 key schedule in place of the (EC)DHE
	shared secret, as shown in Figure 1.		shared secret, as shown in Figure 1.
	0		0
	|		|
	v		v
	PSK -> HKDF-Extract = Early Secret		PSK -> HKDF-Extract = Early Secret
	|		|
	+-----> Derive-Secret(...)		+-----> Derive-Secret(...)
	skipping to change at line 492 ¶		skipping to change at line 495 ¶
	v		v
	0 -> HKDF-Extract = Master Secret		0 -> HKDF-Extract = Master Secret
	|		|
	+-----> Derive-Secret(...)		+-----> Derive-Secret(...)
	+-----> Derive-Secret(...)		+-----> Derive-Secret(...)
	+-----> Derive-Secret(...)		+-----> Derive-Secret(...)
	+-----> Derive-Secret(...)		+-----> Derive-Secret(...)
	Figure 1: Key Schedule for Hybrid Key Exchange		Figure 1: Key Schedule for Hybrid Key Exchange
	*FIPS compliance of shared secret concatenation.* The US National		In regard to FIPS compliance, the US National Institute of Standards
	Institute of Standards and Technology (NIST) documents		and Technology (NIST) documents [NIST-SP-800-56C] and
	[NIST-SP-800-56C] and [NIST-SP-800-135] give recommendations for key		[NIST-SP-800-135] give recommendations for key derivation methods in
	derivation methods in key exchange protocols. Some hybrid		key exchange protocols. Some hybrid combinations may combine the
	combinations may combine the shared secret from a NIST-approved		shared secret from a NIST-approved algorithm (e.g., ECDH using the
	algorithm (e.g., ECDH using the nistp256/secp256r1 curve) with a		nistp256/secp256r1 curve) with a shared secret from an unapproved
	shared secret from a non-approved algorithm (e.g., post-quantum).		algorithm (e.g., post-quantum). [NIST-SP-800-56C] lists simple
	[NIST-SP-800-56C] lists simple concatenation as an approved method		concatenation as an approved method for generation of a hybrid shared
	for generation of a hybrid shared secret in which one of the		secret in which one of the constituent shared secrets is from an
	constituent shared secrets is from an approved method.		approved method.
	4. Discussion		4. Discussion
	*Larger public keys and/or ciphertexts.* The key_exchange field in		Larger public keys and/or ciphertexts:
	the KeyShareEntry struct in Section 3.2 limits public keys and		The key_exchange field in the KeyShareEntry struct in Section 3.2
	ciphertexts to 2^16-1 bytes. Some post-quantum KEMs have larger		limits public keys and ciphertexts to 2^16-1 bytes. Some post-
	public keys and/or ciphertexts; for example, Classic McEliece's		quantum KEMs have larger public keys and/or ciphertexts; for
	smallest parameter set has a public key size of 261,120 bytes.		example, Classic McEliece's smallest parameter set has a public
	However, all defined parameter sets for the Module-Lattice-Based Key		key size of 261,120 bytes [Classic-McEliece]. However, all
	Encapsulation Mechanism (ML-KEM) [NIST-FIPS-203] have public keys and		defined parameter sets for the Module-Lattice-Based Key
	ciphertexts that fall within the TLS constraints (although this may		Encapsulation Mechanism (ML-KEM) [NIST-FIPS-203] have public keys
	result in ClientHello messages larger than a single packet).		and ciphertexts that fall within the TLS constraints (although
			this may result in ClientHello messages larger than a single
			packet).
	*Duplication of key shares.* Concatenation of public keys in the		Duplication of key shares:
	key_exchange field in the KeyShareEntry struct as described in		Concatenation of public keys in the key_exchange field in the
	Section 3.2 can result in sending duplicate key shares. For example,		KeyShareEntry struct as described in Section 3.2 can result in
	if a client wants to offer support for two combinations, say		sending duplicate key shares. For example, if a client wants to
	"SecP256r1MLKEM768" and "X25519MLKEM768" [ECDHE-MLKEM], it would end		offer support for two combinations, say "SecP256r1MLKEM768" and
	up sending two ML-KEM-768 public keys, since the KeyShareEntry for		"X25519MLKEM768" [ECDHE-MLKEM], it would end up sending two ML-
	each combination contains its own copy of an ML-KEM-768 key. This		KEM-768 public keys, since the KeyShareEntry for each combination
	duplication may be more problematic for post-quantum algorithms that		contains its own copy of an ML-KEM-768 key. This duplication may
	have larger public keys. On the other hand, if the client wants to		be more problematic for post-quantum algorithms that have larger
	offer, for example, "SecP256r1MLKEM768" and "secp256r1" (for		public keys. On the other hand, if the client wants to offer, for
	backwards compatibility), there is relatively little duplicated data		example, "SecP256r1MLKEM768" and "secp256r1" (for backwards
	(as the secp256r1 keys are comparatively small).		compatibility), there is relatively little duplicated data (as the
			secp256r1 keys are comparatively small).
	5. IANA Considerations		5. IANA Considerations
	IANA has added this document as a reference for the "TLS Supported		IANA has added this document as a reference for the "TLS Supported
	Groups" registry [IANA-TLS].		Groups" registry [IANA-TLS].
	For hybrid combinations defined per this document, IANA will assign		For hybrid combinations defined per this document, IANA will assign
	identifiers in a range that is distinct from the Finite Field Groups		identifiers in a range that is distinct from the Finite Field Groups
	range. In addition, the "Recommended" column SHOULD be "N", and the		range. In addition, the "Recommended" column SHOULD be "N", and the
	"DTLS-OK" column SHOULD be "Y".		"DTLS-OK" column SHOULD be "Y".
	skipping to change at line 661 ¶		skipping to change at line 667 ¶
	bike-sike-hybrid-07>.		bike-sike-hybrid-07>.
	[CECPQ1] Braithwaite, M., "Experimenting with Post-Quantum		[CECPQ1] Braithwaite, M., "Experimenting with Post-Quantum
	Cryptography", Google Security Blog, 7 July 2016,		Cryptography", Google Security Blog, 7 July 2016,
	<https://security.googleblog.com/2016/07/experimenting-		<https://security.googleblog.com/2016/07/experimenting-
	with-post-quantum.html>.		with-post-quantum.html>.
	[CECPQ2] Langley, A., "CECPQ2", 12 December 2018,		[CECPQ2] Langley, A., "CECPQ2", 12 December 2018,
	<https://www.imperialviolet.org/2018/12/12/cecpq2.html>.		<https://www.imperialviolet.org/2018/12/12/cecpq2.html>.
			[Classic-McEliece]
			Josefsson, S., "Classic McEliece", Work in Progress,
			Internet-Draft, draft-josefsson-mceliece-03, 7 July 2025,
			<https://datatracker.ietf.org/doc/html/draft-josefsson-
			mceliece-03>.
	[DODIS] Dodis, Y. and J. Katz, "Chosen-Ciphertext Security of		[DODIS] Dodis, Y. and J. Katz, "Chosen-Ciphertext Security of
	Multiple Encryption", Theory of Cryptography (TCC 2005),		Multiple Encryption", Theory of Cryptography (TCC 2005),
	Lecture Notes in Computer Science, vol. 3378, pp. 188-209,		Lecture Notes in Computer Science, vol. 3378, pp. 188-209,
	DOI 10.1007/978-3-540-30576-7_11, 2005,		DOI 10.1007/978-3-540-30576-7_11, 2005,
	<https://doi.org/10.1007/978-3-540-30576-7_11>.		<https://doi.org/10.1007/978-3-540-30576-7_11>.
	[DOWLING] Dowling, B., Fischlin, M., Günther, F., and D. Stebila, "A		[DOWLING] Dowling, B., Fischlin, M., Günther, F., and D. Stebila, "A
	Cryptographic Analysis of the TLS 1.3 Handshake Protocol",		Cryptographic Analysis of the TLS 1.3 Handshake Protocol",
	Journal of Cryptology, vol. 34, article 37,		Journal of Cryptology, vol. 34, article 37,
	DOI 10.1007/s00145-021-09384-1, July 2021,		DOI 10.1007/s00145-021-09384-1, July 2021,
	<https://doi.org/10.1007/s00145-021-09384-1>.		<https://doi.org/10.1007/s00145-021-09384-1>.
	[ECDHE-MLKEM]		[ECDHE-MLKEM]
	Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.		Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.
	Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement		Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement
	for TLSv1.3", Work in Progress, Internet-Draft, draft-		for TLSv1.3", Work in Progress, Internet-Draft, draft-
	kwiatkowski-tls-ecdhe-mlkem-03, 24 December 2024,		ietf-tls-ecdhe-mlkem-04, 8 February 2026,
	<https://datatracker.ietf.org/doc/html/draft-kwiatkowski-		<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
	tls-ecdhe-mlkem-03>.		ecdhe-mlkem-04>.
	[ETSI] Campagna, M., Ed., et al., "Quantum Safe Cryptography and		[ETSI] Campagna, M., Ed., et al., "Quantum Safe Cryptography and
	Security: An introduction, benefits, enablers and		Security: An introduction, benefits, enablers and
	challengers", ETSI White Paper No. 8, June 2015,		challengers", ETSI White Paper No. 8, June 2015,
	<https://www.etsi.org/images/files/ETSIWhitePapers/		<https://www.etsi.org/images/files/ETSIWhitePapers/
	QuantumSafeWhitepaper.pdf>.		QuantumSafeWhitepaper.pdf>.
	[EVEN] Even, S. and O. Goldreich, "On the Power of Cascade		[EVEN] Even, S. and O. Goldreich, "On the Power of Cascade
	Ciphers", Advances in Cryptology, pp. 43-50,		Ciphers", Advances in Cryptology, pp. 43-50,
	DOI 10.1007/978-1-4684-4730-9_4, 1984,		DOI 10.1007/978-1-4684-4730-9_4, 1984,
	skipping to change at line 730 ¶		skipping to change at line 742 ¶
	96-113, DOI 10.1007/11426639_6, 2005,		96-113, DOI 10.1007/11426639_6, 2005,
	<https://doi.org/10.1007/11426639_6>.		<https://doi.org/10.1007/11426639_6>.
	[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid		[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
	Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,		Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
	February 2022, <https://www.rfc-editor.org/info/rfc9180>.		February 2022, <https://www.rfc-editor.org/info/rfc9180>.
	[IANA-TLS] IANA, "TLS Supported Groups",		[IANA-TLS] IANA, "TLS Supported Groups",
	<https://www.iana.org/assignments/tls-parameters>.		<https://www.iana.org/assignments/tls-parameters>.
	[IKE-HYBRID]
	Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
	Geest, D., Garcia-Morchon, O., and V. Smyslov, "Framework
	to Integrate Post-quantum Key Exchanges into Internet Key
	Exchange Protocol Version 2 (IKEv2)", Work in Progress,
	Internet-Draft, draft-tjhai-ipsecme-hybrid-qske-ikev2-04,
	9 July 2019, <https://datatracker.ietf.org/doc/html/draft-
	tjhai-ipsecme-hybrid-qske-ikev2-04>.
	[IKE-PSK] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,		[IKE-PSK] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
	"Mixing Preshared Keys in the Internet Key Exchange		"Mixing Preshared Keys in the Internet Key Exchange
	Protocol Version 2 (IKEv2) for Post-quantum Security",		Protocol Version 2 (IKEv2) for Post-quantum Security",
	RFC 8784, DOI 10.17487/RFC8784, June 2020,		RFC 8784, DOI 10.17487/RFC8784, June 2020,
	<https://www.rfc-editor.org/info/rfc8784>.		<https://www.rfc-editor.org/info/rfc8784>.
	[KATZ] Katz, J. and Y. Lindell, "Introduction to Modern		[KATZ] Katz, J. and Y. Lindell, "Introduction to Modern
	Cryptography", Third Edition, CRC Press, 2021.		Cryptography", Third Edition, CRC Press, 2021.
	[KIEFER] Kiefer, F. and K. Kwiatkowski, "Hybrid ECDHE-SIDH Key		[KIEFER] Kiefer, F. and K. Kwiatkowski, "Hybrid ECDHE-SIDH Key
	skipping to change at line 817 ¶		skipping to change at line 820 ¶
	Cryptography (PQCrypto 2020), Lecture Notes in Computer		Cryptography (PQCrypto 2020), Lecture Notes in Computer
	Science, vol. 12100, pp. 72-91,		Science, vol. 12100, pp. 72-91,
	DOI 10.1007/978-3-030-44223-1_5, 2020,		DOI 10.1007/978-3-030-44223-1_5, 2020,
	<https://doi.org/10.1007/978-3-030-44223-1_5>.		<https://doi.org/10.1007/978-3-030-44223-1_5>.
	[RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J.,		[RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J.,
	Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and		Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and
	Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)",		Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)",
	September 2020, <https://raccoon-attack.com/>.		September 2020, <https://raccoon-attack.com/>.
			[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
			Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
			Key Exchanges in the Internet Key Exchange Protocol
			Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
			2023, <https://www.rfc-editor.org/info/rfc9370>.
	[S2N] Hopkins, A. and M. Campagna, "Post-quantum TLS now		[S2N] Hopkins, A. and M. Campagna, "Post-quantum TLS now
	supported in AWS KMS", AWS Security Blog, 4 November 2019,		supported in AWS KMS", AWS Security Blog, 4 November 2019,
	<https://aws.amazon.com/blogs/security/post-quantum-tls-		<https://aws.amazon.com/blogs/security/post-quantum-tls-
	now-supported-in-aws-kms/>.		now-supported-in-aws-kms/>.
	[SCHANCK] Schanck, J. M. and D. Stebila, "A Transport Layer Security		[SCHANCK] Schanck, J. M. and D. Stebila, "A Transport Layer Security
	(TLS) Extension For Establishing An Additional Shared		(TLS) Extension For Establishing An Additional Shared
	Secret", Work in Progress, Internet-Draft, draft-schanck-		Secret", Work in Progress, Internet-Draft, draft-schanck-
	tls-additional-keyshare-00, 17 April 2017,		tls-additional-keyshare-00, 17 April 2017,
	<https://datatracker.ietf.org/doc/html/draft-schanck-tls-		<https://datatracker.ietf.org/doc/html/draft-schanck-tls-
	skipping to change at line 889 ¶		skipping to change at line 898 ¶
	* TLS 1.3: [CECPQ2], [OQS-111], [OQS-PROV], [PST]		* TLS 1.3: [CECPQ2], [OQS-111], [OQS-PROV], [PST]
	These experimental implementations have taken an ad hoc approach and		These experimental implementations have taken an ad hoc approach and
	not attempted to implement one of the Internet-Drafts listed above.		not attempted to implement one of the Internet-Drafts listed above.
	Unrelated to post-quantum but still related to the issue of combining		Unrelated to post-quantum but still related to the issue of combining
	multiple types of keying material in TLS is the use of pre-shared		multiple types of keying material in TLS is the use of pre-shared
	keys, especially the recent TLS Working Group document on including		keys, especially the recent TLS Working Group document on including
	an external pre-shared key [EXTERN-PSK].		an external pre-shared key [EXTERN-PSK].
	Considering other IETF standards, there is work on post-quantum pre-		[RFC9370] on the multiple key exchanges in the Internet Key Exchange
	shared keys in the Internet Key Exchange Protocol Version 2 (IKEv2)		Protocol Version 2 (IKEv2) has been published as a Proposed Standard,
	[IKE-PSK] and a framework for hybrid key exchange in IKEv2		and other IETF work includes post-quantum preshared keys in IKEv2
	[IKE-HYBRID]. The eXtended Merkle Signature Scheme (XMSS) hash-based		[IKE-PSK]. The eXtended Merkle Signature Scheme (XMSS) hash-based
	signature scheme has been published as an Informational RFC by the		signature scheme has been published as an Informational RFC by the
	IRTF [XMSS].		IRTF [XMSS].
	In the academic literature, [EVEN] initiated the study of combining		In the academic literature, [EVEN] initiated the study of combining
	multiple symmetric encryption schemes; [ZHANG], [DODIS], and [HARNIK]		multiple symmetric encryption schemes; [ZHANG], [DODIS], and [HARNIK]
	examined combining multiple public key encryption schemes; and		examined combining multiple public key encryption schemes; and
	[HARNIK] coined the term "robust combiner" to refer to a compiler		[HARNIK] coined the term "robust combiner" to refer to a compiler
	that constructs a hybrid scheme from individual schemes while		that constructs a hybrid scheme from individual schemes while
	preserving security properties. [GIACON] and [BINDEL] examined		preserving security properties. [GIACON] and [BINDEL] examined
	combining multiple key encapsulation mechanisms.		combining multiple key encapsulation mechanisms.
End of changes. 21 change blocks.
	82 lines changed or deleted		91 lines changed or added
This html diff was produced by rfcdiff 1.48.