< draft-ietf-tls-tls13-cert-with-extern-psk-05.txt		draft-ietf-tls-tls13-cert-with-extern-psk-06.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Experimental December 22, 2019		Intended status: Experimental December 23, 2019
	Expires: June 24, 2020		Expires: June 25, 2020
	TLS 1.3 Extension for Certificate-based Authentication with an External		TLS 1.3 Extension for Certificate-based Authentication with an External
	Pre-Shared Key		Pre-Shared Key
	draft-ietf-tls-tls13-cert-with-extern-psk-05		draft-ietf-tls-tls13-cert-with-extern-psk-06
	Abstract		Abstract
	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 pre-		authenticate with a combination of a certificate and an external pre-
	shared key (PSK).		shared key (PSK).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 24, 2020.		This Internet-Draft will expire on June 25, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 31 ¶
	restriction is removed when the "tls_cert_with_extern_psk" extension		restriction is removed when the "tls_cert_with_extern_psk" extension
	is offered by the client and accepted by the server. However, TLS		is offered by the client and accepted by the server. However, TLS
	1.3 does not permit an external PSK to be used in the same fashion as		1.3 does not permit an external PSK to be used in the same fashion as
	a resumption PSK, and this extension does not alter those		a resumption PSK, and this extension does not alter those
	restrictions. Thus, a certificate MUST NOT be used with a resumption		restrictions. Thus, a certificate MUST NOT be used with a resumption
	PSK.		PSK.
	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 quantum		content vulnerable to the future development of a large-scale quantum
	computer.		computer. However, the generation, distribution, and management of
			the external PSKs is out of scope for this specification.
	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 not.		that is protected with an external PSK and a connection that is not.
	Doing so may allow an eavesdropper to correlate the connections,		Doing so may allow an eavesdropper to correlate the connections,
	making the content vulnerable to the future invention of a large-		making the content vulnerable to the future invention of a large-
	scale quantum computer.		scale quantum computer.
	Implementations must generate external PSKs with a secure key		Implementations must generate external PSKs with a secure key
	management technique, such as pseudo-random generation of the key or		management technique, such as pseudo-random generation of the key or
	derivation of the key from one or more other secure keys. The use of		derivation of the key from one or more other secure keys. The use of
	skipping to change at page 9, line 8 ¶		skipping to change at page 9, line 11 ¶
	possibilities, rather than brute-force searching the whole key space.		possibilities, rather than brute-force searching the whole key space.
	The generation of quality random numbers is difficult. [RFC4086]		The generation of quality random numbers is difficult. [RFC4086]
	offers important guidance in this area.		offers important guidance in this area.
	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 MUST NOT be the sole basis for
	authentication. The reasoning is explained in Section 4.2 of		authentication. The reasoning is explained in Section 4.2 of
	[K2016]. When this extension is used, authentication is based on		[K2016]. When this extension is used, authentication is based on
	certificates, not the external PSK.		certificates, not the external PSK.
	In this extension, the external PSK preserves secrecy if the (EC)DH		In this extension, the external PSK preserves confidentiality if the
	key agreement is ever broken by cryptanalysis or the future invention		(EC)DH key agreement is ever broken by cryptanalysis or the future
	of a large-scale quantum computer. As long as the attacker does not		invention of a large-scale quantum computer. As long as the attacker
	know the PSK and the key derivation algorithm remains unbroken, the		does not know the PSK and the key derivation algorithm remains
	attacker cannot derive the session secrets even if they are able to		unbroken, the attacker cannot derive the session secrets even if they
	compute the (EC)DH shared secret.		are able to compute the (EC)DH shared secret. Should the attacker be
			able compute the (EC)DH shared secret, the forward secrecy advantages
			traditionally associated with ephemeral (EC)DH keys will no longer be
			relevant. Although the ephemeral private keys used during a given
			TLS session are destroyed at the end of a session, preventing the
			attacker from later accessing them, these private keys would
			nevertheless be recoverable due to the break in the algorithm.
			However, a more general notion of "secrecy after key material is
			destroyed" would still be achievable using external PSKs, if they are
			managed in a way that ensures their destruction when they are no
			longer needed, and with the assumption that the algorithms that use
			the external PSKs remain quantum-safe.
	TLS 1.3 key derivation makes use of the HKDF algorithm, which depends		TLS 1.3 key derivation makes use of the HKDF algorithm, which depends
	upon the HMAC [RFC2104] construction and a hash function. This		upon the HMAC [RFC2104] construction and a hash function. This
	extension provides the desired protection for the session secrets as		extension provides the desired protection for the session secrets as
	long as HMAC with the selected hash function is a pseudorandom		long as HMAC with the selected hash function is a pseudorandom
	function (PRF) [GGM1986].		function (PRF) [GGM1986].
	In the future, if the (EC)DH key agreement is broken by cryptanalysis
	or the invention of a large-scale quantum computer, the forward
	secrecy advantages traditionally associated with ephemeral (EC)DH
	keys will no longer be relevant. Although the ephemeral private keys
	used during a given TLS session would be destroyed at the end of a
	session, preventing the attacker from later accessing them, the
	private keys would nevertheless be recoverable due to the break in
	the algorithm. A more general notion of "secrecy after key material
	is destroyed" would still be achievable using external PSKs, of
	course, provided that they are managed in a way that ensures their
	destruction when they are no longer needed, and with the assumption
	that the algorithms that use the external PSKs remain quantum-safe.
	This specification does not require that the external PSK is known		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		only by the client and server. The external PSK may be known to a
	group. Since authentication depends on the public key in a		group. Since authentication depends on the public key in a
	certificate, knowledge of the external PSK by other parties does not		certificate, knowledge of the external PSK by other parties does not
	enable impersonation. Since confidentiality depends on the shared		enable impersonation. Since confidentiality depends on the shared
	secret from (EC)DH, knowledge of the external PSK by other parties		secret from (EC)DH, knowledge of the external PSK by other parties
	does not enable eavesdropping. However, group members can record the		does not enable eavesdropping. However, group members can record the
	traffic of other members, and then decrypt it if they ever gain		traffic of other members, and then decrypt it if they ever gain
	access to a large-scale quantum computer. Also, when many parties		access to a large-scale quantum computer. Also, when many parties
	know the external PSK, there are many opportunities for theft of the		know the external PSK, there are many opportunities for theft of the
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 44 ¶
	This extension makes use of external PSKs to improve resilience		This extension makes use of external PSKs to improve resilience
	against attackers that gain access to a large-scale quantum computer		against attackers that gain access to a large-scale quantum computer
	in the future. This extension is always accompanied by the		in the future. This extension is always accompanied by the
	"pre_shared_key" extension to provide the PSK identities in plaintext		"pre_shared_key" extension to provide the PSK identities in plaintext
	in the ClientHello message. Passive observation of the these PSK		in the ClientHello message. Passive observation of the these PSK
	identities will aid an attacker to track users of this extension.		identities will aid an attacker to track users of this extension.
	9. Acknowledgments		9. Acknowledgments
	Many thanks to Liliya Akhmetzyanova, Christian Huitema, Ben Kaduk,		Many thanks to Liliya Akhmetzyanova, Roman Danyliw, Christian
	Geoffrey Keating, Hugo Krawczyk, Mirja Kuehlewind, Nikos		Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja
	Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee for		Kuehlewind, Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson,
	their review and comments; their efforts have improved this document.		and Peter Yee for their review and comments; their efforts have
			improved this document.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
End of changes. 7 change blocks.
	28 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/