draft-ietf-tls-rfc4347-bis-03.txt   draft-ietf-tls-rfc4347-bis-04.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-03.txt> Stanford University <draft-ietf-tls-rfc4347-bis-04.txt> Stanford University
October 7, 2009 (Expires April 2010) July 12, 2010 (Expires January 2011)
Datagram Transport Layer Security version 1.2 Datagram Transport Layer Security version 1.2
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF 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 Copyright (c) 2010 IETF Trust and the persons identified as
Task Force (IETF), its areas, and its working groups. Note that the document authors. All rights reserved.
other groups may also distribute working documents as Internet-
Drafts. 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 document may contain material from IETF Documents or IETF
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
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
skipping to change at page 3, line 50 skipping to change at page 4, line 15
as the Session Initiation Protocol (SIP) [SIP] and electronic gaming as the Session Initiation Protocol (SIP) [SIP] and electronic gaming
protocols are increasingly popular. (Note that SIP can run over both protocols are increasingly popular. (Note that SIP can run over both
TCP and UDP, but that there are situations in which UDP is TCP and UDP, but that there are situations in which UDP is
preferable). Currently, designers of these applications are faced preferable). Currently, designers of these applications are faced
with a number of unsatisfactory choices. First, they can use IPsec with a number of unsatisfactory choices. First, they can use IPsec
[RFC4301]. However, for a number of reasons detailed in [WHYIPSEC], [RFC4301]. However, for a number of reasons detailed in [WHYIPSEC],
this is only suitable for some applications. Second, they can design this is only suitable for some applications. Second, they can design
a custom application layer security protocol. Unfortunately, a custom application layer security protocol. Unfortunately,
although application layer security protocols generally provide although application layer security protocols generally provide
superior security properties (e.g., end-to-end security in the case superior security properties (e.g., end-to-end security in the case
of S/MIME), they typically requires a large amount of effort to of S/MIME), they typically require a large amount of effort to design
design -- in contrast to the relatively small amount of effort -- in contrast to the relatively small amount of effort required to
required to run the protocol over TLS. run the protocol over TLS.
In many cases, the most desirable way to secure client/server In many cases, the most desirable way to secure client/server
applications would be to use TLS; however, the requirement for applications would be to use TLS; however, the requirement for
datagram semantics automatically prohibits use of TLS. This memo datagram semantics automatically prohibits use of TLS. This memo
describes a protocol for this purpose: Datagram Transport Layer describes a protocol for this purpose: Datagram Transport Layer
Security (DTLS). DTLS is deliberately designed to be as similar to Security (DTLS). DTLS is deliberately designed to be as similar to
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
skipping to change at page 5, line 20 skipping to change at page 5, line 22
reordered. TLS has no internal facilities to handle this kind of reordered. TLS has no internal facilities to handle this kind of
unreliability, and therefore TLS implementations break when rehosted unreliability, and therefore TLS implementations break when rehosted
on datagram transport. The purpose of DTLS is to make only the on datagram transport. The purpose of DTLS is to make only the
minimal changes to TLS required to fix this problem. To the greatest minimal changes to TLS required to fix this problem. To the greatest
extent possible, DTLS is identical to TLS. Whenever we need to extent possible, DTLS is identical to TLS. Whenever we need to
invent new mechanisms, we attempt to do so in such a way that invent new mechanisms, we attempt to do so in such a way that
preserves the style of TLS. preserves the style of TLS.
Unreliability creates problems for TLS at two levels: Unreliability creates problems for TLS at two levels:
1. TLS's traffic encryption layer does not allow independent 1. TLS does not allow independent decryption of individual
decryption of individual records. If record N is not received, records. Because the integrity check depends on the sequence
then record N+1 cannot be decrypted. number, if record N is not received, then the integrity check on
record N+1 will be based on the wrong sequence number and thus
will fail. [Note that prior to TLS 1.1, there was no explicit IV
and so decryption would also fail.]
2. The TLS handshake layer assumes that handshake messages are 2. The TLS handshake layer assumes that handshake messages are
delivered reliably and breaks if those messages are lost. delivered reliably and breaks if those messages are lost.
The rest of this section describes the approach that DTLS uses to The rest of this section describes the approach that DTLS uses to
solve these problems. solve these problems.
3.1. Loss-Insensitive Messaging 3.1. Loss-Insensitive Messaging
In TLS's traffic encryption layer (called the TLS Record Layer), In TLS's traffic encryption layer (called the TLS Record Layer),
skipping to change at page 9, line 16 skipping to change at page 9, line 21
discard such packets, though when DTLS is used over reliable discard such packets, though when DTLS is used over reliable
transports (e.g., SCTP), they SHOULD be buffered and processed once transports (e.g., SCTP), they SHOULD be buffered and processed once
the handshake completes. Note that TLS's restrictions on when the handshake completes. Note that TLS's restrictions on when
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 CSS or Finished has not yet been received provided that either the ChangeCipherSpec or Finished has not yet been received provided
the rehandshake resumes the existing session or that it uses exactly that either the rehandshake resumes the existing session or that it
the same security parameters as the existing association. In an uses exactly the same security parameters as the existing
other case, the implementation MUST wait for the receipt of the association. In an other case, the implementation MUST wait for the
Finished to prevent downgrade attack. receipt of the Finished to prevent downgrade attack.
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, that clients of the DTLS record layer SHOULD avoid fragmentation, clients of the DTLS record layer SHOULD attempt
attempt to size records so that they fit within any PMTU estimates to size records so that they fit within any PMTU estimates obtained
obtained from the record layer. 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 11, line 9 skipping to change at page 11, line 14
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 DTLS record
layer should inform the upper layer protocol of the error. layer should 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).
- If the underlying transport protocol allows the application - If the underlying transport protocol allows the application
to request PMTU probing (e.g., DCCP), the DTLS record to request PMTU probing (e.g., DCCP), the DTLS record
skipping to change at page 13, line 43 skipping to change at page 13, line 43
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
Unlike TLS, DTLS is resilient in the face of invalid records (e.g., records (e.g., invalid formatting, length, MAC, etc.) In
invalid formatting, length, MAC, etc.) In general, invalid records general, invalid records SHOULD be silently discarded, thus
SHOULD be silently discarded, thus preserving the association. preserving the association. Implementations which choose to
Implementations which choose to generate an alert instead, MUST generate an alert instead, MUST generate fatal level alerts to
generate fatal level alerts to avoid attacks where the attacker avoid attacks where the attacker repeatedly probes the
repeatedly probes the implementation to see how it responds to implementation to see how it responds to various types of error.
various types of error. Note that if DTLS is run over UDP, then any Note that if DTLS is run over UDP, then any implementation which
implementation which does this will be extremely susceptible to DoS does this will be extremely susceptible to DoS attacks because
attacks because UDP forgery is so easy. Thus, this practice is NOT UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED
RECOMMENDED for such transports. for such transports. If DTLS is being carried over a
transport which is resistant to forgery (e.g., SCTP with SCTP-
If DTLS is being carried over a transport which is resistant to AUTH), then it is safer to send alerts because an attacker will
forget (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts have difficulty forging a datagram which will not be rejected by the
because an attacker will have difficulty forging a datagram which transport layer.
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,
skipping to change at page 17, line 8 skipping to change at page 17, line 7
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). Note to
implementors: this may results in clients receiving multiple 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 HelloVerify in response to the new handle this by sending a new ClientHello with a cookie in response to
HelloVerifyRequest. the new HelloVerifyRequest.
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 fragmentation, DTLS
modifies the TLS 1.2 handshake header: 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
skipping to change at page 25, line 33 skipping to change at page 25, line 33
} DTLSCompressed; } DTLSCompressed;
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;
select (CipherSpec.cipher_type) { select (CipherSpec.cipher_type) {
case block: GenericBlockCipher; case block: GenericBlockCipher;
case aead: GenericAEADCipher; case aead: GenericAEADCipher; // New field
} fragment; } fragment;
} DTLSCiphertext; } DTLSCiphertext;
4.3.2. Handshake Protocol 4.3.2. Handshake Protocol
enum { enum {
hello_request(0), client_hello(1), server_hello(2), hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field hello_verify_request(3), // New field
certificate(11), server_key_exchange (12), certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14), certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16), certificate_verify(15), client_key_exchange(16),
skipping to change at page 27, line 15 skipping to change at page 27, line 15
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. Helpful comments on the document were also received
from Mark Allman, Jari Arkko, Mohamed Badra, Joel Halpern, Ted from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Joel
Hardie, Allison Mankin, Robin Seggelman and Michael Tuexen. Halpern, Ted Hardie, Allison Mankin, Robin Seggelman and Michael
Tuexen.
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.
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. References
8.1. Normative References 8.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.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[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
 End of changes. 15 change blocks. 
59 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/