struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
select (CipherSpec.cipher_type) {
case block: GenericBlockCipher;
} fragment;
} DTLSCiphertext;
4.3.2. Handshake Protocol
enum {
hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // New field
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished:Finished;
} body;
} Handshake;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
5. Security Considerations
This document describes a variant of TLS 1.1 and therefore most of
the security considerations are the same as those of TLS 1.1 [TLS11],
described in Appendices D, E, and F.
The primary additional security consideration raised by DTLS is that
of denial of service. DTLS includes a cookie exchange designed to
protect against denial of service. However, implementations which do
not use this cookie exchange are still vulnerable to DoS. In
particular, DTLS servers which do not use the cookie exchange may be
used as attack amplifiers even if they themselves are not
experiencing DoS. Therefore, DTLS servers SHOULD use the cookie
exchange unless there is good reason to believe that amplification is
not a threat in their environment. Clients MUST be prepared to do a
cookie exchange with every handshake.
6. Acknowledgements
The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley,
Constantine Sapuntzakis, and Hovav Shacham for discussions and
comments on the design of DTLS. Thanks to the anonymous NDSS
reviewers of our original NDSS paper on DTLS [DTLS] for their
comments. Also, thanks to Steve Kent for feedback that helped
clarify many points. The section on PMTU was cribbed from the DCCP
specification [DCCP]. Pasi Eronen provided a detailed review of this
specification. Helpful comments on the document were also received
from Mark Allman, Jari Arkko, Joel Halpern, Ted Hardie, and Allison
Mankin.
7. IANA Considerations
This document uses the same identifier space as TLS [TLS11], so no
new IANA registries are required. When new identifiers are assigned
for TLS, authors MUST specify whether they are suitable for DTLS.
This document defines a new handshake message, hello_verify_request,
whose value has been allocated from the TLS HandshakeType registry
defined in [TLS11]. The value "3" has been assigned by the IANA.
8. References
8.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP’s Retransmission
Timer", RFC 2988, November 2000.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
8.2. Informative References
[AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES"
http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
Congestion Control Protocol", Work in Progress, 10 March
2005.
[DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation
of Datagram TLS", Proceedings of ISOC NDSS 2004, February
2004.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures
Messages", RFC 2521, March 1999.
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
Work in Progress, October 2003.
Authors’ Addresses
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
EMail: ekr@rtfm.com
Nagendra Modadugu
Computer Science Department
Stanford University
353 Serra Mall
Stanford, CA 94305
EMail: nagendra@cs.stanford.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).