draft-ietf-tls-rfc4347-bis-04.txt		draft-ietf-tls-rfc4347-bis-05.txt
	INTERNET-DRAFT E. Rescorla		INTERNET-DRAFT E. Rescorla
	Obsoletes (if approved): RFC 4347 RTFM, Inc.		Obsoletes (if approved): RFC 4347 RTFM, Inc.
	Intended Status: Proposed Standard N. Modadugu		Intended Status: Proposed Standard N. Modadugu
	<draft-ietf-tls-rfc4347-bis-04.txt> Stanford University		Expires: September 14, 2011 Stanford University
	July 12, 2010 (Expires January 2011)		March 14, 2011
	Datagram Transport Layer Security version 1.2		Datagram Transport Layer Security version 1.2
			draft-ietf-tls-rfc4347-bis-05.txt
	Status of This Memo		Abstract
	This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.		This document specifies Version 1.2 of the Datagram Transport Layer
			Security (DTLS) protocol. The DTLS protocol provides communications
			privacy for datagram protocols. The protocol allows client/server
			applications to communicate in a way that is designed to prevent
			eavesdropping, tampering, or message forgery. The DTLS protocol is
			based on the Transport Layer Security (TLS) protocol and provides
			equivalent security guarantees. Datagram semantics of the underlying
			transport are preserved by the DTLS protocol. This document
			updates DTLS 1.0 to work with TLS version 1.2.
	Copyright (c) 2010 IETF Trust and the persons identified as		Legal
	the document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This documents and the information contained therein are provided on
	Provisions Relating to IETF Documents		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	(http://trustee.ietf.org/license-info) in effect on the date of		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	publication of this document. Please review these documents carefully,		IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	as they describe your rights and restrictions with respect to this		WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	document. Code Components extracted from this document must include		WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	Simplified BSD License text as described in Section 4.e of the Trust		ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	Legal Provisions and are provided without warranty as described in the		FOR A PARTICULAR PURPOSE.
	Simplified BSD License.
	This document may contain material from IETF Documents or IETF		Status of this Memo
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s)
	controlling the copyright in such materials, this document may not
	be modified outside the IETF Standards Process, and derivative
	works of it may not be created outside the IETF Standards Process,
	except to format it for publication as an RFC or to translate it
	into languages other than English.
	Internet-Drafts are working documents of the Internet Engineering Task		This Internet-Draft is submitted in full conformance with the
	Force (IETF), its areas, and its working groups. Note that other		provisions of BCP 78 and BCP 79.
	groups may also distribute working documents as Internet-Drafts.
			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		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on September 14, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.
	Abstract
	This document specifies Version 1.2 of the Datagram Transport Layer
	Security (DTLS) protocol. The DTLS protocol provides communications
	privacy for datagram protocols. The protocol allows client/server
	applications to communicate in a way that is designed to prevent
	eavesdropping, tampering, or message forgery. The DTLS protocol is
	based on the Transport Layer Security (TLS) protocol and provides
	equivalent security guarantees. Datagram semantics of the underlying
	transport are preserved by the DTLS protocol. This document updates
	DTLS 1.0 to work with TLS version 1.2.
	Legal		This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	This documents and the information contained therein are provided on		This document may contain material from IETF Documents or IETF
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		Contributions published or made publicly available before November
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE		10, 2008. The person(s) controlling the copyright in some of this
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL		material may not have granted the IETF Trust the right to allow
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY		modifications of such material outside the IETF Standards Process.
	WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE		Without obtaining an adequate license from the person(s) controlling
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS		the copyright in such materials, this document may not be modified
	FOR A PARTICULAR PURPOSE.		outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction 3		1. Introduction 3
	1.1. Requirements Terminology 4		1.1. Requirements Terminology 4
	2. Usage Model 4		2. Usage Model 4
	3. Overview of DTLS 5		3. Overview of DTLS 5
	3.1. Loss-Insensitive Messaging 5		3.1. Loss-Insensitive Messaging 5
	3.2. Providing Reliability for Handshake 5		3.2. Providing Reliability for Handshake 5
	3.2.1. Packet Loss 6		3.2.1. Packet Loss 6
	3.2.2. Reordering 6		3.2.2. Reordering 6
	3.2.3. Message Size 6		3.2.3. Message Size 7
	3.3. Replay Detection 7		3.3. Replay Detection 7
	4. Differences from TLS 7		4. Differences from TLS 7
	4.1. Record Layer 7		4.1. Record Layer 7
	4.1.1. Transport Layer Mapping 9		4.1.1. Transport Layer Mapping 9
	4.1.1.1. PMTU Issues 10		4.1.1.1. PMTU Issues 10
	4.1.2. Record Payload Protection 11		4.1.2. Record Payload Protection 12
	4.1.2.1. MAC 11		4.1.2.1. MAC 12
	4.1.2.2. Null or Standard Stream Cipher 12		4.1.2.2. Null or Standard Stream Cipher 12
	4.1.2.3. Block Cipher 12		4.1.2.3. Block Cipher 12
	4.1.2.3. AEAD Ciphers 12		4.1.2.3. AEAD Ciphers 13
	4.1.2.5. New Cipher Suites 12		4.1.2.5. New Cipher Suites 13
	4.1.2.6. Anti-replay 13		4.1.2.6. Anti-replay 13
	4.1.2.7. Handling Invalid Records 13		4.1.2.7. Handling Invalid Records 14
	4.2. The DTLS Handshake Protocol 14		4.2. The DTLS Handshake Protocol 14
	4.2.1. Denial of Service Countermeasures 14		4.2.1. Denial of Service Countermeasures 14
	4.2.2. Handshake Message Format 17		4.2.2. Handshake Message Format 17
	4.2.3. Message Fragmentation and Reassembly 18		4.2.3. Handshake Message Fragmentation and Reassembly 19
	4.2.4. Timeout and Retransmission 19		4.2.4. Timeout and Retransmission 19
	4.2.4.1. Timer Values 23		4.2.4.1. Timer Values 23
	4.2.5. ChangeCipherSpec 23		4.2.5. ChangeCipherSpec 23
	4.2.6. CertificateVerify and Finished Messages 23		4.2.6. CertificateVerify and Finished Messages 24
	4.2.7. Alert Messages 23		4.2.7. Alert Messages 24
			4.2.8. Establishing New Associations With Existing Parameters 24
	4.3. Summary of new syntax 24		4.3. Summary of new syntax 24
	4.3.1. Record Layer 25		4.3.1. Record Layer 26
	4.3.2. Handshake Protocol 25		4.3.2. Handshake Protocol 26
	5. Security Considerations 26		5. Security Considerations 27
	6. Acknowledgements 27		6. Acknowledgements 29
	7. IANA Considerations 27		7. IANA Considerations 29
	8. References 27		8. Changes Since DTLS 1.0 29
	8.1. Normative References 27		9. References 30
	8.2. Informative References 28		9.1. Normative References 30
			9.2. Informative References 31
	1. Introduction		1. Introduction
	TLS [TLS] is the most widely deployed protocol for securing network		TLS [TLS] is the most widely deployed protocol for securing network
	traffic. It is widely used for protecting Web traffic and for e-mail		traffic. It is widely used for protecting Web traffic and for e-mail
	protocols such as IMAP [IMAP] and POP [POP]. The primary advantage		protocols such as IMAP [IMAP] and POP [POP]. The primary advantage
	of TLS is that it provides a transparent connection-oriented channel.		of TLS is that it provides a transparent connection-oriented channel.
	Thus, it is easy to secure an application protocol by inserting TLS		Thus, it is easy to secure an application protocol by inserting TLS
	between the application layer and the transport layer. However, TLS		between the application layer and the transport layer. However, TLS
	must run over a reliable transport channel -- typically TCP [TCP].		must run over a reliable transport channel -- typically TCP [TCP].
	skipping to change at page 4, line 34		skipping to change at page 4, line 24
	TLS as possible, both to minimize new security invention and to		TLS as possible, both to minimize new security invention and to
	maximize the amount of code and infrastructure reuse.		maximize the amount of code and infrastructure reuse.
	DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This		DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This
	document introduces a new version of DTLS, DTLS 1.2, which is defined		document introduces a new version of DTLS, DTLS 1.2, which is defined
	as a series of deltas to TLS 1.2 [TLS12] There is no DTLS 1.1. That		as a series of deltas to TLS 1.2 [TLS12] There is no DTLS 1.1. That
	version number was skipped in order to harmonize version numbers with		version number was skipped in order to harmonize version numbers with
	TLS. This version also clarifies some confusing points in the DTLS		TLS. This version also clarifies some confusing points in the DTLS
	1.0 specification.		1.0 specification.
			Implementations that speak both DTLS 1.2 and DTLS 1.0 can
			interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of
			course), just as TLS 1.2 implementations can interoperate with
			previous versions (See Appendix E.1 of [TLS12] for details) with the
			exception that there is no DTLS version of SSLv2 or SSLv3 so that the
			backward compatibility issues for those protocols do not apply.
	1.1. Requirements Terminology		1.1. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [REQ].		document are to be interpreted as described in RFC 2119 [REQ].
	2. Usage Model		2. Usage Model
	The DTLS protocol is designed to secure data between communicating		The DTLS protocol is designed to secure data between communicating
	applications. It is designed to run in application space, without		applications. It is designed to run in application space, without
	skipping to change at page 6, line 4		skipping to change at page 5, line 50
	between records.		between records.
	2. Anti-replay and message reordering protection are provided by a		2. Anti-replay and message reordering protection are provided by a
	MAC that includes a sequence number, but the sequence numbers are		MAC that includes a sequence number, but the sequence numbers are
	implicit in the records.		implicit in the records.
	DTLS solves the first problem by banning stream ciphers. DTLS solves		DTLS solves the first problem by banning stream ciphers. DTLS solves
	the second problem by adding explicit sequence numbers.		the second problem by adding explicit sequence numbers.
	3.2. Providing Reliability for Handshake		3.2. Providing Reliability for Handshake
	The TLS handshake is a lockstep cryptographic handshake. Messages		The TLS handshake is a lockstep cryptographic handshake. Messages
	must be transmitted and received in a defined order, and any other		must be transmitted and received in a defined order, and any other
	order is an error. Clearly, this is incompatible with reordering and		order is an error. Clearly, this is incompatible with reordering and
	message loss. In addition, TLS handshake messages are potentially		message loss. In addition, TLS handshake messages are potentially
	larger than any given datagram, thus creating the problem of		larger than any given datagram, thus creating the problem of IP
	fragmentation. DTLS must provide fixes for both of these problems.		fragmentation. DTLS must provide fixes for both of these problems.
	3.2.1. Packet Loss		3.2.1. Packet Loss
	DTLS uses a simple retransmission timer to handle packet loss. The		DTLS uses a simple retransmission timer to handle packet loss. The
	following figure demonstrates the basic concept, using the first		following figure demonstrates the basic concept, using the first
	phase of the DTLS handshake:		phase of the DTLS handshake:
	Client Server		Client Server
	------ ------		------ ------
	skipping to change at page 6, line 41		skipping to change at page 6, line 39
	server's message is lost the client knows that either the ClientHello		server's message is lost the client knows that either the ClientHello
	or the HelloVerifyRequest has been lost and retransmits. When the		or the HelloVerifyRequest has been lost and retransmits. When the
	server receives the retransmission, it knows to retransmit. The		server receives the retransmission, it knows to retransmit. The
	server also maintains a retransmission timer and retransmits when		server also maintains a retransmission timer and retransmits when
	that timer expires.		that timer expires.
	Note: timeout and retransmission do not apply to the		Note: timeout and retransmission do not apply to the
	HelloVerifyRequest, because this requires creating state on the		HelloVerifyRequest, because this requires creating state on the
	server.		server.
			Note: The HelloVerifyRequest is designed to be small enough that it
			will not itself be fragmented, thus avoiding concerns about
			interleaving multiple HelloVerifyRequests.
	3.2.2. Reordering		3.2.2. Reordering
	In DTLS, each handshake message is assigned a specific sequence		In DTLS, each handshake message is assigned a specific sequence
	number within that handshake. When a peer receives a handshake		number within that handshake. When a peer receives a handshake
	message, it can quickly determine whether that message is the next		message, it can quickly determine whether that message is the next
	message it expects. If it is, then it processes it. If not, it		message it expects. If it is, then it processes it. If not, it
	queues it up for future handling once all previous messages have been		queues it up for future handling once all previous messages have been
	received.		received.
	3.2.3. Message Size		3.2.3. Message Size
	skipping to change at page 7, line 4		skipping to change at page 7, line 6
	3.2.2. Reordering		3.2.2. Reordering
	In DTLS, each handshake message is assigned a specific sequence		In DTLS, each handshake message is assigned a specific sequence
	number within that handshake. When a peer receives a handshake		number within that handshake. When a peer receives a handshake
	message, it can quickly determine whether that message is the next		message, it can quickly determine whether that message is the next
	message it expects. If it is, then it processes it. If not, it		message it expects. If it is, then it processes it. If not, it
	queues it up for future handling once all previous messages have been		queues it up for future handling once all previous messages have been
	received.		received.
	3.2.3. Message Size		3.2.3. Message Size
	TLS and DTLS handshake messages can be quite large (in theory up to		TLS and DTLS handshake messages can be quite large (in theory up to
	2^24-1 bytes, in practice many kilobytes). By contrast, UDP		2^24-1 bytes, in practice many kilobytes). By contrast, UDP
	datagrams are often limited to <1500 bytes if fragmentation is not		datagrams are often limited to <1500 bytes if IP fragmentation is not
	desired. In order to compensate for this limitation, each DTLS		desired. In order to compensate for this limitation, each DTLS
	handshake message may be fragmented over several DTLS records. Each		handshake message may be fragmented over several DTLS records, each
	DTLS handshake message contains both a fragment offset and a fragment		of which is intended to fit in a single IP datagram. Each DTLS
			handshake message contains both a fragment offset and a fragment
	length. Thus, a recipient in possession of all bytes of a handshake		length. Thus, a recipient in possession of all bytes of a handshake
	message can reassemble the original unfragmented message.		message can reassemble the original unfragmented message.
	3.3. Replay Detection		3.3. Replay Detection
	DTLS optionally supports record replay detection. The technique used		DTLS optionally supports record replay detection. The technique used
	is the same as in IPsec AH/ESP, by maintaining a bitmap window of		is the same as in IPsec AH/ESP, by maintaining a bitmap window of
	received records. Records that are too old to fit in the window and		received records. Records that are too old to fit in the window and
	records that have previously been received are silently discarded.		records that have previously been received are silently discarded.
	The replay detection feature is optional, since packet duplication is		The replay detection feature is optional, since packet duplication is
	skipping to change at page 9, line 24		skipping to change at page 9, line 26
	packets may be sent still apply, and the receiver treats the packets		packets may be sent still apply, and the receiver treats the packets
	as if they were sent in the right order. In particular, it is still		as if they were sent in the right order. In particular, it is still
	impermissible to send data prior to completion of the first		impermissible to send data prior to completion of the first
	handshake.		handshake.
	Note that in the special case of a rehandshake on an existing		Note that in the special case of a rehandshake on an existing
	association, it is safe to process a data packet immediately even if		association, it is safe to process a data packet immediately even if
	the ChangeCipherSpec or Finished has not yet been received provided		the ChangeCipherSpec or Finished has not yet been received provided
	that either the rehandshake resumes the existing session or that it		that either the rehandshake resumes the existing session or that it
	uses exactly the same security parameters as the existing		uses exactly the same security parameters as the existing
	association. In an other case, the implementation MUST wait for the		association. In any other case, the implementation MUST wait for the
	receipt of the Finished to prevent downgrade attack.		receipt of the Finished to prevent downgrade attack.
			As in TLS, implementations MUST either abandon an association or
			rehandshake prior to allowing the sequence number to wrap. Similarly,
			implementations MUST NOT allow the epoch to wrap, but instead MUST
			establish a new association, terminating the old association as
			described in Section 4.2.8. In practice, implementations rarely
			rehandshake repeatedly on the same channel, so this is not likely to
			be an issue.
	4.1.1. Transport Layer Mapping		4.1.1. Transport Layer Mapping
	Each DTLS record MUST fit within a single datagram. In order to		Each DTLS record MUST fit within a single datagram. In order to
	avoid fragmentation, clients of the DTLS record layer SHOULD attempt		avoid IP fragmentation, clients of the DTLS record layer SHOULD
	to size records so that they fit within any PMTU estimates obtained		attempt to size records so that they fit within any PMTU estimates
	from the record layer.		obtained from the record layer.
	Note that unlike IPsec, DTLS records do not contain any association		Note that unlike IPsec, DTLS records do not contain any association
	identifiers. Applications must arrange to multiplex between		identifiers. Applications must arrange to multiplex between
	associations. With UDP, this is presumably done with host/port		associations. With UDP, this is presumably done with host/port
	number.		number.
	Multiple DTLS records may be placed in a single datagram. They are		Multiple DTLS records may be placed in a single datagram. They are
	simply encoded consecutively. The DTLS record framing is sufficient		simply encoded consecutively. The DTLS record framing is sufficient
	to determine the boundaries. Note, however, that the first byte of		to determine the boundaries. Note, however, that the first byte of
	the datagram payload must be the beginning of a record. Records may		the datagram payload must be the beginning of a record. Records may
	skipping to change at page 10, line 30		skipping to change at page 10, line 39
	In general, DTLS's philosophy is to leave PMTU discovery to the		In general, DTLS's philosophy is to leave PMTU discovery to the
	application. However, DTLS cannot completely ignore PMTU for three		application. However, DTLS cannot completely ignore PMTU for three
	reasons:		reasons:
	- The DTLS record framing expands the datagram size,		- The DTLS record framing expands the datagram size,
	thus lowering the effective PMTU from the application's		thus lowering the effective PMTU from the application's
	perspective.		perspective.
	- In some implementations the application may not directly		- In some implementations the application may not directly
	talk to the network, in which case the DTLS stack may		talk to the network, in which case the DTLS stack may
	absorb ICMP [RFC1191] Datagram Too Big indications.		absorb ICMP [RFC1191] Datagram Too Big indications
			or ICMPv6 [RFC1885] Packet Too Big indications.
	- The DTLS handshake messages can exceed the PMTU.		- The DTLS handshake messages can exceed the PMTU.
	In order to deal with the first two issues, the DTLS record layer		In order to deal with the first two issues, the DTLS record layer
	SHOULD behave as described below.		SHOULD behave as described below.
	If PMTU estimates are available from the underlying transport		If PMTU estimates are available from the underlying transport
	protocol, they should be made available to upper layer protocols. In		protocol, they should be made available to upper layer protocols. In
	particular:		particular:
	- For DTLS over UDP, the upper layer protocol SHOULD be allowed		- For DTLS over UDP, the upper layer protocol SHOULD be allowed
	to obtain the PMTU estimate maintained in the IP layer.		to obtain the PMTU estimate maintained in the IP layer.
	- For DTLS over DCCP, the upper layer protocol		- For DTLS over DCCP, the upper layer protocol
	SHOULD be allowed to obtain the current estimate of the		SHOULD be allowed to obtain the current estimate of the
	PMTU.		PMTU.
	- For DTLS over TCP or SCTP, which automatically fragment		- For DTLS over TCP or SCTP, which automatically fragment
	and reassemble datagrams, there is no PMTU limitation.		and reassemble datagrams, there is no PMTU limitation.
	However, the upper layer protocol MUST NOT write any		However, the upper layer protocol MUST NOT write any
	record that exceeds the maximum record size of 2^14 bytes.		record that exceeds the maximum record size of 2^14 bytes.
	The DTLS record layer SHOULD allow the upper layer protocol to		The DTLS record layer SHOULD allow the upper layer protocol to
	discover the amount of record expansion expected by the DTLS		discover the amount of record expansion expected by the DTLS
	processing. Note that this number is only an estimate because of		processing. Note that this number is only an estimate because of
	block padding and the potential use of DTLS compression.		block padding and the potential use of DTLS compression.
	If there is a transport protocol indication (either via ICMP or via a		If there is a transport protocol indication (either via ICMP or via a
	refusal to send the datagram as in DCCP Section 14), then DTLS record		refusal to send the datagram as in DCCP Section 14), then the DTLS
	layer should inform the upper layer protocol of the error.		record layer MUST inform the upper layer protocol of the error.
	The DTLS record layer SHOULD NOT interfere with upper layer protocols		The DTLS record layer SHOULD NOT interfere with upper layer protocols
	performing PMTU discovery, whether via [RFC1191] or [RFC4821]		performing PMTU discovery, whether via [RFC1191] or [RFC4821]
	mechanisms. In particular:		mechanisms. In particular:
	- Where allowed by the underlying transport protocol,		- Where allowed by the underlying transport protocol,
	the upper layer protocol SHOULD be allowed to set		the upper layer protocol SHOULD be allowed to set
	the state of the DF bit (in IPv4) or prohibit local		the state of the DF bit (in IPv4) or prohibit local
	fragmentation (in IPv6).		fragmentation (in IPv6).
	skipping to change at page 12, line 23		skipping to change at page 12, line 35
	253} for DTLS 1.2.		253} for DTLS 1.2.
	Note that one important difference between DTLS and TLS MAC handling		Note that one important difference between DTLS and TLS MAC handling
	is that in TLS MAC errors must result in connection termination. In		is that in TLS MAC errors must result in connection termination. In
	DTLS, the receiving implementation MAY simply discard the offending		DTLS, the receiving implementation MAY simply discard the offending
	record and continue with the connection. This change is possible		record and continue with the connection. This change is possible
	because DTLS records are not dependent on each other in the way that		because DTLS records are not dependent on each other in the way that
	TLS records are.		TLS records are.
	In general, DTLS implementations SHOULD silently discard records with		In general, DTLS implementations SHOULD silently discard records with
	bad MACs or that are otherwise invalid. If a DTLS implementation		bad MACs or that are otherwise invalid. They MAY log an error. If a
	chooses to generate an alert when it receives a message with an		DTLS implementation chooses to generate an alert when it receives a
	invalid MAC, it MUST generate a bad_record_mac alert with level fatal		message with an invalid MAC, it MUST generate a bad_record_mac alert
	and terminate its connection state.		with level fatal and terminate its connection state.
	4.1.2.2. Null or Standard Stream Cipher		4.1.2.2. Null or Standard Stream Cipher
	The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher.		The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher.
	The only stream cipher described in TLS 1.2 is RC4, which cannot be		The only stream cipher described in TLS 1.2 is RC4, which cannot be
	randomly accessed. RC4 MUST NOT be used with DTLS.		randomly accessed. RC4 MUST NOT be used with DTLS.
	4.1.2.3. Block Cipher		4.1.2.3. Block Cipher
	skipping to change at page 12, line 50		skipping to change at page 13, line 15
	4.1.2.3. AEAD Ciphers		4.1.2.3. AEAD Ciphers
	TLS 1.2 introduced authenticated encryption with additional data		TLS 1.2 introduced authenticated encryption with additional data
	(AEAD) cipher suites. The existing AEAD cipher suites, defined in		(AEAD) cipher suites. The existing AEAD cipher suites, defined in
	[ECCGCM] and [RSAGCM] can be used with DTLS exactly as with TLS 1.2.		[ECCGCM] and [RSAGCM] can be used with DTLS exactly as with TLS 1.2.
	4.1.2.5. New Cipher Suites		4.1.2.5. New Cipher Suites
	Upon registration, new TLS cipher suites MUST indicate whether they		Upon registration, new TLS cipher suites MUST indicate whether they
	are suitable for DTLS usage and what, if any, adaptations must be		are suitable for DTLS usage and what, if any, adaptations must be
	made.		made (See Section 7 for IANA considerations).
	4.1.2.6. Anti-replay		4.1.2.6. Anti-replay
	DTLS records contain a sequence number to provide replay protection.		DTLS records contain a sequence number to provide replay protection.
	Sequence number verification SHOULD be performed using the following		Sequence number verification SHOULD be performed using the following
	sliding window procedure, borrowed from Section 3.4.3 of [ESP].		sliding window procedure, borrowed from Section 3.4.3 of [ESP].
	The receiver packet counter for this session MUST be initialized to		The receiver packet counter for this session MUST be initialized to
	zero when the session is established. For each received record, the		zero when the session is established. For each received record, the
	receiver MUST verify that the record contains a Sequence Number that		receiver MUST verify that the record contains a Sequence Number that
	skipping to change at page 13, line 43		skipping to change at page 14, line 7
	performing this check, based on the use of a bit mask, is described		performing this check, based on the use of a bit mask, is described
	in Section 3.4.3 of [ESP].		in Section 3.4.3 of [ESP].
	If the received record falls within the window and is new, or if the		If the received record falls within the window and is new, or if the
	packet is to the right of the window, then the receiver proceeds to		packet is to the right of the window, then the receiver proceeds to
	MAC verification. If the MAC validation fails, the receiver MUST		MAC verification. If the MAC validation fails, the receiver MUST
	discard the received record as invalid. The receive window is		discard the received record as invalid. The receive window is
	updated only if the MAC verification succeeds.		updated only if the MAC verification succeeds.
	4.1.2.7. Handling Invalid Records		4.1.2.7. Handling Invalid Records
	Unlike TLS, DTLS is resilient in the face of invalid
	records (e.g., invalid formatting, length, MAC, etc.) In		Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
	general, invalid records SHOULD be silently discarded, thus		invalid formatting, length, MAC, etc.) In general, invalid records
	preserving the association. Implementations which choose to		SHOULD be silently discarded, thus preserving the association,
	generate an alert instead, MUST generate fatal level alerts to		however an error MAY be logged for diagnostic purposes.
	avoid attacks where the attacker repeatedly probes the		Implementations which choose to generate an alert instead, MUST
	implementation to see how it responds to various types of error.		generate fatal level alerts to avoid attacks where the attacker
	Note that if DTLS is run over UDP, then any implementation which		repeatedly probes the implementation to see how it responds to
	does this will be extremely susceptible to DoS attacks because		various types of error. Note that if DTLS is run over UDP, then any
	UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED		implementation which does this will be extremely susceptible to DoS
	for such transports. If DTLS is being carried over a		attacks because UDP forgery is so easy. Thus, this practice is NOT
	transport which is resistant to forgery (e.g., SCTP with SCTP-		RECOMMENDED for such transports.
	AUTH), then it is safer to send alerts because an attacker will
	have difficulty forging a datagram which will not be rejected by the		If DTLS is being carried over a transport which is resistant to
	transport layer.		forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts
			because an attacker will have difficulty forging a datagram which
			will not be rejected by the transport layer.
	4.2. The DTLS Handshake Protocol		4.2. The DTLS Handshake Protocol
	DTLS uses all of the same handshake messages and flows as TLS, with		DTLS uses all of the same handshake messages and flows as TLS, with
	three principal changes:		three principal changes:
	1. A stateless cookie exchange has been added to prevent denial of		1. A stateless cookie exchange has been added to prevent denial of
	service attacks.		service attacks.
	2. Modifications to the handshake header to handle message loss,		2. Modifications to the handshake header to handle message loss,
	reordering, and fragmentation.		reordering, and DTLS message fragmentation (in order to avoid IP
			fragmentation).
	3. Retransmission timers to handle message loss.		3. Retransmission timers to handle message loss.
	With these exceptions, the DTLS message formats, flows, and logic are		With these exceptions, the DTLS message formats, flows, and logic are
	the same as those of TLS 1.2.		the same as those of TLS 1.2.
	4.2.1. Denial of Service Countermeasures		4.2.1. Denial of Service Countermeasures
	Datagram security protocols are extremely susceptible to a variety of		Datagram security protocols are extremely susceptible to a variety of
	denial of service (DoS) attacks. Two attacks are of particular		denial of service (DoS) attacks. Two attacks are of particular
	skipping to change at page 17, line 4		skipping to change at page 17, line 20
	handshake.		handshake.
	If HelloVerifyRequest is used, the initial ClientHello and		If HelloVerifyRequest is used, the initial ClientHello and
	HelloVerifyRequest are not included in the calculation of the		HelloVerifyRequest are not included in the calculation of the
	handshake_messages (for the CertificateVerify message) and		handshake_messages (for the CertificateVerify message) and
	verify_data (for the Finished message).		verify_data (for the Finished message).
	If a server receives a ClientHello with an invalid cookie, it SHOULD		If a server receives a ClientHello with an invalid cookie, it SHOULD
	treat it the same as a ClientHello with no cookie. This avoids		treat it the same as a ClientHello with no cookie. This avoids
	race/deadlock conditions if the client somehow gets a bad cookie		race/deadlock conditions if the client somehow gets a bad cookie
	(e.g., because the server changes its cookie signing key). Note to		(e.g., because the server changes its cookie signing key).
	implementors: this may results in clients receiving multiple
			Note to implementors: this may results in clients receiving multiple
	HelloVerifyRequest messages with different cookies. Clients SHOULD		HelloVerifyRequest messages with different cookies. Clients SHOULD
	handle this by sending a new ClientHello with a cookie in response to		handle this by sending a new ClientHello with a cookie in response to
	the new HelloVerifyRequest.		the new HelloVerifyRequest. Note that this message should have the
			same handshake sequence number (0) and record sequence number (0),
			thus avoiding the need to create state on the server. This also
			implies that the client MUST NOT do replay suppression during the
			initial handshake (this is safe as handshake messages have their own
			sequence numbers). [OPEN ISSUE: It's not clear that this is the best
			choice. Michael Tuexen suggested mimicing the client's record
			sequence number instead.]
	4.2.2. Handshake Message Format		4.2.2. Handshake Message Format
	In order to support message loss, reordering, and fragmentation, DTLS		In order to support message loss, reordering, and message
	modifies the TLS 1.2 handshake header:		fragmentation, DTLS modifies the TLS 1.2 handshake header:
	struct {		struct {
	HandshakeType msg_type;		HandshakeType msg_type;
	uint24 length;		uint24 length;
	uint16 message_seq; // New field		uint16 message_seq; // New field
	uint24 fragment_offset; // New field		uint24 fragment_offset; // New field
	uint24 fragment_length; // New field		uint24 fragment_length; // New field
	select (HandshakeType) {		select (HandshakeType) {
	case hello_request: HelloRequest;		case hello_request: HelloRequest;
	case client_hello: ClientHello;		case client_hello: ClientHello;
	skipping to change at page 18, line 30		skipping to change at page 19, line 6
	DTLS implementations maintain (at least notionally) a		DTLS implementations maintain (at least notionally) a
	next_receive_seq counter. This counter is initially set to zero.		next_receive_seq counter. This counter is initially set to zero.
	When a message is received, if its sequence number matches		When a message is received, if its sequence number matches
	next_receive_seq, next_receive_seq is incremented and the message is		next_receive_seq, next_receive_seq is incremented and the message is
	processed. If the sequence number is less than next_receive_seq, the		processed. If the sequence number is less than next_receive_seq, the
	message MUST be discarded. If the sequence number is greater than		message MUST be discarded. If the sequence number is greater than
	next_receive_seq, the implementation SHOULD queue the message but MAY		next_receive_seq, the implementation SHOULD queue the message but MAY
	discard it. (This is a simple space/bandwidth tradeoff).		discard it. (This is a simple space/bandwidth tradeoff).
	4.2.3. Message Fragmentation and Reassembly		4.2.3. Handshake Message Fragmentation and Reassembly
	As noted in Section 4.1.1, each DTLS message MUST fit within a single		As noted in Section 4.1.1, each DTLS message MUST fit within a single
	transport layer datagram. However, handshake messages are		transport layer datagram. However, handshake messages are
	potentially bigger than the maximum record size. Therefore, DTLS		potentially bigger than the maximum record size. Therefore, DTLS
	provides a mechanism for fragmenting a handshake message over a		provides a mechanism for fragmenting a handshake message over a
	number of records.		number of records, each of which can be transmitted separately, thus
			avoiding IP fragmentation.
	When transmitting the handshake message, the sender divides the		When transmitting the handshake message, the sender divides the
	message into a series of N contiguous data ranges. These ranges MUST		message into a series of N contiguous data ranges. These ranges MUST
	NOT be larger than the maximum handshake fragment size and MUST		NOT be larger than the maximum handshake fragment size and MUST
	jointly contain the entire handshake message. The ranges SHOULD NOT		jointly contain the entire handshake message. The ranges SHOULD NOT
	overlap. The sender then creates N handshake messages, all with the		overlap. The sender then creates N handshake messages, all with the
	same message_seq value as the original handshake message. Each new		same message_seq value as the original handshake message. Each new
	message is labelled with the fragment_offset (the number of bytes		message is labelled with the fragment_offset (the number of bytes
	contained in previous fragments) and the fragment_length (the length		contained in previous fragments) and the fragment_length (the length
	of this fragment). The length field in all messages is the same as		of this fragment). The length field in all messages is the same as
	skipping to change at page 22, line 48		skipping to change at page 22, line 48
	(whether partial messages or only some of the messages in the		(whether partial messages or only some of the messages in the
	flight) do not cause state transitions or timer resets.		flight) do not cause state transitions or timer resets.
	Because DTLS clients send the first message (ClientHello), they start		Because DTLS clients send the first message (ClientHello), they start
	in the PREPARING state. DTLS servers start in the WAITING state, but		in the PREPARING state. DTLS servers start in the WAITING state, but
	with empty buffers and no retransmit timer.		with empty buffers and no retransmit timer.
	When the server desires a rehandshake, it transitions from the		When the server desires a rehandshake, it transitions from the
	FINISHED state to the PREPARING state to transmit the HelloRequest.		FINISHED state to the PREPARING state to transmit the HelloRequest.
	When the client receives a HelloRequest it transitions from FINISHED		When the client receives a HelloRequest it transitions from FINISHED
	to PREPARING to transmit the ClientHello. In addition, for at least		to PREPARING to transmit the ClientHello.
	2MSL, when in the FINISHED state, the node which transmits the last
	flight (the server in an ordinary handshake or the client in a		In addition, for at least 2MSL, when in the FINISHED state, the node
	resumed handshake) MUST respond to a retransmit of the peer's last		which transmits the last flight (the server in an ordinary handshake
	flight with a retransmit of the last flight. This avoids deadlock		or the client in a resumed handshake) MUST respond to a retransmit of
	conditions if the last flight gets lost. This requirement applies to		the peer's last flight with a retransmit of the last flight. This
	DTLS 1.0 as well, and though not explicit in [DTLS1] but was always		avoids deadlock conditions if the last flight gets lost. This
	required for the state machine to function correctly.		requirement applies to DTLS 1.0 as well, and though not explicit in
			[DTLS1] but was always required for the state machine to function
			correctly. To see why this is necessary, consider what happens in an
			ordinary handshake if the server's Finished is lost: the server
			believes the handshake is complete but it actually is not. As the
			client is waiting for the Finished, the client's retransmit timer
			will fire and it will retransmit the client Finished, causing the
			server to respond with its own Finished, completing the handshake.
			The same logic applies on the server side for the resumed handshake.
			Note that because of packet loss it is possible for one side to be
			sending application data even though the other side has not received
			the first side's Finished. Implementations MUST either discard or
			buffer all application data packets for the new epoch until they have
			received the Finished for that epoch. Implementations MAY treat
			receipt of application data with a new epoch prior to receipt of the
			corresponding Finished as evidence of reordering or packet loss and
			retransmit their final flight immediately, shortcutting the
			retransmission timer.
	4.2.4.1. Timer Values		4.2.4.1. Timer Values
	Though timer values are the choice of the implementation, mishandling		Though timer values are the choice of the implementation, mishandling
	of the timer can lead to serious congestion problems; for example, if		of the timer can lead to serious congestion problems; for example, if
	many instances of a DTLS time out early and retransmit too quickly on		many instances of a DTLS time out early and retransmit too quickly on
	a congested link. Implementations SHOULD use an initial timer value		a congested link. Implementations SHOULD use an initial timer value
	of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double		of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double
	the value at each retransmission, up to no less than the RFC 2988		the value at each retransmission, up to no less than the RFC 2988
	maximum of 60 seconds. Note that we recommend a 1-second timer		maximum of 60 seconds. Note that we recommend a 1-second timer
	skipping to change at page 23, line 43		skipping to change at page 24, line 13
	handshake message but MUST be treated as part of the same flight as		handshake message but MUST be treated as part of the same flight as
	the associated Finished message for the purposes of timeout and		the associated Finished message for the purposes of timeout and
	retransmission.		retransmission.
	4.2.6. CertificateVerify and Finished Messages		4.2.6. CertificateVerify and Finished Messages
	CertificateVerify and Finished messages have the same format as in		CertificateVerify and Finished messages have the same format as in
	TLS. Hash calculations include entire handshake messages, including		TLS. Hash calculations include entire handshake messages, including
	DTLS specific fields: message_seq, fragment_offset and		DTLS specific fields: message_seq, fragment_offset and
	fragment_length. However, in order to remove sensitivity to		fragment_length. However, in order to remove sensitivity to
	fragmentation, the Finished MAC MUST be computed as if each handshake		handshake message fragmentation, the Finished MAC MUST be computed as
	message had been sent as a single fragment. Note that in cases where		if each handshake message had been sent as a single fragment. Note
	the cookie exchange is used, the initial ClientHello and		that in cases where the cookie exchange is used, the initial
	HelloVerifyRequest MUST NOT be included in the CertificateVerify or		ClientHello and HelloVerifyRequest MUST NOT be included in the
	Finished MAC computations.		CertificateVerify or Finished MAC computations.
	4.2.7. Alert Messages		4.2.7. Alert Messages
	Note that Alert messages are not retransmitted at all, even when they		Note that Alert messages are not retransmitted at all, even when they
	occur in the context of a handshake. However, a DTLS implementation		occur in the context of a handshake. However, a DTLS implementation
	SHOULD generate a new alert message if the offending record is		SHOULD generate a new alert message if the offending record is
	received again (e.g., as a retransmitted handshake message).		received again (e.g., as a retransmitted handshake message).
	Implementations SHOULD detect when a peer is persistently sending bad		Implementations SHOULD detect when a peer is persistently sending bad
	messages and terminate the local connection state after such		messages and terminate the local connection state after such
	misbehavior is detected.		misbehavior is detected.
			4.2.8. Establishing New Associations With Existing Parameters
			If a DTLS client-server pair are configured in such a way that
			repeated connections happen on the same host/port quartet, then it is
			possible that a client will silently abandon one connection and then
			initiate another with the same parameters (e.g., after a reboot).
			This will appear to the server as a new handshake with epoch=0. In
			cases where a server believes it has an existing association on a
			given host/port quartet and it receives an epoch=0 ClientHello, it
			SHOULD proceed with a new handshake but MUST NOT destroy the existing
			association until the client has demonstrated reachability either by
			completing a cookie exchange or by completing a complete handshake
			including delivering a verifiable Finished message. After a correct
			Finished is received, the server MUST abandon the previous
			association to avoid confusion between two valid associations with
			overlapping epochs. The reachability requirement prevents off-
			path/blind attackers from destroying associations merely by sending
			forged ClientHellos.
	4.3. Summary of new syntax		4.3. Summary of new syntax
	This section includes specifications for the data structures that		This section includes specifications for the data structures that
	have changed between TLS 1.2 and DTLS.		have changed between TLS 1.2 and DTLS 1.2. See [TLS12] for the
			definition of this syntax.
	4.3.1. Record Layer		4.3.1. Record Layer
	struct {		struct {
	ContentType type;		ContentType type;
	ProtocolVersion version;		ProtocolVersion version;
	uint16 epoch; // New field		uint16 epoch; // New field
	uint48 sequence_number; // New field		uint48 sequence_number; // New field
	uint16 length;		uint16 length;
	opaque fragment[DTLSPlaintext.length];		opaque fragment[DTLSPlaintext.length];
	skipping to change at page 27, line 5		skipping to change at page 27, line 51
	of denial of service. DTLS includes a cookie exchange designed to		of denial of service. DTLS includes a cookie exchange designed to
	protect against denial of service. However, implementations which do		protect against denial of service. However, implementations which do
	not use this cookie exchange are still vulnerable to DoS. In		not use this cookie exchange are still vulnerable to DoS. In
	particular, DTLS servers which do not use the cookie exchange may be		particular, DTLS servers which do not use the cookie exchange may be
	used as attack amplifiers even if they themselves are not		used as attack amplifiers even if they themselves are not
	experiencing DoS. Therefore, DTLS servers SHOULD use the cookie		experiencing DoS. Therefore, DTLS servers SHOULD use the cookie
	exchange unless there is good reason to believe that amplification is		exchange unless there is good reason to believe that amplification is
	not a threat in their environment. Clients MUST be prepared to do a		not a threat in their environment. Clients MUST be prepared to do a
	cookie exchange with every handshake.		cookie exchange with every handshake.
			Unlike TLS implementations DTLS implementations SHOULD NOT respond to
			invalid records by terminating the connection. See Section 4.1.2.7
			for details on this.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley,		The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley,
	Constantine Sapuntzakis, and Hovav Shacham for discussions and		Constantine Sapuntzakis, and Hovav Shacham for discussions and
	comments on the design of DTLS. Thanks to the anonymous NDSS		comments on the design of DTLS. Thanks to the anonymous NDSS
	reviewers of our original NDSS paper on DTLS [DTLS] for their		reviewers of our original NDSS paper on DTLS [DTLS] for their
	comments. Also, thanks to Steve Kent for feedback that helped		comments. Also, thanks to Steve Kent for feedback that helped
	clarify many points. The section on PMTU was cribbed from the DCCP		clarify many points. The section on PMTU was cribbed from the DCCP
	specification [DCCP]. Pasi Eronen provided a detailed review of this		specification [DCCP]. Pasi Eronen provided a detailed review of this
	specification. Helpful comments on the document were also received		specification. Peter Saint-Andre provided the changes list in Section
	from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Joel		8. elpful comments on the document were also received from Mark
	Halpern, Ted Hardie, Allison Mankin, Robin Seggelman and Michael		Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Adrian Farrell,
	Tuexen.		Joel Halpern, Ted Hardie, Charlia Kaufman, Pekka Savola, Allison
			Mankin, Nikos Mavrogiannopoulos, Alexey Melnikov, Robin Seggelman,
			Michael Tuexen, Juho Vaha-Herttua, and Florian Weimer.
	7. IANA Considerations		7. IANA Considerations
	This document uses the same identifier space as TLS [TLS12], so no		This document uses the same identifier space as TLS [TLS12], so no
	new IANA registries are required. When new identifiers are assigned		new IANA registries are required. When new identifiers are assigned
	for TLS, authors MUST specify whether they are suitable for DTLS.		for TLS, authors MUST specify whether they are suitable for DTLS.
			IANA [should modify/has modified] all TLS parameter registries to add
			a DTLS-OK flag, indicating whether the specification may be used with
			DTLS.
	This document defines a new handshake message, hello_verify_request,		This document defines a new handshake message, hello_verify_request,
	whose value has been allocated from the TLS HandshakeType registry		whose value has been allocated from the TLS HandshakeType registry
	defined in [TLS12]. The value "3" has been assigned by the IANA.		defined in [TLS12]. The value "3" has been assigned by the IANA.
	8. References		8. Changes Since DTLS 1.0
	8.1. Normative References		This document reflects the following changes since DTLS 1.0 [DTLS1].
			- Updated to match TLS 1.2 [TLS12].
			- Addition of AEAD Ciphers in Section 4.1.2.3 (tracking changes in
			TLS 1.2.
			- Clarifications regarding sequence numbers and epochs in Section 4.1
			and a clear procedure for dealing with state loss in Section 4.2.8.
			- Clarifications and more detailed rules regarding Path MTU issues in
			Section 4.1.1.1. Clarification of the fragmentation text throughout.
			- Clarifications regarding handling of invalid records in Section 4.1.2.7.
			- A new paragraph describing handling of invalid cookies at the end of
			Section 4.2.1.
			- Some new text describing how to avoid handshake deadlock conditions
			at the end of Section 4.2.4.
			- Some new text about CertificateVerify messages in Section 4.2.6.
			- A prohibition on epoch wrapping in Section 4.1.
			- Clarification of the IANA requirements and the explicit requirement
			for a new IANA registration flag for each parameter.
			- Numerous editorial changes.
			9. References
			9.1. Normative References
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	November 1990.		November 1990.
			[RFC1885] Conta, A., and S. Deering, "Internet Control Message
			Protocol (ICMPv6) for the Internet Protocol Version 6
			(IPv6) Specification", RFC 1885, December 1995.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission		[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
	Timer", RFC 2988, November 2000.		Timer", RFC 2988, November 2000.
	[RFC4821] Mathis, M., and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M., and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, March 2007.		Discovery", RFC 4821, March 2007.
	[RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher		[RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
	Suites for TLS", RFC 5288, August 2008.		Suites for TLS", RFC 5288, August 2008.
	[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC		[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
	793, September 1981.		793, September 1981.
	[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, May 2008.		(TLS) Protocol Version 1.2", RFC 5246, May 2008.
	8.2. Informative References		9.2. Informative References
	[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram		[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
	Congestion Control Protocol", Work in Progress, 10 March		Congestion Control Protocol", Work in Progress, 10 March
	2005.		2005.
	[DCCPDTLS] T. Phelan, "Datagram Transport Layer Security (DTLS) over		[DCCPDTLS] T. Phelan, "Datagram Transport Layer Security (DTLS) over
	the Datagram Congestion Control Protocol (DCCP)", RFC		the Datagram Congestion Control Protocol (DCCP)", RFC
	5238, May 2008.		5238, May 2008.
	[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation		[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation
	skipping to change at page 28, line 32		skipping to change at page 31, line 32
	[ECCGCM] E. Rescorla, "TLS Elliptic Curve Cipher Suites with		[ECCGCM] E. Rescorla, "TLS Elliptic Curve Cipher Suites with
	SHA-256/384 and AES Galois Counter Mode", RFC 5289, August		SHA-256/384 and AES Galois Counter Mode", RFC 5289, August
	2008.		2008.
	[ESP] S. Kent "IP Encapsulating Security Payload (ESP)", RFC		[ESP] S. Kent "IP Encapsulating Security Payload (ESP)", RFC
	4303, December 2005.		4303, December 2005.
	[IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol",		[IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
	Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
	December 2005.
	[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, March 2003.		4rev1", RFC 3501, March 2003.
	[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management		[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
	Protocol", RFC 2522, March 1999.		Protocol", RFC 2522, March 1999.
	[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3",		[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
	STD 53, RFC 1939, May 1996.		STD 53, RFC 1939, May 1996.
	[REQ] Bradner, S., "Key words for use in RFCs to Indicate		[REQ] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 29, line 10		skipping to change at page 32, line 7
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security		[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",		[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
	Work in Progress, October 2003.		RFC 5406, October 2003.
	Authors' Addresses		Authors' Addresses
	Eric Rescorla		Eric Rescorla
	RTFM, Inc.		RTFM, Inc.
	2064 Edgewood Drive		2064 Edgewood Drive
	Palo Alto, CA 94303		Palo Alto, CA 94303
	EMail: ekr@rtfm.com		EMail: ekr@rtfm.com
End of changes. 55 change blocks.
	147 lines changed or deleted		255 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/