< draft-ietf-tls-tls13-cert-with-extern-psk-01.txt		draft-ietf-tls-tls13-cert-with-extern-psk-02.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Experimental May 9, 2019		Intended status: Experimental May 31, 2019
	Expires: November 10, 2019		Expires: December 2, 2019
	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-01		draft-ietf-tls-tls13-cert-with-extern-psk-02
	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 November 10, 2019.		This Internet-Draft will expire on December 2, 2019.
	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 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	authenticate the server in the TLS 1.3 handshake protocol. It is an		authenticate the server in the TLS 1.3 handshake protocol. It is an
	open question whether or not it is feasible to build a large-scale		open question whether or not it is feasible to build a large-scale
	quantum computer, and if so, when that might happen. However, if		quantum computer, and if so, when that might happen. However, if
	such a quantum computer is invented, many of the cryptographic		such a quantum computer is invented, many of the cryptographic
	algorithms and the security protocols that use them would become		algorithms and the security protocols that use them would become
	vulnerable.		vulnerable.
	The TLS 1.3 handshake protocol employs key agreement algorithms that		The TLS 1.3 handshake protocol employs key agreement algorithms that
	could be broken by the invention of a large-scale quantum computer		could be broken by the invention of a large-scale quantum computer
	[I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH)		[I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH)
	[DH] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a		[DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a
	result, an adversary that stores a TLS 1.3 handshake protocol		result, an adversary that stores a TLS 1.3 handshake protocol
	exchange today could decrypt the associated encrypted communications		exchange today could decrypt the associated encrypted communications
	in the future when a large-scale quantum computer becomes available.		in the future when a large-scale quantum computer becomes available.
	In the near-term, this document describes TLS 1.3 extension to		In the near-term, this document describes TLS 1.3 extension to
	protect today's communications from the future invention of a large-		protect today's communications from the future invention of a large-
	scale quantum computer by providing a strong external PSK as an input		scale quantum computer by providing a strong external PSK as an input
	to the TLS 1.3 key schedule while preserving the authentication		to the TLS 1.3 key schedule while preserving the authentication
	provided by the existing certificate and digital signature		provided by the existing certificate and digital signature
	mechanisms.		mechanisms.
	skipping to change at page 6, line 34 ¶		skipping to change at page 6, line 34 ¶
	case server_hello: uint16 selected_identity;		case server_hello: uint16 selected_identity;
	};		};
	} PreSharedKeyExtension;		} PreSharedKeyExtension;
	The OfferedPsks contains the list of PSK identities and associated		The OfferedPsks contains the list of PSK identities and associated
	binders for the external PSKs that the client is willing to use with		binders for the external PSKs that the client is willing to use with
	the server.		the server.
	The identities are a list of external PSK identities that the client		The identities are a list of external PSK identities that the client
	is willing to negotiate with the server. Each external PSK has an		is willing to negotiate with the server. Each external PSK has an
	associated identity that is known to the client and the server. In		associated identity that is known to the client and the server; the
			associated identities may be know to other parties as well. In
	addition, the binder validation (see below) confirms that the client		addition, the binder validation (see below) confirms that the client
	and server have the same key associated with the identity.		and server have the same key associated with the identity.
	The obfuscated_ticket_age is not used for external PSKs; clients		The obfuscated_ticket_age is not used for external PSKs; clients
	SHOULD set this value to 0, and servers MUST ignore the value.		SHOULD set this value to 0, and servers MUST ignore the value.
	The binders are a series of HMAC values, one for each external PSK		The binders are a series of HMAC values, one for each external PSK
	offered by the client, in the same order as the identities list. The		offered by the client, in the same order as the identities list. The
	HMAC value is computed using the binder_key, which is derived from		HMAC value is computed using the binder_key, which is derived from
	the external PSK, and a partial transcript of the current handshake.		the external PSK, and a partial transcript of the current handshake.
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	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
	inadequate pseudo-random number generators (PRNGs) to generate		inadequate pseudo-random number generators (PRNGs) to generate
	external PSKs can result in little or no security. An attacker may		external PSKs can result in little or no security. An attacker may
	find it much easier to reproduce the PRNG environment that produced		find it much easier to reproduce the PRNG environment that produced
	the external PSKs and searching the resulting small set of		the external PSKs and searching the resulting small set of
	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
			the server, then the external PSK MUST NOT be the sole basis for
			authentication. The reasoning is explained in [K2016] (see
			Section 4.2). When this extension is used, authentication is based
			on certificates, not the external PSK.
			In this extension, the external PSK preserves secrecy if the (EC)DH
			key agreement is ever broken by cryptanalysis or the future invention
			of a large-scale quantum computer. As long as the attacker does not
			know the PSK and the key derivation algorithm remains unbroken, the
			attacker cannot derive the session secrets even if they are able to
			compute the (EC)DH shared secret.
			TLS 1.3 key derivation makes use of the HKDF algorithm, which depends
			upon the HMAC construction and a hash function. This extension
			provides the desired protection for the session secrets as long as
			HMAC with the selected hash function is a pseudorandom 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 external PSK is known only
			by 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 the external PSK by other parties does not enable
			impersonation. Since confidentiality depends on the shared secret
			from (EC)DH, knowledge of the external PSK by other parties does not
			enable eavesdropping. However, group members can record the traffic
			of other members, and then decrypt it if they ever gain access to a
			large-scale quantum computer. Also, when many parties know the
			external PSK, there are many opportunities for theft of the external
			PSK by an attacker. Once an attacker has the external PSK, they can
			decrypt stored traffic if they ever gain access to a large-scale
			quantum computer in the same manner as a legitimate group member.
	TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are		TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are
	bound to a specific hash function and KDF. By contrast, TLS 1.2		bound to a specific hash function and KDF. By contrast, TLS 1.2
	[RFC5246] allows PSKs to be used with any hash function and the TLS		[RFC5246] allows PSKs to be used with any hash function and the TLS
	1.2 PRF. Thus, the safest approach is to use a PSK with either TLS		1.2 PRF. Thus, the safest approach is to use a PSK with either TLS
	1.2 or TLS 1.3. However, any PSK that might be used with both TLS		1.2 or TLS 1.3. However, any PSK that might be used with both TLS
	1.2 and TLS 1.3 must be used with only one hash function, which is		1.2 and TLS 1.3 must be used with only one hash function, which is
	the one that is bound for use in TLS 1.3. This restriction is less		the one that is bound for use in TLS 1.3. This restriction is less
	than optimal when users want to provision a single PSK. While the		than optimal when users want to provision a single PSK. While the
	constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC		constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC
	[RFC2104], the constructions are different, and there is no known way		[RFC2104], the constructions are different, and there is no known way
	skipping to change at page 9, line 25 ¶		skipping to change at page 10, line 22 ¶
	With this extension, the Early Secret is computed as:		With this extension, the Early Secret is computed as:
	Early Secret = HKDF-Extract(External PSK, 0)		Early Secret = HKDF-Extract(External PSK, 0)
	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		reasons, TLS 1.3 continues to meet its security goals when this
	extension is used.		extension is used.
	8. Acknowledgments		8. Privacy Considerations
	Many thanks to Nikos Mavrogiannopoulos, Nick Sullivan, Martin		Appendix E.6 of [RFC8446] discusses identity exposure attacks on
	Thomson, and Peter Yee for their review and comments; their efforts		PSKs. The guidance in this section remains relevant.
	have improved this document.
	9. References		This extension makes use of external PSKs to improve resilience
			against attackers that gain access to a large-scale quantum computer
			in the future. This extension is always accompanied by the
			"pre_shared_key" extension to provide the PSK identities in plaintext
			in the ClientHello message. Passive observation of the these PSK
			identities will aid an attacker to track users of this extension.
	9.1. Normative References		9. Acknowledgments
			Many thanks to Liliya Akhmetzyanova, Christian Huitema, Geoffrey
			Keating, Hugo Krawczyk, Nikos Mavrogiannopoulos, Nick Sullivan,
			Martin Thomson, and Peter Yee for their review and comments; their
			efforts have improved this document.
			10. 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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	9.2. Informative References		10.2. Informative References
	[DH] Diffie, W. and M. Hellman, "New Directions in		[DH1977] Diffie, W. and M. Hellman, "New Directions in
	Cryptography", IEEE Transactions on Information		Cryptography", IEEE Transactions on Information
	Theory V.IT-22 n.6, June 1977.		Theory V.IT-22 n.6, June 1977.
			[GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to
			construct random functions", J. ACM 1986 (33), pp.
			792-807, 1986.
	[I-D.hoffman-c2pq]		[I-D.hoffman-c2pq]
	Hoffman, P., "The Transition from Classical to Post-		Hoffman, P., "The Transition from Classical to Post-
	Quantum Cryptography", draft-hoffman-c2pq-04 (work in		Quantum Cryptography", draft-hoffman-c2pq-05 (work in
	progress), August 2018.		progress), May 2019.
	[IEEE1363]		[IEEE1363]
	Institute of Electrical and Electronics Engineers, "IEEE		Institute of Electrical and Electronics Engineers, "IEEE
	Standard Specifications for Public-Key Cryptography", IEEE		Standard Specifications for Public-Key Cryptography", IEEE
	Std 1363-2000, 2000.		Std 1363-2000, 2000.
			[K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication
			Compiler for Key Exchange (with Applications to Client
			Authentication in TLS 1.3)", IACR ePrint 2016/711, August
			2016.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	DOI 10.17487/RFC2104, February 1997,		DOI 10.17487/RFC2104, February 1997,
	<https://www.rfc-editor.org/info/rfc2104>.		<https://www.rfc-editor.org/info/rfc2104>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
End of changes. 15 change blocks.
	16 lines changed or deleted		85 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/