< draft-ietf-tls-external-psk-importer-05.txt		draft-ietf-tls-external-psk-importer-06.txt >
	tls D. Benjamin		tls D. Benjamin
	Internet-Draft Google, LLC.		Internet-Draft Google, LLC.
	Intended status: Standards Track C.A. Wood		Intended status: Standards Track C.A. Wood
	Expires: 20 November 2020 Cloudflare		Expires: 6 June 2021 Cloudflare
	19 May 2020		3 December 2020
	Importing External PSKs for TLS		Importing External PSKs for TLS
	draft-ietf-tls-external-psk-importer-05		draft-ietf-tls-external-psk-importer-06
	Abstract		Abstract
	This document describes an interface for importing external Pre-		This document describes an interface for importing external Pre-
	Shared Keys (PSKs) into TLS 1.3.		Shared Keys (PSKs) into TLS 1.3.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 20 November 2020.		This Internet-Draft will expire on 6 June 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 13 ¶		skipping to change at page 2, line 13 ¶
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	4. PSK Import . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. PSK Import . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. External PSK Diversification . . . . . . . . . . . . . . 4		4.1. External PSK Diversification . . . . . . . . . . . . . . 4
	4.2. Binder Key Derivation . . . . . . . . . . . . . . . . . . 5		4.2. Binder Key Derivation . . . . . . . . . . . . . . . . . . 6
	5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 6		5. Deprecating Hash Functions . . . . . . . . . . . . . . . . . 6
	6. Incremental Deployment . . . . . . . . . . . . . . . . . . . 6		6. Incremental Deployment . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 9		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
	Appendix B. Addressing Selfie . . . . . . . . . . . . . . . . . 10		Appendix B. Addressing Selfie . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	TLS 1.3 [RFC8446] supports Pre-Shared Key (PSK) authentication,		TLS 1.3 [RFC8446] supports Pre-Shared Key (PSK) authentication,
	wherein PSKs can be established via session tickets from prior		wherein PSKs can be established via session tickets from prior
	connections or externally via some out-of-band mechanism. The		connections or externally via some out-of-band mechanism. The
	protocol mandates that each PSK only be used with a single hash		protocol mandates that each PSK only be used with a single hash
	function. This was done to simplify protocol analysis. TLS 1.2		function. This was done to simplify protocol analysis. TLS 1.2
	[RFC5246], in contrast, has no such requirement, as a PSK may be used		[RFC5246], in contrast, has no such requirement, as a PSK may be used
	with any hash algorithm and the TLS 1.2 PRF. While there is no known		with any hash algorithm and the TLS 1.2 pseudorandom function (PRF).
	way in which the same external PSK might produce related output in		While there is no known way in which the same external PSK might
	TLS 1.3 and prior versions, only limited analysis has been done.		produce related output in TLS 1.3 and prior versions, only limited
	Applications SHOULD provision separate PSKs for TLS 1.3 and prior		analysis has been done. Applications SHOULD provision separate PSKs
	versions when possible.		for TLS 1.3 and prior versions.
	To mitigate against any interference, this document specifies a PSK		To mitigate against any interference, this document specifies a PSK
	Importer interface by which external PSKs may be imported and		Importer interface by which external PSKs may be imported and
	subsequently bound to a specific KDF and hash function for use in		subsequently bound to a specific key derivation function (KDF) and
	(D)TLS 1.3. In particular, it describes a mechanism for		hash function for use in TLS 1.3 [RFC8446] and DTLS 1.3 [DTLS13]. In
	differentiating external PSKs by the target KDF, (D)TLS protocol		particular, it describes a mechanism for differentiating external
	version, and an optional context string. This process yields a set		PSKs by the target KDF, (D)TLS protocol version, and an optional
	of candidate PSKs, each of which are bound to a target KDF and		context string. This process yields a set of candidate PSKs, each of
	protocol, that are separate from those used in (D)TLS 1.2 and prior		which are bound to a target KDF and protocol, that are separate from
	versions. This expands what would normally have been a single PSK		those used in (D)TLS 1.2 and prior versions. This expands what would
	and identity into a set of PSKs and identities.		normally have been a single PSK and identity into a set of PSKs and
			identities.
	2. Conventions and Definitions		2. Conventions and Definitions
	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 BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Overview		3. Overview
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	* Base Key: The secret value of an EPSK.		* Base Key: The secret value of an EPSK.
	* External Identity: A sequence of bytes used to identify an EPSK.		* External Identity: A sequence of bytes used to identify an EPSK.
	* Target protocol: The protocol for which a PSK is imported for use.		* Target protocol: The protocol for which a PSK is imported for use.
	* Target KDF: The KDF for which a PSK is imported for use.		* Target KDF: The KDF for which a PSK is imported for use.
	* Imported PSK (IPSK): A PSK derived from an EPSK, External		* Imported PSK (IPSK): A PSK derived from an EPSK, External
	Identity, optional context string, and target protocol and KDF.		Identity, optional context string, target protocol, and target
			KDF.
	* Imported Identity: A sequence of bytes used to identify an IPSK.		* Imported Identity: A sequence of bytes used to identify an IPSK.
	4. PSK Import		4. PSK Import
	This section describes the PSK Importer interface and its underlying		This section describes the PSK Importer interface and its underlying
	diversification mechanism and binder key computation modification.		diversification mechanism and binder key computation modification.
	4.1. External PSK Diversification		4.1. External PSK Diversification
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 35 ¶
	protocol "target_protocol" and KDF "target_kdf", the importer		protocol "target_protocol" and KDF "target_kdf", the importer
	constructs an ImportedIdentity structure as follows:		constructs an ImportedIdentity structure as follows:
	struct {		struct {
	opaque external_identity<1...2^16-1>;		opaque external_identity<1...2^16-1>;
	opaque context<0..2^16-1>;		opaque context<0..2^16-1>;
	uint16 target_protocol;		uint16 target_protocol;
	uint16 target_kdf;		uint16 target_kdf;
	} ImportedIdentity;		} ImportedIdentity;
	The list of "target_kdf" values is maintained by IANA as described in		The list of ImportedIdentity.target_kdf values is maintained by IANA
	Section 9. External PSKs MUST NOT be imported for (D)TLS 1.2 or		as described in Section 9. External PSKs MUST NOT be imported for
	prior versions. See Section 6 for discussion on how imported PSKs		(D)TLS 1.2 or prior versions. See Section 6 for discussion on how
	for TLS 1.3 and non-imported PSKs for earlier versions co-exist for		imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions
	incremental deployment.		co-exist for incremental deployment.
	ImportedIdentity.context MUST include the context used to derive the		ImportedIdentity.context MUST include the context used to derive the
	EPSK, if any exists. For example, ImportedIdentity.context may		EPSK, if any exists. For example, ImportedIdentity.context may
	include information about peer roles or identities to mitigate		include information about peer roles or identities to mitigate
	Selfie-style reflection attacks [Selfie]. See Appendix B for more		Selfie-style reflection attacks [Selfie]. See Appendix B for more
	details. If the EPSK is a key derived from some other protocol or		details. If the EPSK is a key derived from some other protocol or
	sequence of protocols, ImportedIdentity.context MUST include a		sequence of protocols, ImportedIdentity.context MUST include a
	channel binding for the deriving protocols [RFC5056].		channel binding for the deriving protocols [RFC5056]. The details of
			this binding are protocol specific and out of scope for this
			document.
	ImportedIdentity.target_protocol MUST be the (D)TLS protocol version		ImportedIdentity.target_protocol MUST be the (D)TLS protocol version
	for which the PSK is being imported. For example, TLS 1.3 [RFC8446]		for which the PSK is being imported. For example, TLS 1.3 [RFC8446]
	and QUICv1 [QUIC] use 0x0304. Note that this means future versions		uses 0x0304, which will therefore also be used by QUICv1 [QUIC].
	of TLS will increase the number of PSKs derived from an external PSK.		Note that this means future versions of TLS will increase the number
			of PSKs derived from an external PSK.
	Given an ImportedIdentity and corresponding EPSK with base key		Given an ImportedIdentity and corresponding EPSK with base key
	"epsk", an Imported PSK IPSK with base key "ipskx" is computed as		"epsk", an Imported PSK IPSK with base key "ipskx" is computed as
	follows:		follows:
	epskx = HKDF-Extract(0, epsk)		epskx = HKDF-Extract(0, epsk)
	ipskx = HKDF-Expand-Label(epskx, "derived psk",		ipskx = HKDF-Expand-Label(epskx, "derived psk",
	Hash(ImportedIdentity), L)		Hash(ImportedIdentity), L)
	L corresponds to the KDF output length of ImportedIdentity.target_kdf		L corresponds to the KDF output length of ImportedIdentity.target_kdf
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 30 ¶
	suitable for supported ciphersuites.		suitable for supported ciphersuites.
	The identity of "ipskx" as sent on the wire is ImportedIdentity,		The identity of "ipskx" as sent on the wire is ImportedIdentity,
	i.e., the serialized content of ImportedIdentity is used as the		i.e., the serialized content of ImportedIdentity is used as the
	content of PskIdentity.identity in the PSK extension. The		content of PskIdentity.identity in the PSK extension. The
	corresponding TLS 1.3 binder key is "ipskx".		corresponding TLS 1.3 binder key is "ipskx".
	The hash function used for HKDF [RFC5869] is that which is associated		The hash function used for HKDF [RFC5869] is that which is associated
	with the EPSK. It is not the hash function associated with		with the EPSK. It is not the hash function associated with
	ImportedIdentity.target_kdf. If no hash function is specified,		ImportedIdentity.target_kdf. If no hash function is specified,
	SHA-256 MUST be used. Diversifying EPSK by		SHA-256 [SHA2] MUST be used. Diversifying EPSK by
	ImportedIdentity.target_kdf ensures that an IPSK is only used as		ImportedIdentity.target_kdf ensures that an IPSK is only used as
	input keying material to at most one KDF, thus satisfying the		input keying material to at most one KDF, thus satisfying the
	requirements in [RFC8446]. See Section 7 for more details.		requirements in [RFC8446]. See Section 7 for more details.
	Endpoints SHOULD generate a compatible "ipskx" for each target		Endpoints SHOULD generate a compatible "ipskx" for each target
	ciphersuite they offer. For example, importing a key for		ciphersuite they offer. For example, importing a key for
	TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two		TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two
	PSKs, one for HKDF-SHA256 and another for HKDF-SHA384. In contrast,		PSKs, one for HKDF-SHA256 and another for HKDF-SHA384. In contrast,
	if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are		if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are
	supported, only one derived key is necessary.		supported, only one derived key is necessary.
	EPSKs may be imported before the start of a connection if the target		EPSKs MAY be imported before the start of a connection if the target
	KDFs, protocols, and context string(s) are known a priori. EPSKs may		KDFs, protocols, and context string(s) are known a priori. EPSKs MAY
	also be imported for early data use if they are bound to protocol		also be imported for early data use if they are bound to protocol
	settings and configurations that would otherwise be required for		settings and configurations that would otherwise be required for
	early data with normal (ticket-based PSK) resumption. Minimally,		early data with normal (ticket-based PSK) resumption. Minimally,
	that means ALPN, QUIC transport parameters (if used for QUIC), etc.,		that means Application-Layer Protocol Negotiation [RFC7301], QUIC
	must be provisioned alongside these EPSKs.		transport parameters (if used for QUIC), and any other relevant
			parameters that are negotiated for early data MUST be provisioned
			alongside these EPSKs.
	4.2. Binder Key Derivation		4.2. Binder Key Derivation
	To prevent confusion between imported and non-imported PSKs, imported		To prevent confusion between imported and non-imported PSKs, imported
	PSKs change the PSK binder key derivation label. In particular, the		PSKs change the PSK binder key derivation label. In particular, the
	standard TLS 1.3 PSK binder key computation is defined as follows:		standard TLS 1.3 PSK binder key computation is defined as follows:
	0		0
	|		|
	v		v
	skipping to change at page 6, line 51 ¶		skipping to change at page 7, line 15 ¶
	6. Incremental Deployment		6. Incremental Deployment
	Recall that TLS 1.2 permits computing the TLS PRF with any hash		Recall that TLS 1.2 permits computing the TLS PRF with any hash
	algorithm and PSK. Thus, an EPSK may be used with the same KDF (and		algorithm and PSK. Thus, an EPSK may be used with the same KDF (and
	underlying HMAC hash algorithm) as TLS 1.3 with importers. However,		underlying HMAC hash algorithm) as TLS 1.3 with importers. However,
	critically, the derived PSK will not be the same since the importer		critically, the derived PSK will not be the same since the importer
	differentiates the PSK via the identity and target KDF and protocol.		differentiates the PSK via the identity and target KDF and protocol.
	Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS		Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
	1.2, and thereby avoid cross-protocol collisions. Note that this		1.2, and thereby avoid cross-protocol collisions. Note that this
	does not preclude endpoints from using non-imported PSKs for TLS 1.2.		does not preclude endpoints from using non-imported PSKs for TLS 1.2.
	Indeed, this is necessary for incremental deployment.		Indeed, this is necessary for incremental deployment. Specifically,
			existing applications using TLS 1.2 with non-imported PSKs can safely
			enable TLS 1.3 with imported PSKs in clients and servers without
			interoperability risk.
	7. Security Considerations		7. Security Considerations
	The PSK Importer security goals can be roughly stated as follows:		The PSK Importer security goals can be roughly stated as follows:
	avoid PSK re-use across KDFs while properly authenticating endpoints.		avoid PSK re-use across KDFs while properly authenticating endpoints.
	When modeled as computational extractors, KDFs assume that input		When modeled as computational extractors, KDFs assume that input
	keying material (IKM) is sampled from some "source" probability		keying material (IKM) is sampled from some "source" probability
	distribution and that any two IKM values are chosen independently of		distribution and that any two IKM values are chosen independently of
	each other [Kraw10]. This source-independence requirement implies		each other [Kraw10]. This source-independence requirement implies
	that the same IKM value cannot be used for two different KDFs.		that the same IKM value cannot be used for two different KDFs.
	skipping to change at page 7, line 51 ¶		skipping to change at page 8, line 18 ¶
	3. Imported PSKs are not used as IKM for two different KDFs.		3. Imported PSKs are not used as IKM for two different KDFs.
	4. Imported PSKs do not collide with future protocol versions and		4. Imported PSKs do not collide with future protocol versions and
	KDFs.		KDFs.
	There is no known interference between the process for computing		There is no known interference between the process for computing
	Imported PSKs from an external PSK and the processing of existing		Imported PSKs from an external PSK and the processing of existing
	external PSKs used in (D)TLS 1.2 and below. However, only limited		external PSKs used in (D)TLS 1.2 and below. However, only limited
	analysis has been done, which is an additional reason why		analysis has been done, which is an additional reason why
	applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior		applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior
	versions when possible, even when the importer interface is used in		versions, even when the importer interface is used in (D)TLS 1.3.
	(D)TLS 1.3.
	The PSK Importer does not prevent applications from constructing non-		The PSK Importer does not prevent applications from constructing non-
	importer PSK identities that collide with imported PSK identities.		importer PSK identities that collide with imported PSK identities.
	8. Privacy Considerations		8. Privacy Considerations
	External PSK identities are typically static by design so that		External PSK identities are typically static by design so that
	endpoints may use them to lookup keying material. However, for some		endpoints may use them to lookup keying material. However, for some
	systems and use cases, this identity may become a persistent tracking		systems and use cases, this identity may become a persistent tracking
	identifier.		identifier.
	9. IANA Considerations		9. IANA Considerations
	This specification introduces a new registry for TLS KDF identifiers,		This specification introduces a new registry for TLS KDF identifiers,
	titled "TLS KDF Identifiers", under the existing "Transport Layer		titled "TLS KDF Identifiers", under the existing "Transport Layer
	Security (TLS) Parameters" heading.		Security (TLS) Parameters" heading.
	The entries in the registry are:		The entries in the registry are:
	+-----------------+--------+		+-----------------+--------+-----------+
	| KDF Description | Value |		| KDF Description | Value | Reference |
	+=================+========+		+=================+========+===========+
	| Reserved | 0x0000 |		| Reserved | 0x0000 | N/A |
	+-----------------+--------+		+-----------------+--------+-----------+
	| HKDF_SHA256 | 0x0001 |		| HKDF_SHA256 | 0x0001 | [RFC5869] |
	+-----------------+--------+		+-----------------+--------+-----------+
	| HKDF_SHA384 | 0x0002 |		| HKDF_SHA384 | 0x0002 | [RFC5869] |
	+-----------------+--------+		+-----------------+--------+-----------+
	Table 1: Target KDF Registry		Table 1: Target KDF Registry
	New target KDF values are allocated according to the following		New target KDF values are allocated according to the following
	process:		process:
	* Values in the range 0x0000-0xfeff are assigned via Specification		* Values in the range 0x0000-0xfeff are assigned via Specification
	Required [RFC8126].		Required [RFC8126].
	* Values in the range 0xff00-0xffff are reserved for Private Use		* Values in the range 0xff00-0xffff are reserved for Private Use
	[RFC8126].		[RFC8126].
	The procedures for requesting values in the Specification Required		The procedures for requesting values in the Specification Required
	space are specified in Section 17 of [RFC8447].		space are specified in Section 17 of [RFC8447].
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
			Datagram Transport Layer Security (DTLS) Protocol Version
			1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
			dtls13-39, 2 November 2020, <http://www.ietf.org/internet-
			drafts/draft-ietf-tls-dtls13-39.txt>.
	[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", Work in Progress, Internet-Draft,		and Secure Transport", Work in Progress, Internet-Draft,
	draft-ietf-quic-transport-27, 21 February 2020,		draft-ietf-quic-transport-32, 20 October 2020,
	<http://www.ietf.org/internet-drafts/draft-ietf-quic-		<http://www.ietf.org/internet-drafts/draft-ietf-quic-
	transport-27.txt>.		transport-32.txt>.
	[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>.
	[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure		[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,		Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
	<https://www.rfc-editor.org/info/rfc5056>.		<https://www.rfc-editor.org/info/rfc5056>.
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 29 ¶
	[BAA15] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti,		[BAA15] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti,
	"Verified Contributive Channel Bindings for Compound		"Verified Contributive Channel Bindings for Compound
	Authentication", DOI 10.14722/ndss.2015.23277, Proceedings		Authentication", DOI 10.14722/ndss.2015.23277, Proceedings
	2015 Network and Distributed System Security Symposium,		2015 Network and Distributed System Security Symposium,
	2015, <https://doi.org/10.14722/ndss.2015.23277>.		2015, <https://doi.org/10.14722/ndss.2015.23277>.
	[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key		[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key
	Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 ,		Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 ,
	2010, <https://eprint.iacr.org/2010/264>.		2010, <https://eprint.iacr.org/2010/264>.
			[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
			"Transport Layer Security (TLS) Application-Layer Protocol
			Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
			July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3		[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3
	with PSK", 2019, <https://eprint.iacr.org/2019/347.pdf>.		with PSK", 2019, <https://eprint.iacr.org/2019/347.pdf>.
			[SHA2] National Institute of Standards and Technology, "Secure
			Hash Standard", FIPS PUB 180-3 , October 2008.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The authors thank Eric Rescorla and Martin Thomson for discussions		The authors thank Eric Rescorla and Martin Thomson for discussions
	that led to the production of this document, as well as Christian		that led to the production of this document, as well as Christian
	Huitema for input regarding privacy considerations of external PSKs.		Huitema for input regarding privacy considerations of external PSKs.
	John Mattsson provided input regarding PSK importer deployment		John Mattsson provided input regarding PSK importer deployment
	considerations. Hugo Krawczyk provided guidance for the security		considerations. Hugo Krawczyk provided guidance for the security
	considerations. Martin Thomson, Jonathan Hoyland, Scott Hollenbeck		considerations. Martin Thomson, Jonathan Hoyland, Scott Hollenbeck
	and others all provided reviews, feedback, and suggestions for		and others all provided reviews, feedback, and suggestions for
	improving the document.		improving the document.
End of changes. 24 change blocks.
	51 lines changed or deleted		74 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/