draft-ietf-uta-tls-attacks-02.txt		draft-ietf-uta-tls-attacks-03.txt
	uta Y. Sheffer		uta Y. Sheffer
	Internet-Draft Porticor		Internet-Draft Porticor
	Intended status: Informational R. Holz		Intended status: Informational R. Holz
	Expires: February 13, 2015 TUM		Expires: March 13, 2015 TUM
	P. Saint-Andre		P. Saint-Andre
	&yet		&yet
	August 12, 2014		September 9, 2014
	Summarizing Current Attacks on TLS and DTLS		Summarizing Current Attacks on TLS and DTLS
	draft-ietf-uta-tls-attacks-02		draft-ietf-uta-tls-attacks-03
	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
	TLS, including attacks on its most commonly used ciphers and modes of		TLS, including attacks on its most commonly used ciphers and modes of
	operation. This document summarizes these attacks, with the goal of		operation. This document summarizes these attacks, with the goal of
	motivating generic and protocol-specific recommendations on the usage		motivating generic and protocol-specific recommendations on the usage
	of TLS and DTLS.		of TLS and DTLS.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 February 13, 2015.		This Internet-Draft will expire on March 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 2, line 13		skipping to change at page 2, line 13
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		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. BEAST . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. STARTTLS Command Injection Attack (CVE-2011-0411) . . . . . 3
	2.3. Lucky Thirteen . . . . . . . . . . . . . . . . . . . . . . 3		2.3. BEAST (CVE-2011-3389) . . . . . . . . . . . . . . . . . . . 3
	2.4. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . . . 3		2.4. Lucky Thirteen (CVE-2013-0169) . . . . . . . . . . . . . . 4
	2.5. Compression Attacks: CRIME and BREACH . . . . . . . . . . . 4		2.5. Attacks on RC4 . . . . . . . . . . . . . . . . . . . . . . 4
	2.6. Certificate Attacks . . . . . . . . . . . . . . . . . . . . 4		2.6. Compression Attacks: CRIME, TIME and BREACH . . . . . . . . 4
	2.7. Diffie-Hellman Parameters . . . . . . . . . . . . . . . . . 4		2.7. Certificate Attacks . . . . . . . . . . . . . . . . . . . . 5
	2.8. Renegotiation . . . . . . . . . . . . . . . . . . . . . . . 5		2.8. Diffie-Hellman Parameters . . . . . . . . . . . . . . . . . 5
	2.9. Triple Hanshake . . . . . . . . . . . . . . . . . . . . . . 5		2.9. Renegotiation (CVE-2009-3555) . . . . . . . . . . . . . . . 5
	2.10. Denial of Service . . . . . . . . . . . . . . . . . . . . . 5		2.10. Triple Handshake (CVE-2014-1295) . . . . . . . . . . . . . 5
	2.11. Implementation Issues . . . . . . . . . . . . . . . . . . . 5		2.11. Virtual Host Confusion . . . . . . . . . . . . . . . . . . 5
			2.12. Denial of Service . . . . . . . . . . . . . . . . . . . . . 6
			2.13. Implementation Issues . . . . . . . . . . . . . . . . . . . 6
	3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 6		3. Applicability to DTLS . . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Informative References . . . . . . . . . . . . . . . . . . . 6		7. Informative References . . . . . . . . . . . . . . . . . . . 7
	Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . 9		Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . 10
	A.1. draft-ietf-uta-tls-attacks-02 . . . . . . . . . . . . . . . 9		A.1. draft-ietf-uta-tls-attacks-03 . . . . . . . . . . . . . . . 10
	A.2. draft-ietf-uta-tls-attacks-01 . . . . . . . . . . . . . . . 9		A.2. draft-ietf-uta-tls-attacks-02 . . . . . . . . . . . . . . . 10
	A.3. draft-ietf-uta-tls-attacks-00 . . . . . . . . . . . . . . . 9		A.3. draft-ietf-uta-tls-attacks-01 . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		A.4. draft-ietf-uta-tls-attacks-00 . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Over the last few years there have been several major attacks on TLS		Over the last few years there have been several major attacks on TLS
	[RFC5246], including attacks on its most commonly used ciphers and		[RFC5246], including attacks on its most commonly used ciphers and
	modes of operation. Details are given in Section 2, but suffice it		modes of operation. Details are given in Section 2, but suffice it
	to say that both AES-CBC and RC4, which together make up for most		to say that both AES-CBC and RC4, which together make up for most
	current usage, have been seriously attacked in the context of TLS.		current usage, have been seriously attacked in the context of TLS.
	This situation motivated the creation of the UTA working group, which		This situation motivated the creation of the UTA working group, which
	skipping to change at page 3, line 23		skipping to change at page 3, line 25
	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
	systemic solution.		systemic solution.
	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 SSL/TLS altogether, by
	modifying unencrypted protocols that request the use of TLS,		modifying unencrypted protocols that request the use of TLS,
	specifically modifying HTTP traffic and HTML pages as they pass on		specifically modifying HTTP traffic and HTML pages as they pass on
	the wire. These attacks are known collectively as SSL Stripping, and		the wire. These attacks are known collectively as SSL Stripping and
	were first introduced by Moxie Marlinspike [SSL-Stripping]. In the		were first introduced by Moxie Marlinspike [SSL-Stripping]. In the
	context of Web traffic, these attacks are only effective if the		context of Web traffic, these attacks are only effective if the
	client accesses a Web server using a mixture of HTTP and HTTPS.		client initially accesses a Web server using HTTP. A commonly used
			mitigation is HTTP Strict Transport Security (HSTS) [RFC6797].
	2.2. BEAST		2.2. STARTTLS Command Injection Attack (CVE-2011-0411)
			Similarly, there are attacks on the transition between unprotected
			and TLS-protected traffic. A number of IETF application protocols
			have used an application-level command, usually STARTTLS, to upgrade
			a clear-text connection to use TLS. Multiple implementations of
			STARTTLS had a flaw where an application-layer input buffer retained
			commands that were pipelined with the STARTTLS command, such that
			commands received prior to TLS negotiation are executed after TLS
			negotiation. This problem is resolved by requiring the application-
			level command input buffer to be empty before negotiating TLS. Note
			that this flaw lives in the application layer code and does not
			impact the TLS protocol directly.
			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 CBC (that is, the predictable initialization vector) to decrypt
	parts of a packet, and specifically to decrypt HTTP cookies when HTTP		parts of a packet, and specifically to decrypt HTTP cookies when HTTP
	is run over TLS.		is run over TLS.
	2.3. Lucky Thirteen		2.4. Lucky Thirteen (CVE-2013-0169)
	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
	[CBC-Attack], a timing side-channel attack that allows the attacker		[CBC-Attack], a timing side-channel attack that allows the attacker
	to decrypt arbitrary ciphertext.		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] and encrypt-then-mac		encryption like AES-GCM [RFC5288] or encrypt-then-mac
	[I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC-		[I-D.ietf-tls-encrypt-then-mac] instead of the TLS default of MAC-
	then-encrypt.		then-encrypt.
	2.4. 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]		[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 refered to [I-D.ietf-tls-prohibiting-rc4].		the reader is referred to [I-D.ietf-tls-prohibiting-rc4].
	2.5. Compression Attacks: CRIME and BREACH		2.6. Compression Attacks: CRIME, TIME and BREACH
	The CRIME attack [CRIME] allows an active attacker to decrypt		The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to
	ciphertext (specifically, cookies) when TLS is used with TLS level		decrypt ciphertext (specifically, cookies) when TLS is used with TLS
	compression.		level compression.
	The TIME attack [TIME] and the later BREACH attack [BREACH] both make		The TIME attack [TIME] and the later BREACH attack [BREACH]
	similar use of HTTP-level compression to decrypt secret data passed		(CVE-2013-3587, though the number has not been officially allocated)
	in the HTTP response. We note that compression of the HTTP message		both make similar use of HTTP-level compression to decrypt secret
	body is much more prevalent than compression at the TLS level.		data passed in the HTTP response. We note that compression of the
			HTTP message body is much more prevalent than compression at the TLS
			level.
	The former attack can be mitigated by disabling TLS compression. We		The former 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 latter
	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 CSRF tokens
	will need to randomize them even when the recommendations of		will need to randomize them even when the recommendations of
	[I-D.ietf-uta-tls-bcp] are adopted.		[I-D.ietf-uta-tls-bcp] are adopted.
	2.6. Certificate Attacks		2.7. Certificate 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 that relies on a		has been mitigated in TLS 1.0, the Klima attack that relies on a
	version-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], unless the implementation takes care to explicitly		[Brumley03] (CVE-2003-0147), unless the implementation takes care to
	eliminate them.		explicitly eliminate them.
	2.7. Diffie-Hellman Parameters		A recent certificate fuzzing tool [Brubaker2014using] uncovered
			numerous vulnerabilities in different TLS libraries, related to
			certificate validation.
			2.8. Diffie-Hellman Parameters
	TLS allows to define ephemeral Diffie-Hellman and Elliptic Curve		TLS allows to define ephemeral Diffie-Hellman and Elliptic Curve
	Diffie-Hellman parameters in its respective key exchange modes. This		Diffie-Hellman parameters in its respective key exchange modes. This
	results in an outstanding attack, detailed in [Cross-Protocol]. In		results in an attack detailed in [Cross-Protocol]. In addition,
	addition, clients that do not properly verify the received parameters		clients that do not properly verify the received parameters are
	are exposed to man in the middle (MITM) attacks. Unfortunately the		exposed to man in the middle (MITM) attacks. Unfortunately the TLS
	TLS protocol does not require this verification, see [RFC6989] for		protocol does not require this verification, see [RFC6989] for the
	the IPsec analogy.		IPsec analogy.
	2.8. Renegotiation		2.9. 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.9. Triple Hanshake		2.10. Triple Handshake (CVE-2014-1295)
	The triple handshake attack [[TRIPLE-HS, add the reference when		The triple handshake attack [[TRIPLE-HS, add the reference when
	published]] enables the attacker to cause two TLS connections to		published]] enables the attacker to cause two TLS connections to
	share keying material. This leads to a multitude of attacks, e.g.		share keying material. This leads to a multitude of attacks, e.g.
	Man-in-the-Middle, breaking safe renegotiation and breaking channel		Man-in-the-Middle, breaking safe renegotiation and breaking channel
	binding via TLS Exporter [RFC5705] or "tls-unique" [RFC5929].		binding via TLS Exporter [RFC5705] or "tls-unique" [RFC5929].
	2.10. Denial of Service		2.11. Virtual Host Confusion
			A recent article [Delignat14] describes a security issue whereby
			SSLv3 fallback and improper handling of session caches on the server
			side can be abused by an attacker to establish a malicious connection
			to a virtual host other than originally intended and approved by the
			server. This attack is especially serious in performance critical
			environments where sharing of SSLv3 session caches is very common.
			2.12. 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.11. Implementation Issues		2.13. Implementation Issues
	Even when the protocol is fully specified, the are very common issues		Even when the protocol is fully specified, the are very common issues
	that often plague implementations. In particular, the integration of		that often plague implementations. In particular, the integration of
	higher-level protocols, TLS and its PKI-based authentication is the		higher-level protocols, TLS and its PKI-based authentication is the
	source of misunderstandings and implementation "shortcuts". An		source of misunderstandings and implementation "shortcuts". An
	extensive survey of these issues can be found in [Georgiev2012].		extensive survey of these issues can be found in [Georgiev2012].
	o Implementations may omit validation of the server certificate		o Implementations may 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.		implementation of HTTP client libraries in Python 2 (see e.g.
			CVE-2013-2191).
	o Implementations may not validate the server identity. This		o Implementations may 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.		name with the certificate's Subject Alternative Name field. Note:
			historically, although incorrect, this information is also often
			found in the Common Name part of the Distinguished Name instead.
	o Implementations may be validating the certificate chain		o Implementations may be validating the certificate chain
	incorrectly or not at all, or using an incorrect or outdated trust		incorrectly or not at all, or using an incorrect or outdated trust
	anchor list.		anchor list.
	3. Applicability to DTLS		3. Applicability to DTLS
	DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP datagrams.		DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP datagrams.
	With respect to the attacks described in the current document, DTLS		With respect to the attacks described in the current document, DTLS
	skipping to change at page 6, line 30		skipping to change at page 7, line 16
	This document requires no IANA actions. [Note to RFC Editor: please		This document requires no IANA actions. [Note to RFC Editor: please
	remove this whole section before publication.]		remove this whole section before publication.]
	6. Acknowledgments		6. Acknowledgments
	We would like to thank Stephen Farrell, Simon Josefsson, John		We would like to thank Stephen Farrell, Simon Josefsson, John
	Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter and		Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter and
	Rich Salz for their review of this document. We thank Andrei Popov		Rich Salz for their review of this document. We thank Andrei Popov
	for contributing text on RC4, Kohei Kasamatsu for text on Lucky13,		for contributing text on RC4, Kohei Kasamatsu for text on Lucky13,
	Ilari Liusvaara for text on attacks and on DTLS.		Ilari Liusvaara for text on attacks and on DTLS, Aaron Zauner for
			text on virtual host confusion, Chris Newman for text on STARTTLS
			command injection.
	The document was prepared using the lyx2rfc tool, created by Nico		The document was prepared using the lyx2rfc tool, created by Nico
	Williams.		Williams.
	7. Informative References		7. Informative References
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, April 2006.		Security", RFC 4347, April 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	skipping to change at page 7, line 11		skipping to change at page 7, line 48
	[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,		[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
	"Transport Layer Security (TLS) Renegotiation Indication		"Transport Layer Security (TLS) Renegotiation Indication
	Extension", RFC 5746, February 2010.		Extension", RFC 5746, February 2010.
	[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings		[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
	for TLS", RFC 5929, July 2010.		for TLS", RFC 5929, July 2010.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		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		[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
	Tests for the Internet Key Exchange Protocol Version 2		Tests for the Internet Key Exchange Protocol Version 2
	(IKEv2)", RFC 6989, July 2013.		(IKEv2)", RFC 6989, July 2013.
	[I-D.ietf-uta-tls-bcp]		[I-D.ietf-uta-tls-bcp]
	Sheffer, Y., Holz, R., and P. Saint-Andre,		Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of TLS and DTLS", draft-		"Recommendations for Secure Use of TLS and DTLS", draft-
	ietf-uta-tls-bcp-01 (work in progress), June 2014.		ietf-uta-tls-bcp-01 (work in progress), June 2014.
	[I-D.ietf-tls-prohibiting-rc4]		[I-D.ietf-tls-prohibiting-rc4]
	skipping to change at page 9, line 17		skipping to change at page 10, line 12
	protocols based on the RSA encryption standard pkcs1",		protocols based on the RSA encryption standard pkcs1",
	1998.		1998.
	[Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based		[Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based
	sessions in SSL/TLS", 2003.		sessions in SSL/TLS", 2003.
	[Brumley03]		[Brumley03]
	Brumley, D. and D. Boneh, "Remote timing attacks are		Brumley, D. and D. Boneh, "Remote timing attacks are
	practical", 2003.		practical", 2003.
			[Brubaker2014using]
			Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V.
			Shmatikov, "Using frankencerts for automated adversarial
			testing of certificate validation in SSL/TLS
			implementations", 2014.
			[Delignat14]
			Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host
			Confusion: Weaknesses and Exploits", Black Hat 2014, 2014.
	Appendix A. Appendix: Change Log		Appendix A. Appendix: Change Log
	Note to RFC Editor: please remove this section before publication.		Note to RFC Editor: please remove this section before publication.
	A.1. draft-ietf-uta-tls-attacks-02		A.1. draft-ietf-uta-tls-attacks-03
			o Implemented WG Last Call comments.
			o Virtual host confusion.
			o STARTTLS command injection.
			o Added CVE numbers.
			A.2. draft-ietf-uta-tls-attacks-02
	o Added implementation issues ("most dangerous code"),		o Added implementation issues ("most dangerous code"),
	renegotiation, triple handshake.		renegotiation, triple handshake.
	o Added text re: mitigation of Lucky13.		o Added text re: mitigation of Lucky13.
	o Added applicability to DTLS.		o Added applicability to DTLS.
	A.2. draft-ietf-uta-tls-attacks-01		A.3. draft-ietf-uta-tls-attacks-01
	o Added SSL Stripping, attacks related to certificates, Diffie		o Added SSL Stripping, attacks related to certificates, Diffie
	Hellman parameters and denial of service.		Hellman parameters and denial of service.
	o Expanded on RC4 attacks, thanks to Andrei Popov.		o Expanded on RC4 attacks, thanks to Andrei Popov.
	A.3. draft-ietf-uta-tls-attacks-00		A.4. draft-ietf-uta-tls-attacks-00
	o Initial version, extracted from draft-sheffer-tls-bcp-01.		o Initial version, extracted from draft-sheffer-tls-bcp-01.
	Authors' Addresses		Authors' Addresses
	Yaron Sheffer		Yaron Sheffer
	Porticor		Porticor
	29 HaHarash St.		29 HaHarash St.
	Hod HaSharon 4501303		Hod HaSharon 4501303
	Israel		Israel
End of changes. 33 change blocks.
	57 lines changed or deleted		117 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/