draft-ietf-quic-tls-24.txt		draft-ietf-quic-tls-latest.txt
	QUIC Working Group M. Thomson, Ed.		QUIC Working Group M. Thomson, Ed.
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track S. Turner, Ed.		Intended status: Standards Track S. Turner, Ed.
	Expires: May 7, 2020 sn3rd		Expires: June 7, 2020 sn3rd
	November 4, 2019		December 5, 2019
	Using TLS to Secure QUIC		Using TLS to Secure QUIC
	draft-ietf-quic-tls-24		draft-ietf-quic-tls-latest
	Abstract		Abstract
	This document describes how Transport Layer Security (TLS) is used to		This document describes how Transport Layer Security (TLS) is used to
	secure QUIC.		secure QUIC.
	Note to Readers		Note to Readers
	Discussion of this draft takes place on the QUIC working group		Discussion of this draft takes place on the QUIC working group
	mailing list (quic@ietf.org), which is archived at		mailing list (quic@ietf.org), which is archived at
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 May 7, 2020.		This Internet-Draft will expire on June 7, 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 9, line 8 ¶		skipping to change at page 9, line 8 ¶
	Some frames are prohibited in different encryption levels, others		Some frames are prohibited in different encryption levels, others
	cannot be sent. The rules here generalize those of TLS, in that		cannot be sent. The rules here generalize those of TLS, in that
	frames associated with establishing the connection can usually appear		frames associated with establishing the connection can usually appear
	at any encryption level, whereas those associated with transferring		at any encryption level, whereas those associated with transferring
	data can only appear in the 0-RTT and 1-RTT encryption levels:		data can only appear in the 0-RTT and 1-RTT encryption levels:
	o PADDING and PING frames MAY appear in packets of any encryption		o PADDING and PING frames MAY appear in packets of any encryption
	level.		level.
	o CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any		o CRYPTO frames and CONNECTION_CLOSE frames signaling errors at the
	encryption level except 0-RTT.		QUIC layer (type 0x1c) MAY appear in packets of any encryption
			level except 0-RTT.
			o CONNECTION_CLOSE frames signaling application errors (type 0x1d)
			MUST only be sent in packets at the 1-RTT encryption level.
	o ACK frames MAY appear in packets of any encryption level other		o ACK frames MAY appear in packets of any encryption level other
	than 0-RTT, but can only acknowledge packets which appeared in		than 0-RTT, but can only acknowledge packets which appeared in
	that packet number space.		that packet number space.
	o All other frame types MUST only be sent in the 0-RTT and 1-RTT		o All other frame types MUST only be sent in the 0-RTT and 1-RTT
	levels.		levels.
	Note that it is not possible to send the following frames in 0-RTT		Note that it is not possible to send the following frames in 0-RTT
	for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and		for various reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and
	skipping to change at page 34, line 29 ¶		skipping to change at page 34, line 29 ¶
	QUIC uses the TLS handshake for more than just negotiation of		QUIC uses the TLS handshake for more than just negotiation of
	cryptographic parameters. The TLS handshake provides preliminary		cryptographic parameters. The TLS handshake provides preliminary
	values for QUIC transport parameters and allows a server to perform		values for QUIC transport parameters and allows a server to perform
	return routability checks on clients.		return routability checks on clients.
	8.1. Protocol Negotiation		8.1. Protocol Negotiation
	QUIC requires that the cryptographic handshake provide authenticated		QUIC requires that the cryptographic handshake provide authenticated
	protocol negotiation. TLS uses Application Layer Protocol		protocol negotiation. TLS uses Application Layer Protocol
	Negotiation (ALPN) [RFC7301] to select an application protocol.		Negotiation (ALPN) [ALPN] to select an application protocol. Unless
	Unless another mechanism is used for agreeing on an application		another mechanism is used for agreeing on an application protocol,
	protocol, endpoints MUST use ALPN for this purpose. When using ALPN,		endpoints MUST use ALPN for this purpose. When using ALPN, endpoints
	endpoints MUST immediately close a connection (see Section 10.3 in		MUST immediately close a connection (see Section 10.3 in
	[QUIC-TRANSPORT]) if an application protocol is not negotiated with a		[QUIC-TRANSPORT]) if an application protocol is not negotiated with a
	no_application_protocol TLS alert (QUIC error code 0x178, see		no_application_protocol TLS alert (QUIC error code 0x178, see
	Section 4.9). While [RFC7301] only specifies that servers use this		Section 4.9). While [ALPN] only specifies that servers use this
	alert, QUIC clients MUST also use it to terminate a connection when		alert, QUIC clients MUST also use it to terminate a connection when
	ALPN negotiation fails.		ALPN negotiation fails.
	An application-layer protocol MAY restrict the QUIC versions that it		An application protocol MAY restrict the QUIC versions that it can
	can operate over. Servers MUST select an application protocol		operate over. Servers MUST select an application protocol compatible
	compatible with the QUIC version that the client has selected. If		with the QUIC version that the client has selected. The server MUST
	the server cannot select a compatible combination of application		treat the inability to select a compatible application protocol as a
	protocol and QUIC version, it MUST abort the connection. A client		connection error of type 0x178 (no_application_protocol). Similarly,
	MUST abort a connection if the server picks an application protocol		a client MUST treat the selection of an incompatible application
	incompatible with the protocol version being used.		protocol by a server as a connection error of type 0x178.
	8.2. QUIC Transport Parameters Extension		8.2. QUIC Transport Parameters Extension
	QUIC transport parameters are carried in a TLS extension. Different		QUIC transport parameters are carried in a TLS extension. Different
	versions of QUIC might define a different method for negotiating		versions of QUIC might define a different method for negotiating
	transport configuration.		transport configuration.
	Including transport parameters in the TLS handshake provides		Including transport parameters in the TLS handshake provides
	integrity protection for these values.		integrity protection for these values.
	skipping to change at page 39, line 33 ¶		skipping to change at page 39, line 33 ¶
	The initial secrets use a key that is specific to the negotiated QUIC		The initial secrets use a key that is specific to the negotiated QUIC
	version. New QUIC versions SHOULD define a new salt value used in		version. New QUIC versions SHOULD define a new salt value used in
	calculating initial secrets.		calculating initial secrets.
	10. IANA Considerations		10. IANA Considerations
	This document does not create any new IANA registries, but it		This document does not create any new IANA registries, but it
	registers the values in the following registries:		registers the values in the following registries:
	o TLS ExtensionsType Registry [TLS-REGISTRIES] - IANA is to register		o TLS ExtensionType Values Registry [TLS-REGISTRIES] - IANA is to
	the quic_transport_parameters extension found in Section 8.2. The		register the quic_transport_parameters extension found in
	Recommended column is to be marked Yes. The TLS 1.3 Column is to		Section 8.2. The Recommended column is to be marked Yes. The TLS
	include CH and EE.		1.3 Column is to include CH and EE.
	o QUIC Error Codes Registry [QUIC-TRANSPORT] - IANA is to register		o QUIC Transport Error Codes Registry [QUIC-TRANSPORT] - IANA is to
	the KEY_UPDATE_ERROR (0xE), as described in Section 6.7.		register the KEY_UPDATE_ERROR (0xE), as described in Section 6.7.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated		[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,		Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
	<https://www.rfc-editor.org/info/rfc5116>.		<https://www.rfc-editor.org/info/rfc5116>.
	[AES] "Advanced encryption standard (AES)", National Institute		[AES] "Advanced encryption standard (AES)", National Institute
	of Standards and Technology report,		of Standards and Technology report,
	DOI 10.6028/nist.fips.197, November 2001.		DOI 10.6028/nist.fips.197, November 2001.
			[ALPN] 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>.
	[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF		[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,		Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
	<https://www.rfc-editor.org/info/rfc8439>.		<https://www.rfc-editor.org/info/rfc8439>.
	[QUIC-RECOVERY]		[QUIC-RECOVERY]
	Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection		Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
	and Congestion Control", draft-ietf-quic-recovery-24 (work		and Congestion Control", draft-ietf-quic-recovery-latest
	in progress).		(work in progress).
	[QUIC-TRANSPORT]		[QUIC-TRANSPORT]
	Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", draft-ietf-quic-		Multiplexed and Secure Transport", draft-ietf-quic-
	transport-24 (work in progress).		transport-latest (work in progress).
	[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>.
	[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>.
	[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>.
	[SHA] Dang, Q., "Secure Hash Standard", National Institute of		[SHA] Dang, Q., "Secure Hash Standard", National Institute of
	Standards and Technology report,		Standards and Technology report,
	DOI 10.6028/nist.fips.180-4, July 2015.		DOI 10.6028/nist.fips.180-4, July 2015.
	[TLS-REGISTRIES]		[TLS-REGISTRIES]
	Salowey, J. and S. Turner, "IANA Registry Updates for TLS		Salowey, J. and S. Turner, "IANA Registry Updates for TLS
	skipping to change at page 41, line 19 ¶		skipping to change at page 41, line 19 ¶
	[IMC] Katz, J. and Y. Lindell, "Introduction to Modern		[IMC] Katz, J. and Y. Lindell, "Introduction to Modern
	Cryptography, Second Edition", ISBN 978-1466570269,		Cryptography, Second Edition", ISBN 978-1466570269,
	November 2014.		November 2014.
	[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:		[NAN] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
	AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.		AEAD Revisited", Advances in Cryptology - CRYPTO 2019 pp.
	235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.		235-265, DOI 10.1007/978-3-030-26948-7_9, 2019.
	[QUIC-HTTP]		[QUIC-HTTP]
	Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over		Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over
	QUIC", draft-ietf-quic-http-24 (work in progress).		QUIC", draft-ietf-quic-http-latest (work in progress).
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<https://www.rfc-editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	skipping to change at page 43, line 22 ¶		skipping to change at page 43, line 22 ¶
	4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006		4131a0e8f309a1d0b9c4000006130113 031302010000910000000b0009000006
	736572766572ff01000100000a001400 12001d00170018001901000101010201		736572766572ff01000100000a001400 12001d00170018001901000101010201
	03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f		03010400230000003300260024001d00 204cfdfcd178b784bf328cae793b136f
	2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403		2aedce005ff183d7bb14952072366470 37002b0003020304000d0020001e0403
	05030603020308040805080604010501 060102010402050206020202002d0002		05030603020308040805080604010501 060102010402050206020202002d0002
	0101001c00024001		0101001c00024001
	The unprotected header includes the connection ID and a 4 byte packet		The unprotected header includes the connection ID and a 4 byte packet
	number encoding for a packet number of 2:		number encoding for a packet number of 2:
	c3ff000017088394c8f03e5157080000449e00000002		c3ff000019088394c8f03e5157080000449e00000002
	Protecting the payload produces output that is sampled for header		Protecting the payload produces output that is sampled for header
	protection. Because the header uses a 4 byte packet number encoding,		protection. Because the header uses a 4 byte packet number encoding,
	the first 16 bytes of the protected payload is sampled, then applied		the first 16 bytes of the protected payload is sampled, then applied
	to the header:		to the header:
	sample = 535064a4268a0d9d7b1c9d250ae35516		sample = 535064a4268a0d9d7b1c9d250ae35516
	mask = AES-ECB(hp, sample)[0..4]		mask = AES-ECB(hp, sample)[0..4]
	= 833b343aaa		= 833b343aaa
	header[0] ^= mask[0] & 0x0f		header[0] ^= mask[0] & 0x0f
	= c0		= c0
	header[17..20] ^= mask[1..4]		header[18..21] ^= mask[1..4]
	= 3b343aa8		= 3b343aa8
	header = c0ff000017088394c8f03e5157080000449e3b343aa8		header = c0ff000019088394c8f03e5157080000449e3b343aa8
	The resulting protected packet is:		The resulting protected packet is:
	c0ff000017088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c		c0ff000019088394c8f03e5157080000 449e3b343aa8535064a4268a0d9d7b1c
	9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752		9d250ae355162276e9b1e3011ef6bbc0 ab48ad5bcc2681e953857ca62becd752
	4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec		4daac473e68d7405fbba4e9ee616c870 38bdbe908c06d9605d9ac49030359eec
	b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f		b1d05a14e117db8cede2bb09d0dbbfee 271cb374d8f10abec82d0f59a1dee29f
	e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d		e95638ed8dd41da07487468791b719c5 5c46968eb3b54680037102a28e53dc1d
	12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6		12903db0af5821794b41c4a93357fa59 ce69cfe7f6bdfa629eef78616447e1d6
	11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50		11c4baf71bf33febcb03137c2c75d253 17d3e13b684370f668411c0f00304b50
	1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008		1c8fd422bd9b9ad81d643b20da89ca05 25d24d2b142041cae0af205092e43008
	0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f		0cd8559ea4c5c6e4fa3f66082b7d303e 52ce0162baa958532b0bbc2bc785681f
	cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724		cf37485dff6595e01e739c8ac9efba31 b985d5f656cc092432d781db95221724
	87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d		87641c4d3ab8ece01e39bc85b1543661 4775a98ba8fa12d46f9b35e2a55eb72d
	skipping to change at page 44, line 42 ¶		skipping to change at page 44, line 42 ¶
	93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9		93a5d0638d32fc51c5c65ff291a3a7a5 2fd6775e623a4439cc08dd25582febc9
	44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14		44ef92d8dbd329c91de3e9c9582e41f1 7f3d186f104ad3f90995116c682a2a14
	a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5		a3b4b1f547c335f0be710fc9fc03e0e5 87b8cda31ce65b969878a4ad4283e6d5
	b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6		b0373f43da86e9e0ffe1ae0fddd35162 55bd74566f36a38703d5f34249ded1f6
	6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e		6b3d9b45b9af2ccfefe984e13376b1b2 c6404aa48c8026132343da3f3a33659e
	c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e		c1b3e95080540b28b7f3fcd35fa5d843 b579a84c089121a60d8c1754915c344e
	eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f		eaf45a9bf27dc0c1e784161691220913 13eb0e87555abd706626e557fc36a04f
	cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da		cd191a58829104d6075c5594f627ca50 6bf181daec940f4a4f3af0074eee89da
	acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc		acde6758312622d4fa675b39f728e062 d2bee680d8f41a597c262648bb18bcfc
	13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d		13c8b3d97b1a77b2ac3af745d61a34cc 4709865bac824a94bb19058015e4e42d
	c9be6c7803567321829dd85853396269		aebe13f98ec51170a4aad0a8324bb768
	A.3. Server Initial		A.3. Server Initial
	The server sends the following payload in response, including an ACK		The server sends the following payload in response, including an ACK
	frame, a CRYPTO frame, and no PADDING frames:		frame, a CRYPTO frame, and no PADDING frames:
	0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988		0d0000000018410a020000560303eefc e7f7b37ba1d1632e96677825ddf73988
	cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d		cfc79825df566dc5430b9a045a120013 0100002e00330024001d00209d3c940d
	89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002		89690b84d08a60993c144eca684d1081 287c834d5311bcf32bb9da1a002b0002
	0304		0304
	The header from the server includes a new connection ID and a 2-byte		The header from the server includes a new connection ID and a 2-byte
	packet number encoding for a packet number of 1:		packet number encoding for a packet number of 1:
	c1ff0000170008f067a5502a4262b50040740001		c1ff0000190008f067a5502a4262b50040740001
	As a result, after protection, the header protection sample is taken		As a result, after protection, the header protection sample is taken
	starting from the third protected octet:		starting from the third protected octet:
	sample = 7002596f99ae67abf65a5852f54f58c3		sample = 7002596f99ae67abf65a5852f54f58c3
	mask = 38168a0c25		mask = 38168a0c25
	header = c9ff0000170008f067a5502a4262b5004074168b		header = c9ff0000190008f067a5502a4262b5004074168b
	The final protected packet is then:		The final protected packet is then:
	c9ff0000170008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a		c9ff0000190008f067a5502a4262b500 4074168bf22b7002596f99ae67abf65a
	5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493		5852f54f58c37c808682e2e40492d8a3 899fb04fc0afe9aabc8767b18a0aa493
	537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3		537426373b48d502214dd856d63b78ce e37bc664b3fe86d487ac7a77c53038a3
	cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b9cf9bb6d091ddfc8b32d		cd32f0b5004d9f5754c4f7f2d1f35cf3 f7116351c92b99c8ae5833225cb51855
	432348a2c413		20d61e68cf5f
	Appendix B. Change Log		Appendix B. Change Log
	*RFC Editor's Note:* Please remove this section prior to		*RFC Editor's Note:* Please remove this section prior to
	publication of a final version of this document.		publication of a final version of this document.
	Issue and pull request numbers are listed with a leading octothorp.		Issue and pull request numbers are listed with a leading octothorp.
	B.1. Since draft-ietf-quic-tls-23		B.1. Since draft-ietf-quic-tls-23
End of changes. 23 change blocks.
	43 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/