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/