rfc9266.original.xml		rfc9266.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
	<!ENTITY docName "draft-ietf-kitten-tls-channel-bindings-for-tls13-16">		<!DOCTYPE rfc [
	]>		<!ENTITY nbsp "&#160;">
			<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
			]>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"		<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	ipr="trust200902"		ipr="trust200902"
	docName="&docName;"		docName="draft-ietf-kitten-tls-channel-bindings-for-tls13"
			number="9266"
	obsoletes=""		obsoletes=""
	updates="5801, 5802, 5929, 7677"		updates="5801, 5802, 5929, 7677"
	submissionType="IETF"		submissionType="IETF"
	category="std"		category="std"
	consensus="true"		consensus="true"
	xml:lang="en"		xml:lang="en"
	tocInclude="true"		tocInclude="true"
	symRefs="true"		symRefs="true"
	sortRefs="true"		sortRefs="true"
	version="3">		version="3">
	skipping to change at line 18 ¶		skipping to change at line 24 ¶
	obsoletes=""		obsoletes=""
	updates="5801, 5802, 5929, 7677"		updates="5801, 5802, 5929, 7677"
	submissionType="IETF"		submissionType="IETF"
	category="std"		category="std"
	consensus="true"		consensus="true"
	xml:lang="en"		xml:lang="en"
	tocInclude="true"		tocInclude="true"
	symRefs="true"		symRefs="true"
	sortRefs="true"		sortRefs="true"
	version="3">		version="3">
	<front>		<front>
	<title abbrev="">Channel Bindings for TLS 1.3</title>		<title abbrev="">Channel Bindings for TLS 1.3</title>
	<seriesInfo name="Internet-Draft" value="&docName;"/>		<seriesInfo name="RFC" value="9266"/>
	<author initials="S" surname="Whited" fullname="Sam Whited">		<author initials="S" surname="Whited" fullname="Sam Whited">
	<organization/>		<organization/>
	<address>		<address>
	<postal>		<postal>
	<street/>		<street/>
	<city>Atlanta</city>		<city>Atlanta</city>
	<code>GA</code>		<region>GA</region>
	<country>USA</country>		<country>United States of America</country>
	<region/>		<region/>
	</postal>		</postal>
	<phone/>		<phone/>
	<email>sam@samwhited.com</email>		<email>sam@samwhited.com</email>
	<uri>https://blog.samwhited.com/</uri>		<uri>https://blog.samwhited.com/</uri>
	</address>		</address>
	</author>		</author>
	<date year="2022" month="May" day="04"/>		<date year="2022" month="July"/>
	<area>Internet</area>
	<workgroup>Transport Layer Security</workgroup>		<area>sec</area>
			<workgroup>kitten</workgroup>
	<abstract>		<abstract>
	<t>		<t>
	This document defines a channel binding type, tls-exporter, that is		This document defines a channel binding type, tls-exporter, that is
	compatible with TLS 1.3 in accordance with RFC 5056, On Channel Binding.		compatible with TLS 1.3 in accordance with RFC 5056, "On the Use of
	Furthermore, it updates the default channel binding to the new binding		Channel Bindings to Secure Channels". Furthermore, it updates the
	for versions of TLS greater than 1.2.		default channel binding to the new binding for versions of TLS greater
	This document updates RFC5801, RFC5802, RFC5929, and RFC7677.		than 1.2. This document updates RFCs 5801, 5802, 5929, and 7677.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="default">		<section anchor="introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	The "tls-unique" channel binding type defined in		The "tls-unique" channel binding type defined in
	<xref target="RFC5929"/> was found to be vulnerable to the "triple		<xref target="RFC5929"/> was found to be susceptible to the "triple
	handshake vulnerability" <xref target="TRIPLE-HANDSHAKE"/> without the		handshake vulnerability" <xref target="TRIPLE-HANDSHAKE"/> without the
	extended master secret extension defined in <xref target="RFC7627"/>.		extended master secret extension defined in <xref target="RFC7627"/>.
	While TLS 1.3 uses a complete transcript hash akin to the extended		While TLS 1.3 uses a complete transcript hash akin to the extended
	master secret procedures, the safety of channel bindings with TLS 1.3		master secret procedures, the safety of channel bindings with TLS 1.3
	was not analyzed as part of the core protocol work, and so the		was not analyzed as part of the core protocol work, so the
	specification of channel bindings for TLS 1.3 was deferred.		specification of channel bindings for TLS 1.3 was deferred.
	<xref target="RFC8446"/> section C.5 notes the lack of channel bindings		<xref target="RFC8446" sectionFormat="of" section="C.5"/> notes the lack
	for TLS 1.3; this document defines such channel bindings, and fills that		of channel bindings
			for TLS 1.3; this document defines such channel bindings and fills that
	gap.		gap.
	Furthermore, this document updates <xref target="RFC5929"/> by adding an		Furthermore, this document updates <xref target="RFC5929"/> by adding an
	additional unique channel binding type, "tls-exporter", that replaces		additional unique channel binding type, "tls-exporter", that replaces
	some usage of "tls-unique".		some usage of "tls-unique".
	</t>		</t>
	<section anchor="conventions-and-terminology" numbered="true" toc="default ">		<section anchor="conventions-and-terminology" numbered="true" toc="default ">
	<name>Conventions and Terminology</name>		<name>Conventions and Terminology</name>
	<t>		<t>
	Throughout this document the acronym "EKM" is used to refer to		Throughout this document, the acronym "EKM" is used to refer to
	Exported Keying Material as defined in <xref target="RFC5705"/>.		"Exported Keying Material" as defined in <xref target="RFC5705"/>.
	</t>		</t>
	<t>		<t>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"OPTIONAL" in this document are to be interpreted as described in BCP		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	14 <xref target="RFC2119" format="default"/> <xref target="RFC8174"		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	format="default"/> when, and only when, they appear in all capitals,		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	as shown here.		be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="tls-exporter" numbered="true" toc="default">		<section anchor="tls-exporter" numbered="true" toc="default">
	<name>The 'tls-exporter' Channel Binding Type</name>		<name>The 'tls-exporter' Channel Binding Type</name>
	<t>		<t>
	Channel binding mechanisms are not useful until TLS implementations		Channel binding mechanisms are not useful until TLS implementations
	expose the required data.		expose the required data. To facilitate this, "tls-exporter" uses
	To facilitate this, "tls-exporter" uses exported keying material (EKM)		Exported Keying Material (EKM), which is already widely exposed by TLS
	which is already widely exposed by TLS implementations.		implementations. The EKM is obtained using the keying material
	The EKM is obtained using the keying material exporters for TLS as		exporters for TLS, as defined in <xref target="RFC5705"/> and <xref
	defined in <xref target="RFC5705"/> and <xref target="RFC8446"/> section		target="RFC8446" sectionFormat="of" section="7.5"/>, by supplying the
	7.5 by supplying the following inputs:		following inputs:
	</t>		</t>
	<dl>		<dl>
	<dt>Label:</dt>		<dt>Label:</dt>
	<dd>		<dd>
	The ASCII string "EXPORTER-Channel-Binding" with no terminating NUL.		The ASCII string "EXPORTER-Channel-Binding" with no terminating NUL.
	</dd>		</dd>
	<dt>Context value:</dt>		<dt>Context value:</dt>
	<dd>		<dd>
	Zero-length string.		Zero-length string.
	</dd>		</dd>
	<dt>Length:</dt>		<dt>Length:</dt>
	<dd>		<dd>
	32 bytes.		32 bytes.
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	This channel binding mechanism is defined only when the TLS handshake		This channel binding mechanism is defined only when the TLS handshake
	results in unique master secrets. This is true of TLS versions prior to		results in unique master secrets. This is true of TLS versions prior to
	1.3 when the extended master secret extension of		1.3 when the extended master secret extension of
	<xref target="RFC7627"/> is in use, and is always true for TLS 1.3		<xref target="RFC7627"/> is in use, and it is always true for TLS 1.3
	(see <xref target="RFC8446"/> appendix D).		(see <xref target="RFC8446" sectionFormat="of" section="D"/>).
	</t>		</t>
	</section>		</section>
	<section anchor="scram" numbered="true" toc="default">		<section anchor="scram" numbered="true" toc="default">
	<name>TLS 1.3 with SCRAM or GSS-API over SASL</name>		<name>TLS 1.3 with SCRAM or GSS-API over SASL</name>
	<t>		<t>
	SCRAM		The specifications for Salted Challenge Response Authentication Mechanis
	(<xref target="RFC5802"/>, and <xref target="RFC7677"/>)		m (SCRAM) <xref
	and GSS-API over SASL <xref target="RFC5801"/>		target="RFC5802"/> <xref target="RFC7677"/> and Generic Security
			Service Application Program Interface (GSS-API) over Simple
			Authentication and Security Layer (SASL) <xref target="RFC5801"/>
	define "tls-unique" as the default channel binding to use over TLS.		define "tls-unique" as the default channel binding to use over TLS.
	As "tls-unique" is not defined for TLS 1.3 (and greater), this document		As "tls-unique" is not defined for TLS 1.3 (and greater), this
	updates <xref target="RFC5801"/>, <xref target="RFC5802"/>, and		document updates <xref target="RFC5801"/>, <xref target="RFC5802"/>,
	<xref target="RFC7677"/> to use "tls-exporter" as the default channel		and <xref target="RFC7677"/> to use "tls-exporter" as the default
	binding over TLS 1.3 (and greater).		channel binding over TLS 1.3 (and greater).
	Note that this document does not change the default channel binding		Note that this document does not change the default channel
	for SCRAM mechanisms over TLS 1.2 <xref target="RFC5246"/>, which is		binding for SCRAM mechanisms over TLS 1.2 <xref target="RFC5246"/>,
	still "tls-unique".		which is still "tls-unique" (also note that RFC 5246 has been obsoleted
			by RFC 8446).
	</t>		</t>
	<t>		<t>
	Additionally, this document updates the aforementioned documents to make		Additionally, this document updates the aforementioned documents to make
	"tls-exporter" the mandatory to implement channel binding if any channel		"tls-exporter" the mandatory-to-implement channel binding if any channel
	bindings are implemented for TLS 1.3.		bindings are implemented for TLS 1.3.
	Implementations that support channel binding over TLS 1.3		Implementations that support channel binding over TLS 1.3
	<bcp14>MUST</bcp14> implement "tls-exporter".		<bcp14>MUST</bcp14> implement "tls-exporter".
	</t>		</t>
	</section>		</section>
	<section anchor="security-considerations" numbered="true" toc="default">		<section anchor="security-considerations" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	The channel binding type defined in this document is constructed so that		The channel binding type defined in this document is constructed so that
	disclosure of the channel binding data does not leak secret information		disclosure of the channel binding data does not leak secret information
	about the TLS channel and does not affect the security of the TLS		about the TLS channel and does not affect the security of the TLS
	channel.		channel.
	</t>		</t>
	<t>		<t>
	The derived data <bcp14>MUST NOT</bcp14> be used for any purpose other		The derived data <bcp14>MUST NOT</bcp14> be used for any purpose other
	than channel bindings as described in <xref target="RFC5056"/>.		than channel bindings as described in <xref target="RFC5056"/>.
	In particular, implementations MUST NOT use channel binding as a		In particular, implementations <bcp14>MUST NOT</bcp14> use channel bindi ng as a
	secret key to protect privileged information.		secret key to protect privileged information.
	</t>		</t>
	<t>		<t>
	The Security Considerations sections of <xref target="RFC5056"/>, <xref		The Security Considerations sections of <xref target="RFC5056"/>, <xref
	target="RFC5705"/>, and <xref target="RFC8446"/> apply to this document.		target="RFC5705"/>, and <xref target="RFC8446"/> apply to this document.
	</t>		</t>
	<section anchor="unique-bindings" numbered="true" toc="default">		<section anchor="unique-bindings" numbered="true" toc="default">
	<name>Uniqueness of Channel Bindings</name>		<name>Uniqueness of Channel Bindings</name>
	<t>		<t>
	The definition of channel bindings in <xref target="RFC5056"/>		The definition of channel bindings in <xref target="RFC5056"/>
	defines the concept of a "unique" channel binding as being one that		defines the concept of a "unique" channel binding as being one that
	is unique to the channel endpoints and unique over time, that is,		is unique to the channel endpoints and unique over time, that is,
	a value that is unique to a specific instance of the lower layer		a value that is unique to a specific instance of the lower-layer
	security protocol.		security protocol.
	When TLS is the lower layer security protocol, as for the channel		When TLS is the lower-layer security protocol, as for the channel bind
	binding type defined in this document, this concept of uniqueness		ing
			type defined in this document, this concept of uniqueness
	corresponds to uniquely identifying the specific TLS connection.		corresponds to uniquely identifying the specific TLS connection.
	</t>		</t>
	<t>		<t>
	However, a stronger form of uniqueness is possible, which would entail		However, a stronger form of uniqueness is possible, which would entail
	uniquely identifying not just the lower layer protocol but also the		uniquely identifying not just the lower-layer protocol but also the
	upper layer application or authentication protocol that is consuming		upper-layer application or authentication protocol that is consuming
	the channel binding.		the channel binding.
	The distinction is relevant only when there are multiple instances of		The distinction is relevant only when there are multiple instances of
	an authentication protocol, or multiple distinct authentication		an authentication protocol, or multiple distinct authentication
	protocols, that run atop the same lower layer protocol.		protocols, that run atop the same lower-layer protocol.
	Such a situation is rare -- most consumers of channel bindings		Such a situation is rare; most consumers of channel bindings
	establish an instance of the lower layer secure protocol, run a single		establish an instance of the lower-layer secure protocol, run a single
	application or authentication protocol as the upper layer protocol,		application or authentication protocol as the upper-layer protocol,
	then terminate both upper and lower layer protocols.		then terminate both upper and lower-layer protocols.
	In this situation the stronger form of uniqueness is trivially		In this situation, the stronger form of uniqueness is trivially
	achieved, given that the channel binding value is unique in the sense		achieved, given that the channel binding value is unique in the sense
	of <xref target="RFC5056"/>.		of <xref target="RFC5056"/>.
	</t>		</t>
	<t>		<t>
	The channel binding type defined by this document provides only the		The channel binding type defined by this document provides only the
	weaker type of uniqueness, as per <xref target="RFC5056"/>; it does		weaker type of uniqueness, as per <xref target="RFC5056"/>; it does
	not achieve the stronger uniqueness per upper layer protocol instance		not achieve the stronger uniqueness per the upper-layer protocol
	described above.		instance described above. This stronger form of uniqueness would be
	This stronger form of uniqueness would be useful in that it provides		useful in that it provides protection against cross-protocol attacks
	protection against cross-protocol attacks for the multiple		for the multiple authentication protocols running over the same
	authentication protocols running over the same instance of the lower		instance of the lower-layer protocol, and it provides protection
	layer protocol, and it provides protection against replay attacks that		against replay attacks that seek to replay a message from one
	seek to replay a message from one instance of an authentication		instance of an authentication protocol in a different instance of
	protocol in a different instance of the same authentication protocol,		the same authentication protocol, again running over the same
	again running over the same instance of the lower layer protocol.		instance of the lower-layer protocol. Both of these properties are
	Both of these properties are highly desirable when performing formal		highly desirable when performing formal analysis of upper-layer
	analysis of upper layer protocols; if these properties are not		protocols; if these properties are not provided, such formal
	provided, such formal analysis is essentially impossible.		analysis is essentially impossible. In some cases, one or both of
	In some cases one or both of these properties may already be provided		these properties may already be provided by specific upper-layer
	by specific upper layer protocols, but that is dependent on the		protocols, but that is dependent on the mechanism(s) in question,
	mechanism(s) in question, and formal analysis requires that the		and formal analysis requires that the property is provided in a
	property is provided in a generic manner, across all potential upper		generic manner across all potential upper-layer protocols that
	layer protocols that exist or might exist in the future.		exist or might exist in the future.
	</t>		</t>
	<t>		<t>
	Accordingly, applications that make use of the channel binding type		Accordingly, applications that make use of the channel binding type
	defined in this document <bcp14>MUST NOT</bcp14> use the channel		defined in this document <bcp14>MUST NOT</bcp14> use the channel
	binding for more than one authentication mechanism instance on a given		binding for more than one authentication mechanism instance on a given
	TLS connection.		TLS connection.
	Such applications <bcp14>MUST</bcp14> immediately close the TLS		Such applications <bcp14>MUST</bcp14> immediately close the TLS
	connection after the conclusion of the upper layer protocol.		connection after the conclusion of the upper-layer protocol.
	</t>		</t>
	</section>		</section>
	<section anchor="legacy-tls" numbered="true" toc="default">		<section anchor="legacy-tls" numbered="true" toc="default">
	<name>Use with Legacy TLS</name>		<name>Use with Legacy TLS</name>
	<t>		<t>
	While it is possible to use this channel binding mechanism with TLS		While it is possible to use this channel binding mechanism with TLS
	versions below 1.3, extra precaution must be taken to ensure that the		versions below 1.3, extra precaution must be taken to ensure that
	chosen cipher suites always result in unique master secrets.		the chosen cipher suites always result in unique master secrets.
	For more information see <xref target="RFC7627"/> and the Security		For more information, see <xref target="RFC7627"/> and the Security
	Considerations section of <xref target="RFC5705"/> (TLS 1.3 always		Considerations section of <xref target="RFC5705"/> (TLS 1.3 always
	provides unique master secrets, as discussed in Appendix D of		provides unique master secrets, as discussed in <xref
	<xref target="RFC8446"/>.)		target="RFC8446" sectionFormat="of" section="D"/>).
	</t>		</t>
	<t>		<t>
	When TLS renegotiation is enabled on a connection the "tls-exporter"		When TLS renegotiation is enabled on a connection, the "tls-exporter"
	channel binding type is not defined for that connection and		channel binding type is not defined for that connection, and
	implementations <bcp14>MUST NOT</bcp14> support it.		implementations <bcp14>MUST NOT</bcp14> support it.
	</t>		</t>
	<t>		<t>
	In general, users wishing to take advantage of channel binding should		In general, users wishing to take advantage of channel binding should
	upgrade to TLS 1.3 or later.		upgrade to TLS 1.3 or later.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<section anchor="cb-type-registration" numbered="true" toc="default">		<section anchor="cb-type-registration" numbered="true" toc="default">
	<name>Registration of Channel Binding Type</name>		<name>Registration of Channel Binding Type</name>
	<t>		<t>
	This document adds the following registration in the "Channel-Binding		IANA has registered tls-exporter in the "Channel-Binding
	Types" registry:		Types" registry:
	</t>		</t>
	<dl>		<dl>
	<dt>Subject:</dt>		<dt>Channel-binding unique prefix:</dt>
	<dd>Registration of channel binding tls-exporter</dd>
	<dt>Channel binding unique prefix:</dt>
	<dd>tls-exporter</dd>		<dd>tls-exporter</dd>
	<dt>Channel binding type:</dt>		<dt>Channel-binding type:</dt>
	<dd>unique</dd>		<dd>unique</dd>
	<dt>Channel type:</dt>		<dt>Channel type:</dt>
	<dd><xref target="RFC8446">TLS</xref></dd>		<dd>TLS <xref target="RFC8446"/></dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>&docName;</dd>		<dd>RFC 9266</dd>
	<dt>Channel binding is secret:</dt>		<dt>Channel-binding is secret:</dt>
	<dd>no</dd>		<dd>no</dd>
	<dt>Description:</dt>		<dt>Description:</dt>
	<dd>The EKM value obtained from the current TLS connection.</dd>		<dd>The EKM value obtained from the current TLS connection.</dd>
	<dt>Intended usage:</dt>		<dt>Intended usage:</dt>
	<dd>COMMON</dd>		<dd>COMMON</dd>
	<dt>		<dt>
	Person and email address to contact for further information:		Person and email address to contact for further information:
	</dt>		</dt>
	<dd>Sam Whited &lt;sam@samwhited.com&gt;.</dd>		<dd>Sam Whited &lt;sam@samwhited.com&gt;</dd>
	<dt>Owner/Change controller name and email address:</dt>		<dt>Owner/Change controller name and email address:</dt>
	<dd>IESG.</dd>		<dd>IESG</dd>
	<dt>Expert reviewer name and contact information:</dt>		<dt>Expert reviewer name and contact information:</dt>
	<dd>		<dd>
	IETF KITTEN or TLS WG (kitten@ietf.org or tls@ietf.org, failing		IETF KITTEN WG &lt;kitten@ietf.org&gt; or IETF TLS WG &lt;tls@ietf.o
	that, ietf@ietf.org).		rg&gt;
	</dd>		</dd>
	<dt>Note:</dt>		<dt>Note:</dt>
	<dd>		<dd>
	See the published specification for advice on the applicability of		See the published specification for advice on the applicability of
	this channel binding type.		this channel binding type.
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="exporter-registration" numbered="true" toc="default">		<section anchor="exporter-registration" numbered="true" toc="default">
	<name>Registration of Channel Binding TLS Exporter Label</name>		<name>Registration of Channel Binding TLS Exporter Label</name>
	<t>		<t>
	This document adds the following registration in the "TLS Exporter		IANA has added the following registration in the "TLS Exporter
	Labels" registry, which is part of the "Transport Layer Security (TLS)		Labels" registry under the "Transport Layer Security (TLS)
	Parameters" group:		Parameters" registry:
	</t>		</t>
	<dl>		<dl>
	<dt>Value:</dt>		<dt>Value:</dt>
	<dd>EXPORTER-Channel-Binding</dd>		<dd>EXPORTER-Channel-Binding</dd>
	<dt>DTLS-OK:</dt>		<dt>DTLS-OK:</dt>
	<dd>Y</dd>		<dd>Y</dd>
	<dt>Recommended:</dt>		<dt>Recommended:</dt>
	<dd>Y</dd>		<dd>Y</dd>
	<dt>Reference:</dt>		<dt>Reference:</dt>
	<dd>This document</dd>		<dd>RFC 9266</dd>
	</dl>		</dl>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 119.xml"/>		<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2 119.xml"/>
	skipping to change at line 320 ¶		skipping to change at line 329 ¶
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 802.xml"/>		<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 802.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 929.xml"/>		<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 929.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 677.xml"/>		<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 677.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 174.xml"/>		<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 174.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 446.xml"/>		<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8 446.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 246.xml"/>		<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 246.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 627.xml"/>		<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 627.xml"/>
	<reference anchor="TRIPLE-HANDSHAKE" target="https://www.mitls.org/pages
	/attacks/3SHAKE">		<reference anchor="TRIPLE-HANDSHAKE" target="https://www.mitls.org/pages/attacks
			/3SHAKE">
	<front>		<front>
	<title>Password Storage</title>		<title>Triple Handshakes Considered Harmful: Breaking and Fixing Aut hentication over TLS</title>
	<author initials="K." surname="Bhargavan"/>		<author initials="K." surname="Bhargavan"/>
	<author initials="A." surname="Delignat-Lavaud"/>		<author initials="A." surname="Delignat-Lavaud"/>
	<author initials="C." surname="Fournet"/>		<author initials="C." surname="Fournet"/>
	<author initials="A." surname="Pironti"/>		<author initials="A." surname="Pironti"/>
	<author initials="P." surname="Strub"/>		<author initials="P." surname="Strub"/>
	<date year="2014" month="March"/>		<date year="2014" month="March"/>
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
End of changes. 42 change blocks.
	103 lines changed or deleted		120 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/