draft-ietf-uta-tls-attacks-05.txt		rfc7457.txt
	uta Y. Sheffer		Internet Engineering Task Force (IETF) Y. Sheffer
	Internet-Draft Porticor		Request for Comments: 7457 Porticor
	Intended status: Informational R. Holz		Category: Informational R. Holz
	Expires: April 26, 2015 TUM		ISSN: 2070-1721 Technische Universitaet Muenchen
	P. Saint-Andre		P. Saint-Andre
	&yet		&yet
	October 23, 2014		February 2015
	Summarizing Known Attacks on TLS and DTLS		Summarizing Known Attacks on Transport Layer Security (TLS)
	draft-ietf-uta-tls-attacks-05		and Datagram TLS (DTLS)
	Abstract		Abstract
	Over the last few years there have been several serious attacks on		Over the last few years, there have been several serious attacks on
	Transport Layer Security (TLS), including attacks on its most		Transport Layer Security (TLS), including attacks on its most
	commonly used ciphers and modes of operation. This document		commonly used ciphers and modes of operation. This document
	summarizes these attacks, with the goal of motivating generic and		summarizes these attacks, with the goal of motivating generic and
	protocol-specific recommendations on the usage of TLS and Datagram		protocol-specific recommendations on the usage of TLS and Datagram
	TLS (DTLS).		TLS (DTLS).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on April 26, 2015.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7457.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
			1. Introduction ....................................................3
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Attacks on TLS ..................................................3
	2. Attacks on TLS . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. SSL Stripping ..............................................3
	2.1. SSL Stripping . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. STARTTLS Command Injection Attack (CVE-2011-0411) ..........4
	2.2. STARTTLS Command Injection Attack (CVE-2011-0411) . . . . . 3		2.3. BEAST (CVE-2011-3389) ......................................4
	2.3. BEAST (CVE-2011-3389) . . . . . . . . . . . . . . . . . . . 4		2.4. Padding Oracle Attacks .....................................4
	2.4. Padding Oracle Attacks . . . . . . . . . . . . . . . . . . 4		2.5. Attacks on RC4 .............................................5
	2.5. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . . . 4		2.6. Compression Attacks: CRIME, TIME, and BREACH ...............5
	2.6. Compression Attacks: CRIME, TIME and BREACH . . . . . . . . 5		2.7. Certificate and RSA-Related Attacks ........................5
	2.7. Certificate and RSA-Related Attacks . . . . . . . . . . . . 5		2.8. Theft of RSA Private Keys ..................................6
	2.8. Theft of RSA Private Keys . . . . . . . . . . . . . . . . . 6		2.9. Diffie-Hellman Parameters ..................................6
	2.9. Diffie-Hellman Parameters . . . . . . . . . . . . . . . . . 6		2.10. Renegotiation (CVE-2009-3555) .............................6
	2.10. Renegotiation (CVE-2009-3555) . . . . . . . . . . . . . . . 6		2.11. Triple Handshake (CVE-2014-1295) ..........................6
	2.11. Triple Handshake (CVE-2014-1295) . . . . . . . . . . . . . 6		2.12. Virtual Host Confusion ....................................7
	2.12. Virtual Host Confusion . . . . . . . . . . . . . . . . . . 7		2.13. Denial of Service .........................................7
	2.13. Denial of Service . . . . . . . . . . . . . . . . . . . . . 7		2.14. Implementation Issues .....................................7
	2.14. Implementation Issues . . . . . . . . . . . . . . . . . . . 7		2.15. Usability .................................................8
	2.15. Usability . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Applicability to DTLS ...........................................8
	3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations .........................................8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. Informative References ..........................................8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		Acknowledgements ..................................................13
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses ................................................13
	7. Informative References . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . 12
	A.1. draft-ietf-uta-tls-attacks-05 . . . . . . . . . . . . . . . 13
	A.2. draft-ietf-uta-tls-attacks-04 . . . . . . . . . . . . . . . 13
	A.3. draft-ietf-uta-tls-attacks-03 . . . . . . . . . . . . . . . 13
	A.4. draft-ietf-uta-tls-attacks-02 . . . . . . . . . . . . . . . 13
	A.5. draft-ietf-uta-tls-attacks-01 . . . . . . . . . . . . . . . 13
	A.6. draft-ietf-uta-tls-attacks-00 . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Over the last few years there have been several major attacks on		Over the last few years, there have been several major attacks on TLS
	Transport Layer Security (TLS) [RFC5246], including attacks on its		[RFC5246], including attacks on its most commonly used ciphers and
	most commonly used ciphers and modes of operation. Details are given		modes of operation. Details are given in Section 2, but a quick
	in Section 2, but a quick summary is that both AES-CBC and RC4, which		summary is that both AES-CBC and RC4, which together make up for most
	together make up for most current usage, have been seriously attacked		current usage, have been seriously attacked in the context of TLS.
	in the context of TLS.
	This situation was one of the motivations for the creation of the UTA		This situation was one of the motivations for the creation of the UTA
	working group, which was tasked with the creation of generic and		working group, which was tasked with the creation of generic and
	protocol-specific recommendations for the use of TLS along with		protocol-specific recommendations for the use of TLS and DTLS
	Datagram TLS (DTLS) [RFC6347] (unless otherwise noted under		[RFC6347] (unless otherwise noted under Section 3, all of the
	Section 3, all of the information provided in this document applies		information provided in this document applies to DTLS).
	to DTLS).
	"Attacks always get better; they never get worse" (ironically, this		There is an old saying attributed, ironically enough, to the US
	saying is attributed to the U.S. National Security Agency, the NSA).		National Security Agency (NSA): "Attacks always get better; they
	This attacks summarized in this document reflect our knowledge as of		never get worse." Unfortunately, that saying is true, so any
	this writing. It seems likely that new attacks will be discovered in		description of security attacks can only be a snapshot in time.
	the future.		Therefore this document reflects our knowledge as of this writing.
			It seems likely that new attacks will be discovered in the future.
	For a more detailed discussion of the attacks listed here, the		For a more detailed discussion of the attacks listed here, the
	interested reader is referred to [Attacks-iSec].		interested reader is referred to [Attacks-iSec].
	2. Attacks on TLS		2. Attacks on TLS
	This section lists the attacks that motivated the current		This section lists the attacks that motivated the current
	recommendations in [I-D.ietf-uta-tls-bcp]. This list is not intended		recommendations in [SECURE-TLS]. This list is not intended to be an
	to be an extensive survey of the security of TLS.		extensive survey of the security of TLS.
	While there are widely deployed mitigations for some of the attacks		While there are widely deployed mitigations for some of the attacks
	listed below, we believe that their root causes necessitate a more		listed below, we believe that their root causes necessitate a more
	systematic solution, which we have attempted to develop in		systematic solution, which we have attempted to develop in
	[I-D.ietf-uta-tls-bcp].		[SECURE-TLS].
	When an identifier exists for an attack, we have included its CVE		When an identifier exists for an attack, we have included its Common
	(Common Vulnerabilities and Exposures) ID. CVE [CVE] is an		Vulnerabilities and Exposures (CVE) ID. CVE [CVE] is an extensive,
	extensive, industry-wide database of software vulnerabilities.		industry-wide database of software vulnerabilities.
	2.1. SSL Stripping		2.1. SSL Stripping
	Various attacks attempt to remove the use of SSL/TLS altogether, by		Various attacks attempt to remove the use of Secure Socket Layer /
	modifying unencrypted protocols that request the use of TLS,		Transport Layer Security (SSL/TLS) altogether by modifying
	specifically modifying HTTP traffic and HTML pages as they pass on		unencrypted protocols that request the use of TLS, specifically
	the wire. These attacks are known collectively as SSL Stripping (a		modifying HTTP traffic and HTML pages as they pass on the wire.
	form of the more generic "downgrade attack") and were first		These attacks are known collectively as "SSL Stripping" (a form of
	introduced by Moxie Marlinspike [SSL-Stripping]. In the context of		the more generic "downgrade attack") and were first introduced by
	Web traffic, these attacks are only effective if the client initially		Moxie Marlinspike [SSL-Stripping]. In the context of Web traffic,
	accesses a Web server using HTTP. A commonly used mitigation is HTTP		these attacks are only effective if the client initially accesses a
	Strict Transport Security (HSTS) [RFC6797].		Web server using HTTP. A commonly used mitigation is HTTP Strict
			Transport Security (HSTS) [RFC6797].
	2.2. STARTTLS Command Injection Attack (CVE-2011-0411)		2.2. STARTTLS Command Injection Attack (CVE-2011-0411)
	Similarly, there are attacks on the transition between unprotected		Similarly, there are attacks on the transition between unprotected
	and TLS-protected traffic. A number of IETF application protocols		and TLS-protected traffic. A number of IETF application protocols
	have used an application-level command, usually STARTTLS, to upgrade		have used an application-level command, usually STARTTLS, to upgrade
	a clear-text connection to use TLS. Multiple implementations of		a cleartext connection to use TLS. Multiple implementations of
	STARTTLS had a flaw where an application-layer input buffer retained		STARTTLS had a flaw where an application-layer input buffer retained
	commands that were pipelined with the STARTTLS command, such that		commands that were pipelined with the STARTTLS command, such that
	commands received prior to TLS negotiation are executed after TLS		commands received prior to TLS negotiation are executed after TLS
	negotiation. This problem is resolved by requiring the application-		negotiation. This problem is resolved by requiring the application-
	level command input buffer to be empty before negotiating TLS. Note		level command input buffer to be empty before negotiating TLS. Note
	that this flaw lives in the application layer code and does not		that this flaw lives in the application layer code and does not
	impact the TLS protocol directly.		impact the TLS protocol directly.
	STARTLS and similar mechanisms are vulnerable to downgrade attacks		STARTTLS and similar mechanisms are vulnerable to downgrade attacks,
	whereby the attacker simply removes the STARTTLS indication from the		whereby the attacker simply removes the STARTTLS indication from the
	(unprotected) request. This cannot be mitigated unless HSTS-like		(unprotected) request. This cannot be mitigated unless HSTS-like
	solutions are added.		solutions are added.
	2.3. BEAST (CVE-2011-3389)		2.3. BEAST (CVE-2011-3389)
	The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation		The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation
	of CBC (that is, the predictable initialization vector) to decrypt		of Cipher Block Chaining (CBC) (that is, the predictable
	parts of a packet, and specifically to decrypt HTTP cookies when HTTP		initialization vector) to decrypt parts of a packet, and specifically
	is run over TLS.		to decrypt HTTP cookies when HTTP is run over TLS.
	2.4. Padding Oracle Attacks		2.4. Padding Oracle Attacks
	A consequence of the MAC-then-encrypt design in all current versions		A consequence of the MAC-then-encrypt design in all current versions
	of TLS is the existence of padding oracle attacks [Padding-Oracle].		of TLS is the existence of padding oracle attacks [Padding-Oracle].
	A recent incarnation of these attacks is the Lucky Thirteen attack		A recent incarnation of these attacks is the Lucky Thirteen attack
	(CVE-2013-0169) [CBC-Attack], a timing side-channel attack that		(CVE-2013-0169) [CBC-Attack], a timing side-channel attack that
	allows the attacker to decrypt arbitrary ciphertext.		allows the attacker to decrypt arbitrary ciphertext.
	The Lucky Thirteen attack can be mitigated by using authenticated		The Lucky Thirteen attack can be mitigated by using authenticated
	encryption like AES-GCM [RFC5288] or encrypt-then-mac		encryption like AES-GCM [RFC5288] or encrypt-then-MAC [RFC7366]
	[I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC-		instead of the TLS default of MAC-then-encrypt.
	then-encrypt.
	An even newer variant of the padding oracle attack, one that does not		An even newer variant of the padding oracle attack, one that does not
	use timing information, is the POODLE attack (CVE-2014-3566) [POODLE]		use timing information, is the POODLE attack (CVE-2014-3566) [POODLE]
	on SSL 3.0. This attack has no known mitigation.		on SSL 3.0. This attack has no known mitigation.
	2.5. Attacks on RC4		2.5. Attacks on RC4
	The RC4 algorithm [RC4] has been used with TLS (and previously, SSL)		The RC4 algorithm [RC4] has been used with TLS (and previously, SSL)
	for many years. RC4 has long been known to have a variety of		for many years. RC4 has long been known to have a variety of
	cryptographic weaknesses, e.g. [RC4-Attack-Pau], [RC4-Attack-Man],		cryptographic weaknesses, e.g., [RC4-Attack-Pau], [RC4-Attack-Man],
	[RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF]		and [RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF]
	exploit biases in the RC4 keystream to recover repeatedly encrypted		exploit biases in the RC4 keystream to recover repeatedly encrypted
	plaintexts.		plaintexts.
	These recent results are on the verge of becoming practically		These recent results are on the verge of becoming practically
	exploitable; currently they require 2^26 sessions or 13x2^30		exploitable; currently they require 2^26 sessions or 13x2^30
	encryptions. As a result, RC4 can no longer be seen as providing a		encryptions. As a result, RC4 can no longer be seen as providing a
	sufficient level of security for TLS sessions. For further details,		sufficient level of security for TLS sessions. For further details,
	the reader is referred to [I-D.ietf-tls-prohibiting-rc4] and the		the reader is referred to [CIPHER-SUITES] and the references it
	references it cites.		cites.
	2.6. Compression Attacks: CRIME, TIME and BREACH		2.6. Compression Attacks: CRIME, TIME, and BREACH
	The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to		The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to
	decrypt ciphertext (specifically, cookies) when TLS is used with TLS		decrypt ciphertext (specifically, cookies) when TLS is used with TLS-
	level compression.		level compression.
	The TIME attack [TIME] and the later BREACH attack [BREACH] (CVE-		The TIME attack [TIME] and the later BREACH attack [BREACH] (CVE-
	2013-3587, though the number has not been officially allocated) both		2013-3587, though the number has not been officially allocated) both
	make similar use of HTTP-level compression to decrypt secret data		make similar use of HTTP-level compression to decrypt secret data
	passed in the HTTP response. We note that compression of the HTTP		passed in the HTTP response. We note that compression of the HTTP
	message body is much more prevalent than compression at the TLS		message body is much more prevalent than compression at the TLS
	level.		level.
	The former attack can be mitigated by disabling TLS compression. We		The TIME attack can be mitigated by disabling TLS compression. We
	are not aware of mitigations at the TLS protocol level to the latter		are not aware of mitigations at the TLS protocol level to the BREACH
	attack, and so application-level mitigations are needed (see		attack, and so application-level mitigations are needed (see
	[BREACH]). For example, implementations of HTTP that use CSRF tokens		[BREACH]). For example, implementations of HTTP that use Cross-Site
	will need to randomize them. Even the best practices and		Request Forgery (CSRF) tokens will need to randomize them. Even the
	recommendations from [I-D.ietf-uta-tls-bcp] are insufficient to		best practices and recommendations from [SECURE-TLS] are insufficient
	thwart this attack.		to thwart this attack.
	2.7. Certificate and RSA-Related Attacks		2.7. Certificate and RSA-Related Attacks
	There have been several practical attacks on TLS when used with RSA		There have been several practical attacks on TLS when used with RSA
	certificates (the most common use case). These include		certificates (the most common use case). These include
	[Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack		[Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack
	has been mitigated in TLS 1.0, the Klima attack relies on a version-		has been mitigated in TLS 1.0, the Klima attack, which relies on a
	check oracle is only mitigated by TLS 1.1.		version-check oracle, is only mitigated by TLS 1.1.
	The use of RSA certificates often involves exploitable timing issues		The use of RSA certificates often involves exploitable timing issues
	[Brumley03] (CVE-2003-0147), unless the implementation takes care to		[Brumley03] (CVE-2003-0147), unless the implementation takes care to
	explicitly eliminate them.		explicitly eliminate them.
	A recent certificate fuzzing tool [Brubaker2014using] uncovered		A recent certificate fuzzing tool [Brubaker2014using] uncovered
	numerous vulnerabilities in different TLS libraries, related to		numerous vulnerabilities in different TLS libraries related to
	certificate validation.		certificate validation.
	2.8. Theft of RSA Private Keys		2.8. Theft of RSA Private Keys
	When TLS is used with most non-Diffie Hellman cipher suites, it is		When TLS is used with most non-Diffie-Hellman cipher suites, it is
	sufficient to obtain the server's private key in order to decrypt any		sufficient to obtain the server's private key in order to decrypt any
	sessions (past and future) that were initiated with that server.		sessions (past and future) that were initiated with that server.
	This technique is used, for example, by the popular Wireshark network		This technique is used, for example, by the popular Wireshark network
	sniffer to inspect TLS-protected connections.		sniffer to inspect TLS-protected connections.
	It is known that stolen (or otherwise obtained) private keys have		It is known that stolen (or otherwise obtained) private keys have
	been used as part of large-scale monitoring [RFC7258] of certain		been used as part of large-scale monitoring [RFC7258] of certain
	servers.		servers.
	Such attacks can be mitigated by better protecting the private key,		Such attacks can be mitigated by better protecting the private key,
	e.g. using OS protections or dedicated hardware. Even more effective		e.g., using OS protections or dedicated hardware. Even more
	is the use of cipher suites that offer "forward secrecy", the		effective is the use of cipher suites that offer "forward secrecy",
	property that revealing a secret such as a private key does not		the property where revealing a secret such as a private key does not
	expose past or future sessions to a passive attacker.		expose past or future sessions to a passive attacker.
	2.9. Diffie-Hellman Parameters		2.9. Diffie-Hellman Parameters
	TLS allows the definition of ephemeral Diffie-Hellman and Elliptic		TLS allows the definition of ephemeral Diffie-Hellman (DH) and
	Curve Diffie-Hellman parameters in its respective key exchange modes.		Elliptic Curve Diffie-Hellman parameters in its respective key
	This results in an attack detailed in [Cross-Protocol]. Using		exchange modes. This results in an attack detailed in
	predefined DH groups, as proposed in		[Cross-Protocol]. Using predefined DH groups, as proposed in
	[I-D.ietf-tls-negotiated-ff-dhe], would mitigate this attack.		[FFDHE-TLS], would mitigate this attack.
	In addition, clients that do not properly verify the received		In addition, clients that do not properly verify the received
	parameters are exposed to man in the middle (MITM) attacks.		parameters are exposed to man-in-the-middle (MITM) attacks.
	Unfortunately the TLS protocol does not mandate this verification		Unfortunately, the TLS protocol does not mandate this verification
	(see [RFC6989] for analogous information for IPsec).		(see [RFC6989] for analogous information for IPsec).
	2.10. Renegotiation (CVE-2009-3555)		2.10. Renegotiation (CVE-2009-3555)
	A major attack on the TLS renegotiation mechanism applies to all		A major attack on the TLS renegotiation mechanism applies to all
	current versions of the protocol. The attack and the TLS extension		current versions of the protocol. The attack and the TLS extension
	that resolves it are described in [RFC5746].		that resolves it are described in [RFC5746].
	2.11. Triple Handshake (CVE-2014-1295)		2.11. Triple Handshake (CVE-2014-1295)
	The triple handshake attack [BhargavanDFPS14] enables the attacker to		The triple handshake attack [BhargavanDFPS14] enables the attacker to
	cause two TLS connections to share keying material. This leads to a		cause two TLS connections to share keying material. This leads to a
	multitude of attacks, e.g. Man-in-the-Middle, breaking safe		multitude of attacks, e.g., man-in-the-middle, breaking safe
	renegotiation, and breaking channel binding via TLS Exporter		renegotiation, and breaking channel binding via TLS Exporter
	[RFC5705] or "tls-unique" [RFC5929].		[RFC5705] or "tls-unique" [RFC5929].
	2.12. Virtual Host Confusion		2.12. Virtual Host Confusion
	A recent article [Delignat14] describes a security issue whereby		A recent article [Delignat14] describes a security issue whereby
	SSLv3 fallback and improper handling of session caches on the server		SSLv3 fallback and improper handling of session caches on the server
	side can be abused by an attacker to establish a malicious connection		side can be abused by an attacker to establish a malicious connection
	to a virtual host other than the one originally intended and approved		to a virtual host other than the one originally intended and approved
	by the server. This attack is especially serious in performance		by the server. This attack is especially serious in performance
	critical environments where sharing of SSLv3 session caches is very		critical environments where sharing of SSLv3 session caches is very
	common.		common.
	2.13. Denial of Service		2.13. Denial of Service
	Server CPU power has progressed over the years so that TLS can now be		Server CPU power has progressed over the years so that TLS can now be
	turned on by default. However, the risk of malicious clients and		turned on by default. However, the risk of malicious clients and
	coordinated groups of clients ("botnets") mounting denial of service		coordinated groups of clients ("botnets") mounting denial-of-service
	attacks is still very real. TLS adds another vector for		attacks is still very real. TLS adds another vector for
	computational attacks, since a client can easily (with little		computational attacks, since a client can easily (with little
	computational effort) force the server to expend relatively large		computational effort) force the server to expend relatively large
	computational work. It is known that such attacks have in fact been		computational work. It is known that such attacks have in fact been
	mounted.		mounted.
	2.14. Implementation Issues		2.14. Implementation Issues
	Even when the protocol is properly specified, this does not guarantee		Even when the protocol is properly specified, this does not guarantee
	the security of implementations. In fact there are very common		the security of implementations. In fact, there are very common
	issues that often plague TLS implementations. In particular, when		issues that often plague TLS implementations. In particular, when
	integrating into higher-level protocols, TLS and its PKI-based		integrating into higher-level protocols, TLS and its PKI-based
	authentication are sometimes the source of misunderstandings and		authentication are sometimes the source of misunderstandings and
	implementation "shortcuts". An extensive survey of these issues can		implementation "shortcuts". An extensive survey of these issues can
	be found in [Georgiev2012].		be found in [Georgiev2012].
	o Implementations might omit validation of the server certificate		o Implementations might omit validation of the server certificate
	altogether. For example, this is true of the default		altogether. For example, this is true of the default
	implementation of HTTP client libraries in Python 2 (see e.g.		implementation of HTTP client libraries in Python 2 (e.g., CVE-
	CVE-2013-2191).		2013-2191).
	o Implementations might not validate the server identity. This		o Implementations might not validate the server identity. This
	validation typically amounts to matching the protocol-level server		validation typically amounts to matching the protocol-level server
	name with the certificate's Subject Alternative Name field. Note:		name with the certificate's Subject Alternative Name field. Note:
	this same information is often also found in the Common Name part		this same information is often also found in the Common Name part
	of the Distinguished Name, and some validators incorrectly		of the Distinguished Name, and some validators incorrectly
	retrieve it from there instead of from the Subject Alternative		retrieve it from there instead of from the Subject Alternative
	Name.		Name.
	o Implementations might validate the certificate chain incorrectly		o Implementations might validate the certificate chain incorrectly
	skipping to change at page 8, line 14		skipping to change at page 8, line 14
	An implementation attack of a different kind, one that exploits a		An implementation attack of a different kind, one that exploits a
	simple coding mistake (bounds check), is the Heartbleed attack (CVE-		simple coding mistake (bounds check), is the Heartbleed attack (CVE-
	2014-0160) that affected a wide swath of the Internet when it was		2014-0160) that affected a wide swath of the Internet when it was
	discovered in April 2014.		discovered in April 2014.
	2.15. Usability		2.15. Usability
	Many TLS endpoints, such as browsers and mail clients, allow the user		Many TLS endpoints, such as browsers and mail clients, allow the user
	to explicitly accept an invalid server certificate. This often takes		to explicitly accept an invalid server certificate. This often takes
	the form of a UI dialog (e.g., "do you accept this server?") and		the form of a UI dialog (e.g., "do you accept this server?"), and
	users have been conditioned to respond in the affirmative in order to		users have been conditioned to respond in the affirmative in order to
	allow the connection to take place.		allow the connection to take place.
	This user behavior is used by (arguably legitimate) "SSL proxies"		This user behavior is used by (arguably legitimate) "SSL proxies"
	that decrypt and re-encrypt the TLS connection in order to enforce		that decrypt and re-encrypt the TLS connection in order to enforce
	local security policy. It is also abused by attackers whose goal is		local security policy. It is also abused by attackers whose goal is
	to gain access to the encrypted information.		to gain access to the encrypted information.
	Mitigation is complex and will probably involve a combination of		Mitigation is complex and will probably involve a combination of
	protocol mechanisms (HSTS, certificate pinning		protocol mechanisms (HSTS, certificate pinning [KEY-PINNING]), and
	[I-D.ietf-websec-key-pinning]) and very careful UI design.		very careful UI design.
	3. Applicability to DTLS		3. Applicability to DTLS
	DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP.		DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP.
	With respect to the attacks described in the current document, DTLS		With respect to the attacks described in the current document, DTLS
	1.0 is equivalent to TLS 1.1. The only exception is RC4, which is		1.0 is equivalent to TLS 1.1. The only exception is RC4, which is
	disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2.		disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2.
	4. IANA Considerations		4. Security Considerations
	This document requires no IANA actions. [Note to RFC Editor: please
	remove this whole section before publication.]
	5. Security Considerations
	This document describes protocol attacks in an informational manner,		This document describes protocol attacks in an informational manner
	and in itself does not have any security implications. Its companion		and in itself does not have any security implications. Its companion
	documents, especially [I-D.ietf-uta-tls-bcp], certainly do.		documents, especially [SECURE-TLS], certainly do.
	6. Acknowledgments
	We would like to thank Stephen Farrell, Simon Josefsson, John
	Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter,
	Rich Salz and Meral Shirazipour for their feedback on this document.
	We thank Andrei Popov for contributing text on RC4, Kohei Kasamatsu
	for text on Lucky13, Ilari Liusvaara for text on attacks and on DTLS,
	Aaron Zauner for text on virtual host confusion, and Chris Newman for
	text on STARTTLS command injection.
	During IESG review, Richard Barnes, Barry Leiba, and Kathleen
	Moriarty caught several issues that needed to be addressed.
	The authors gratefully acknowledge the assistance of Leif Johansson
	and Orit Levin as the working group chairs and Pete Resnick as the
	sponsoring Area Director.
	The document was prepared using the lyx2rfc tool, created by Nico
	Williams.
	7. Informative References
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, April 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
	Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
	August 2008.
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, March 2010.
	[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
	"Transport Layer Security (TLS) Renegotiation Indication
	Extension", RFC 5746, February 2010.
	[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
	for TLS", RFC 5929, July 2010.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.
	[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
	Transport Security (HSTS)", RFC 6797, November 2012.
	[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman		5. Informative References
	Tests for the Internet Key Exchange Protocol Version 2
	(IKEv2)", RFC 6989, July 2013.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[Attacks-iSec]
	Attack", BCP 188, RFC 7258, May 2014.		Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a
			comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13
			and RC4 biases", August 2013,
			<https://www.isecpartners.com/media/106031/
			ssl_attacks_survey.pdf>.
	[I-D.ietf-uta-tls-bcp]		[BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS",
	Sheffer, Y., Holz, R., and P. Saint-Andre,		2011, <http://packetstormsecurity.com/files/105499/
	"Recommendations for Secure Use of TLS and DTLS", draft-		Browser-Exploit-Against-SSL-TLS.html>.
	ietf-uta-tls-bcp-05 (work in progress), October 2014.
	[I-D.ietf-tls-prohibiting-rc4]		[BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack",
	Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf-		2013, <http://breachattack.com/>.
	tls-prohibiting-rc4-00 (work in progress), July 2014.
	[I-D.ietf-tls-encrypt-then-mac]		[BhargavanDFPS14]
	Gutmann, P., "Encrypt-then-MAC for TLS and DTLS", draft-		Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
	ietf-tls-encrypt-then-mac-03 (work in progress), July		A., and P. Strub, "Triple handshakes and cookie cutters:
	2014.		breaking and fixing authentication over tls", 2014,
			<https://secure-resumption.com/tlsauth.pdf>.
	[I-D.ietf-tls-negotiated-ff-dhe]		[Bleichenbacher98]
	Gillmor, D., "Negotiated Finite Field Diffie-Hellman		Bleichenbacher, D., "Chosen Ciphertext Attacks Against
	Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-		Protocols Based on the RSA Encryption Standard PKCS #1",
	ff-dhe-02 (work in progress), October 2014.		1998, <http://archiv.infsec.ethz.ch/education/fs08/secsem/
			Bleichenbacher98.pdf>.
	[I-D.ietf-websec-key-pinning]		[Brubaker2014using]
	Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V.
	Extension for HTTP", draft-ietf-websec-key-pinning-21		Shmatikov, "Using Frankencerts for Automated Adversarial
	(work in progress), October 2014.		Testing of Certificate Validation in SSL/TLS
			Implementations", 2014,
			<https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf>.
	[CVE] MITRE, , "Common Vulnerabilities and Exposures",		[Brumley03]
	<https://cve.mitre.org/>.		Brumley, D. and D. Boneh, "Remote Timing Attacks are
			Practical", 2003,
			<http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf>.
	[CBC-Attack]		[CBC-Attack]
	AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking		AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking
	the TLS and DTLS Record Protocols", IEEE Symposium on		the TLS and DTLS Record Protocols", IEEE Symposium on
	Security and Privacy , 2013.		Security and Privacy, 2013, <http://www.ieee-security.org/
			TC/SP2013/papers/4977a526.pdf>.
	[BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS",
	2011, <http://packetstormsecurity.com/files/105499/
	Browser-Exploit-Against-SSL-TLS.html>.
	[POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE		[CIPHER-SUITES]
	Bites:Exploiting the SSL 3.0 Fallback", 2014,		Popov, A., "Prohibiting RC4 Cipher Suites", Work in
	<https://www.openssl.org/~bodo/ssl-poodle.pdf>.		Progress, draft-ietf-tls-prohibiting-rc4-01, October 2014.
	[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty		[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty
	Security Conference 2012, 2012.		Security Conference, 2012.
	[BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack",
	2013, <http://breachattack.com/>.
	[TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME		[CVE] MITRE, "Common Vulnerabilities and Exposures",
	Will Tell", Black Hat Europe 2013, 2013,		<https://cve.mitre.org/>.
	<https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-
	13-a-perfect-crime-beery-wp.pdf>.
	[RC4] Schneier, B., "Applied Cryptography: Protocols,		[Cross-Protocol]
	Algorithms, and Source Code in C, 2nd Ed.", 1996.		Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and
			B. Preneel, "A cross-protocol attack on the TLS protocol",
			Proceedings of the 2012 ACM Conference in Computer and
			Communications Security, pages 62-72, 2012,
			<http://doi.acm.org/10.1145/2382196.2382206>.
	[RC4-Attack-FMS]		[Delignat14]
	Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the		Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host
	Key Scheduling Algorithm of RC4", Selected Areas in		Confusion: Weaknesses and Exploits", Black Hat 2014, 2014,
	Cryptography , 2001.		<https://bh.ht.vc/vhost_confusion.pdf>.
	[RC4-Attack-AlF]		[FFDHE-TLS]
	AlFardan, N., Bernstein, D., Paterson, K., Poettering, B.,		Gillmor, D., "Negotiated Finite Field Diffie-Hellman
	and J. Schuldt, "On the Security of RC4 in TLS", Usenix		Ephemeral Parameters for TLS", Work in Progress,
	Security Symposium 2013, 2013,		draft-ietf-tls-negotiated-ff-dhe-05, December 2014.
	<https://www.usenix.org/conference/usenixsecurity13/
	security-rc4-tls>.
	[Georgiev2012]		[Georgiev2012]
	Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,		Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh,
	D., and V. Shmatikov, "The most dangerous code in the		D., and V. Shmatikov, "The most dangerous code in the
	world: validating SSL certificates in non-browser		world: validating SSL certificates in non-browser
	software", 2012,		software", Proceedings of the 2012 ACM conference on
			Computer and Communications Security, pages 38-49, 2012,
	<http://doi.acm.org/10.1145/2382196.2382204>.		<http://doi.acm.org/10.1145/2382196.2382204>.
	[Attacks-iSec]		[KEY-PINNING]
	Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a		Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13		Extension for HTTP", Work in Progress,
	and RC4 biases", 8 2013,		draft-ietf-websec-key-pinning-21, October 2014.
	<https://www.isecpartners.com/media/106031/
	ssl_attacks_survey.pdf>.		[Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based
			Sessions in SSL/TLS", 2003,
			<https://eprint.iacr.org/2003/052.pdf>.
			[POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE
			Bites: Exploiting the SSL 3.0 Fallback", September 2014,
			<https://www.openssl.org/~bodo/ssl-poodle.pdf>.
	[Padding-Oracle]		[Padding-Oracle]
	Vaudenay, S., "Security Flaws Induced by CBC Padding		Vaudenay, S., "Security Flaws Induced by CBC Padding
	Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002,		Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002,
	2002, <http://www.iacr.org/cryptodb/archive/2002/		2002, <http://www.iacr.org/cryptodb/archive/2002/
	EUROCRYPT/2850/2850.pdf>.		EUROCRYPT/2850/2850.pdf>.
	[Cross-Protocol]		[RC4] Schneier, B., "Applied Cryptography: Protocols,
	Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and		Algorithms, and Source Code in C", Second Edition, October
	B. Preneel, "A cross-protocol attack on the TLS protocol",		1996.
	2012, <http://doi.acm.org/10.1145/2382196.2382206>.
	[RC4-Attack-Pau]
	Paul, G. and S. Maitra, "Permutation after RC4 key
	scheduling reveals the secret key.", 2007,
	<http://dblp.uni-trier.de/db/conf/sacrypt/
	sacrypt2007.html#PaulM07>.
	[RC4-Attack-Man]
	Mantin, I. and A. Shamir, "A practical attack on broadcast
	RC4", 2001.
	[SSL-Stripping]
	Marlinspike, M., "SSL Stripping", February 2009,
	<http://www.thoughtcrime.org/software/sslstrip/>.
	[Bleichenbacher98]
	Bleichenbacher, D., "Chosen ciphertext attacks against
	protocols based on the RSA encryption standard pkcs1",
	1998.
	[Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based
	sessions in SSL/TLS", 2003.
	[Brumley03]
	Brumley, D. and D. Boneh, "Remote timing attacks are
	practical", 2003.
	[Brubaker2014using]		[RC4-Attack-AlF]
	Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V.		AlFardan, N., Bernstein, D., Paterson, K., Poettering, B.,
	Shmatikov, "Using frankencerts for automated adversarial		and J. Schuldt, "On the Security of RC4 in TLS", Usenix
	testing of certificate validation in SSL/TLS		Security Symposium 2013, August 2013,
	implementations", 2014.		<https://www.usenix.org/conference/usenixsecurity13/
			security-rc4-tls>.
	[Delignat14]		[RC4-Attack-FMS]
	Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host		Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the
	Confusion: Weaknesses and Exploits", Black Hat 2014, 2014.		Key Scheduling Algorithm of RC4", Selected Areas in
			Cryptography, August 2001,
			<http://www.crypto.com/papers/others/rc4_ksaproc.pdf>.
	[BhargavanDFPS14]		[RC4-Attack-Man]
	Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,		Mantin, I. and A. Shamir, "A Practical Attack on Broadcast
	A., and P. Strub, "Triple handshakes and cookie cutters:		RC4", April 2001,
	breaking and fixing authentication over tls", 2014,		<http://saluc.engr.uconn.edu/refs/stream_cipher/
	<http://prosecco.gforge.inria.fr/pubs/		mantin01attackRC4.pdf>.
	triple-handshakes-and-cookie-cutters-sp14.pdf>.
	Appendix A. Appendix: Change Log		[RC4-Attack-Pau]
			Paul, G. and S. Maitra, "Permutation After RC4 Key
			Scheduling Reveals the Secret Key", August 2007,
			<http://dblp.uni-trier.de/db/conf/sacrypt/
			sacrypt2007.html#PaulM07>.
	Note to RFC Editor: please remove this section before publication.		[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security", RFC 4347, April 2006,
			<http://www.rfc-editor.org/info/rfc4347>.
	A.1. draft-ietf-uta-tls-attacks-05		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246, August 2008,
			<http://www.rfc-editor.org/info/rfc5246>.
	o Implemented Gen-ART and IESG reviews.		[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
			Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
			August 2008, <http://www.rfc-editor.org/info/rfc5288>.
	A.2. draft-ietf-uta-tls-attacks-04		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
			Layer Security (TLS)", RFC 5705, March 2010,
			<http://www.rfc-editor.org/info/rfc5705>.
	o Implemented AD review comments.		[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
			"Transport Layer Security (TLS) Renegotiation Indication
			Extension", RFC 5746, February 2010,
			<http://www.rfc-editor.org/info/rfc5746>.
	A.3. draft-ietf-uta-tls-attacks-03		[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
			for TLS", RFC 5929, July 2010,
			<http://www.rfc-editor.org/info/rfc5929>.
	o Implemented WG Last Call comments.		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security Version 1.2", RFC 6347, January 2012,
			<http://www.rfc-editor.org/info/rfc6347>.
	o Virtual host confusion.		[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
			Transport Security (HSTS)", RFC 6797, November 2012,
			<http://www.rfc-editor.org/info/rfc6797>.
	o STARTTLS command injection.		[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
			Tests for the Internet Key Exchange Protocol Version 2
			(IKEv2)", RFC 6989, July 2013,
			<http://www.rfc-editor.org/info/rfc6989>.
	o Added CVE numbers.		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
			Attack", BCP 188, RFC 7258, May 2014,
			<http://www.rfc-editor.org/info/rfc7258>.
	A.4. draft-ietf-uta-tls-attacks-02		[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", RFC 7366, September 2014,
			<http://www.rfc-editor.org/info/rfc7366>.
	o Added implementation issues ("most dangerous code"),		[SECURE-TLS]
	renegotiation, triple handshake.		Sheffer, Y., Holz, R., and P. Saint-Andre,
			"Recommendations for Secure Use of TLS and DTLS", Work in
			Progress, draft-ietf-uta-tls-bcp-08, December 2014.
	o Added text re: mitigation of Lucky13.		[SSL-Stripping]
			Marlinspike, M., "sslstrip", February 2009,
			<http://www.thoughtcrime.org/software/sslstrip/>.
	o Added applicability to DTLS.		[TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME
			Will Tell", Black Hat Europe 2013, 2013,
			<https://media.blackhat.com/eu-13/briefings/Beery/
			bh-eu-13-a-perfect-crime-beery-wp.pdf>.
	A.5. draft-ietf-uta-tls-attacks-01		Acknowledgements
	o Added SSL Stripping, attacks related to certificates, Diffie		We would like to thank Stephen Farrell, Simon Josefsson, John
	Hellman parameters and denial of service.		Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter,
			Rich Salz, and Meral Shirazipour for their feedback on this document.
			We thank Andrei Popov for contributing text on RC4, Kohei Kasamatsu
			for text on Lucky13, Ilari Liusvaara for text on attacks and on DTLS,
			Aaron Zauner for text on virtual host confusion, and Chris Newman for
			text on STARTTLS command injection. Ralph Holz gratefully
			acknowledges the support of NICTA (National ICT of Australia) in the
			preparation of this document.
	o Expanded on RC4 attacks, thanks to Andrei Popov.		During IESG review, Richard Barnes, Barry Leiba, and Kathleen
			Moriarty caught several issues that needed to be addressed.
	A.6. draft-ietf-uta-tls-attacks-00		The authors gratefully acknowledge the assistance of Leif Johansson
			and Orit Levin as the working group chairs and Pete Resnick as the
			sponsoring Area Director.
	o Initial version, extracted from draft-sheffer-tls-bcp-01.		The document was prepared using the lyx2rfc tool, created by Nico
			Williams.
	Authors' Addresses		Authors' Addresses
	Yaron Sheffer		Yaron Sheffer
	Porticor		Porticor
	29 HaHarash St.		29 HaHarash St.
	Hod HaSharon 4501303		Hod HaSharon 4501303
	Israel		Israel
	Email: yaronf.ietf@gmail.com		EMail: yaronf.ietf@gmail.com
	Ralph Holz		Ralph Holz
	Technische Universitaet Muenchen		Technische Universitaet Muenchen
	Boltzmannstr. 3		Boltzmannstr. 3
	Garching 85748		Garching 85748
	Germany		Germany
	Email: holz@net.in.tum.de		EMail: holz@net.in.tum.de
	Peter Saint-Andre		Peter Saint-Andre
	&yet		&yet
	Email: peter@andyet.com		EMail: peter@andyet.com
	URI: https://andyet.com/		URI: https://andyet.com/
End of changes. 85 change blocks.
	310 lines changed or deleted		276 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/