< draft-ietf-tls-negotiated-ff-dhe-04.txt		draft-ietf-tls-negotiated-ff-dhe-05.txt >
	Internet Engineering Task Force D. Gillmor		Internet Engineering Task Force D. Gillmor
	Internet-Draft ACLU		Internet-Draft ACLU
	Updates: 4492, 5246, 4346, 2246 (if December 5, 2014		Updates: 4492, 5246, 4346, 2246 (if December 19, 2014
	approved)		approved)
	Intended status: Informational		Intended status: Informational
	Expires: June 8, 2015		Expires: June 22, 2015
	Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS		Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
	draft-ietf-tls-negotiated-ff-dhe-04		draft-ietf-tls-negotiated-ff-dhe-05
	Abstract		Abstract
	Traditional finite-field-based Diffie-Hellman (DH) key exchange		Traditional finite-field-based Diffie-Hellman (DH) key exchange
	during the TLS handshake suffers from a number of security,		during the TLS handshake suffers from a number of security,
	interoperability, and efficiency shortcomings. These shortcomings		interoperability, and efficiency shortcomings. These shortcomings
	arise from lack of clarity about which DH group parameters TLS		arise from lack of clarity about which DH group parameters TLS
	servers should offer and clients should accept. This document offers		servers should offer and clients should accept. This document offers
	a solution to these shortcomings for compatible peers by using a		a solution to these shortcomings for compatible peers by using a
	section of the TLS "EC Named Curve Registry" to establish common		section of the TLS "EC Named Curve Registry" to establish common
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 June 8, 2015.		This Internet-Draft will expire on June 22, 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 36 ¶		skipping to change at page 2, line 36 ¶
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 9		9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9.1. Negotiation resistance to active attacks . . . . . . . . 9		9.1. Negotiation resistance to active attacks . . . . . . . . 9
	9.2. Group strength considerations . . . . . . . . . . . . . . 10		9.2. Group strength considerations . . . . . . . . . . . . . . 10
	9.3. Finite-Field DHE only . . . . . . . . . . . . . . . . . . 11		9.3. Finite-Field DHE only . . . . . . . . . . . . . . . . . . 11
	9.4. Deprecating weak groups . . . . . . . . . . . . . . . . . 11		9.4. Deprecating weak groups . . . . . . . . . . . . . . . . . 11
	9.5. Choice of groups . . . . . . . . . . . . . . . . . . . . 11		9.5. Choice of groups . . . . . . . . . . . . . . . . . . . . 11
	9.6. Timing attacks . . . . . . . . . . . . . . . . . . . . . 12		9.6. Timing attacks . . . . . . . . . . . . . . . . . . . . . 12
	9.7. Replay attacks from non-negotiated FFDHE . . . . . . . . 12		9.7. Replay attacks from non-negotiated FFDHE . . . . . . . . 12
	9.8. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 12		9.8. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 12
			9.9. False Start . . . . . . . . . . . . . . . . . . . . . . . 13
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
	10.1. Client fingerprinting . . . . . . . . . . . . . . . . . 13		10.1. Client fingerprinting . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Normative References . . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . 13
	11.2. Informative References . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . 14
	11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15		11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 15		Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 15
	A.1. ffdhe2048 . . . . . . . . . . . . . . . . . . . . . . . . 15		A.1. ffdhe2048 . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 16		A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 17
	A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 18		A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 18
	A.4. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 19		A.4. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 20
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key		Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key
	exchange mode which provides Forward Secrecy for the connection. The		exchange mode which provides Forward Secrecy for the connection. The
	client offers a ciphersuite in the ClientHello that includes DHE, and		client offers a ciphersuite in the ClientHello that includes DHE, and
	the server offers the client group parameters generator g and modulus		the server offers the client group parameters generator g and modulus
	p. If the client does not consider the group strong enough (e.g. if		p. If the client does not consider the group strong enough (e.g. if
	p is too small, or if p is not prime, or there are small subgroups),		p is too small, or if p is not prime, or there are small subgroups),
	or if it is unable to process the group for other reasons, the client		or if it is unable to process the group for other reasons, the client
	skipping to change at page 13, line 9 ¶		skipping to change at page 13, line 9 ¶
	group; using a very strong symmetric cipher like AES256 with a		group; using a very strong symmetric cipher like AES256 with a
	forward-secret ciphersuite, but generating the keys with a much		forward-secret ciphersuite, but generating the keys with a much
	weaker group like dhe2048 simply moves the adversary's cost from		weaker group like dhe2048 simply moves the adversary's cost from
	attacking the symmetric cipher to attacking the dh_Ys or dh_Yc		attacking the symmetric cipher to attacking the dh_Ys or dh_Yc
	ephemeral keyshares.		ephemeral keyshares.
	If the goal is to provide forward secrecy, attention should be paid		If the goal is to provide forward secrecy, attention should be paid
	to all parts of the ciphersuite selection process, both key exchange		to all parts of the ciphersuite selection process, both key exchange
	and symmetric cipher choice.		and symmetric cipher choice.
			9.9. False Start
			Clients capable of TLS False Start [FALSE-START] may receive a
			proposed FFDHE group from a server that is attacker-controlled. In
			particular, the attacker can modify the ClientHello to strip the
			proposed FFDHE groups, which may cause the server to offer a weaker
			FFDHE group than it should, and this will not be detected until
			receipt of the server's Finished message. This could cause the a
			client using the False Start protocol modification to send data
			encrypted under a weak key agreement.
			Clients should have their own classification of FFDHE groups that are
			"cryptographically strong" in the same sense described in the
			description of symmetric ciphers in [FALSE-START], and MUST offer at
			least one of these in the initial handshake if they contemplate using
			the False Start protocol modification.
			Compatible clients performing a full handshake MUST NOT use the False
			Start protocol modification if the server selects an FFDHE
			ciphersuite but sends a group that is not cryptographically strong
			from the client's perspective.
	10. Privacy Considerations		10. Privacy Considerations
	10.1. Client fingerprinting		10.1. Client fingerprinting
	This extension provides a few additional bits of information to		This extension provides a few additional bits of information to
	distinguish between classes of TLS clients (see e.g.		distinguish between classes of TLS clients (see e.g.
	[PANOPTICLICK]). To minimize this sort of fingerprinting, clients		[PANOPTICLICK]). To minimize this sort of fingerprinting, clients
	SHOULD support all named groups at or above their minimum security		SHOULD support all named groups at or above their minimum security
	threshhold. New named groups SHOULD NOT be added to the registry		threshhold. New named groups SHOULD NOT be added to the registry
	without consideration of the cost of browser fingerprinting.		without consideration of the cost of browser fingerprinting.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
			[FALSE-START]
			Langley, A., Modadugu, N., and B. Moeller, "Transport
			Layer Security (TLS) False Start", Work in Progress,
			draft-bmoeller-tls-falsestart-01, November 2014.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.		[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
	Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites		Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
	for Transport Layer Security (TLS)", RFC 4492, May 2006.		for Transport Layer Security (TLS)", RFC 4492, May 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
End of changes. 10 change blocks.
	9 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/