--- 1/draft-ietf-tls-rfc4347-bis-03.txt 2011-02-09 13:31:44.000000000 +0100 +++ 2/draft-ietf-tls-rfc4347-bis-04.txt 2011-02-09 13:31:44.000000000 +0100 @@ -1,44 +1,56 @@ INTERNET-DRAFT E. Rescorla Obsoletes (if approved): RFC 4347 RTFM, Inc. Intended Status: Proposed Standard N. Modadugu - Stanford University - October 7, 2009 (Expires April 2010) + Stanford University + July 12, 2010 (Expires January 2011) Datagram Transport Layer Security version 1.2 Status of This Memo - This Internet-Draft is submitted to IETF in full conformance with the - 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. + This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. - 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. + Copyright (c) 2010 IETF Trust and the persons identified as + the document authors. All rights reserved. + + 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at 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 (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. @@ -131,23 +143,23 @@ as the Session Initiation Protocol (SIP) [SIP] and electronic gaming protocols are increasingly popular. (Note that SIP can run over both TCP and UDP, but that there are situations in which UDP is preferable). Currently, designers of these applications are faced with a number of unsatisfactory choices. First, they can use IPsec [RFC4301]. However, for a number of reasons detailed in [WHYIPSEC], this is only suitable for some applications. Second, they can design a custom application layer security protocol. Unfortunately, although application layer security protocols generally provide superior security properties (e.g., end-to-end security in the case - of S/MIME), they typically requires a large amount of effort to - design -- in contrast to the relatively small amount of effort - required to run the protocol over TLS. + of S/MIME), they typically require a large amount of effort to design + -- in contrast to the relatively small amount of effort required to + run the protocol over TLS. In many cases, the most desirable way to secure client/server applications would be to use TLS; however, the requirement for datagram semantics automatically prohibits use of TLS. This memo describes a protocol for this purpose: Datagram Transport Layer Security (DTLS). DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse. DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This @@ -186,23 +198,26 @@ reordered. TLS has no internal facilities to handle this kind of unreliability, and therefore TLS implementations break when rehosted on datagram transport. The purpose of DTLS is to make only the minimal changes to TLS required to fix this problem. To the greatest extent possible, DTLS is identical to TLS. Whenever we need to invent new mechanisms, we attempt to do so in such a way that preserves the style of TLS. Unreliability creates problems for TLS at two levels: - 1. TLS's traffic encryption layer does not allow independent - decryption of individual records. If record N is not received, - then record N+1 cannot be decrypted. + 1. TLS does not allow independent decryption of individual + records. Because the integrity check depends on the sequence + 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 delivered reliably and breaks if those messages are lost. The rest of this section describes the approach that DTLS uses to solve these problems. 3.1. Loss-Insensitive Messaging In TLS's traffic encryption layer (called the TLS Record Layer), @@ -375,32 +388,32 @@ discard such packets, though when DTLS is used over reliable transports (e.g., SCTP), they SHOULD be buffered and processed once the handshake completes. Note that TLS's restrictions on when 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 impermissible to send data prior to completion of the first handshake. Note that in the special case of a rehandshake on an existing 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 rehandshake resumes the existing session or that it uses exactly - the same security parameters as the existing association. In an - other case, the implementation MUST wait for the receipt of the - Finished to prevent downgrade attack. + the ChangeCipherSpec or Finished has not yet been received provided + that either the rehandshake resumes the existing session or that it + uses exactly the same security parameters as the existing + association. In an other case, the implementation MUST wait for the + receipt of the Finished to prevent downgrade attack. 4.1.1. Transport Layer Mapping Each DTLS record MUST fit within a single datagram. In order to - avoid fragmentation, that clients of the DTLS record layer SHOULD - attempt to size records so that they fit within any PMTU estimates - obtained from the record layer. + avoid fragmentation, clients of the DTLS record layer SHOULD attempt + to size records so that they fit within any PMTU estimates obtained + from the record layer. Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations. With UDP, this is presumably done with host/port number. Multiple DTLS records may be placed in a single datagram. They are simply encoded consecutively. The DTLS record framing is sufficient to determine the boundaries. Note, however, that the first byte of the datagram payload must be the beginning of a record. Records may @@ -462,21 +475,21 @@ The DTLS record layer SHOULD allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing. Note that this number is only an estimate because of block padding and the potential use of DTLS compression. 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 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] mechanisms. In particular: - Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the DF bit (in IPv4) or prohibit local fragmentation (in IPv6). - If the underlying transport protocol allows the application to request PMTU probing (e.g., DCCP), the DTLS record @@ -588,36 +600,35 @@ performing this check, based on the use of a bit mask, is described in Section 3.4.3 of [ESP]. 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 MAC verification. If the MAC validation fails, the receiver MUST discard the received record as invalid. The receive window is updated only if the MAC verification succeeds. 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 general, invalid records - SHOULD be silently discarded, thus preserving the association. - Implementations which choose to generate an alert instead, MUST - generate fatal level alerts to avoid attacks where the attacker - repeatedly probes the implementation to see how it responds to - various types of error. Note that if DTLS is run over UDP, then any - implementation which does this will be extremely susceptible to DoS - attacks because UDP forgery is so easy. Thus, this practice is NOT - RECOMMENDED for such transports. - - If DTLS is being carried over a transport which is resistant to - forget (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. + Unlike TLS, DTLS is resilient in the face of invalid + records (e.g., invalid formatting, length, MAC, etc.) In + general, invalid records SHOULD be silently discarded, thus + preserving the association. Implementations which choose to + generate an alert instead, MUST generate fatal level alerts to + avoid attacks where the attacker repeatedly probes the + implementation to see how it responds to various types of error. + Note that if DTLS is run over UDP, then any implementation which + does this will be extremely susceptible to DoS attacks because + UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED + for such transports. If DTLS is being carried over a + transport which is resistant to 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 DTLS uses all of the same handshake messages and flows as TLS, with three principal changes: 1. A stateless cookie exchange has been added to prevent denial of service attacks. 2. Modifications to the handshake header to handle message loss, @@ -744,22 +755,22 @@ HelloVerifyRequest are not included in the calculation of the handshake_messages (for the CertificateVerify message) and verify_data (for the Finished message). If a server receives a ClientHello with an invalid cookie, it SHOULD treat it the same as a ClientHello with no cookie. This avoids race/deadlock conditions if the client somehow gets a bad cookie (e.g., because the server changes its cookie signing key). Note to implementors: this may results in clients receiving multiple HelloVerifyRequest messages with different cookies. Clients SHOULD - handle this by sending a new HelloVerify in response to the new - HelloVerifyRequest. + handle this by sending a new ClientHello with a cookie in response to + the new HelloVerifyRequest. 4.2.2. Handshake Message Format In order to support message loss, reordering, and fragmentation, DTLS modifies the TLS 1.2 handshake header: struct { HandshakeType msg_type; uint24 length; uint16 message_seq; // New field @@ -1080,23 +1092,22 @@ } DTLSCompressed; struct { ContentType type; ProtocolVersion version; uint16 epoch; // New field uint48 sequence_number; // New field uint16 length; select (CipherSpec.cipher_type) { case block: GenericBlockCipher; - case aead: GenericAEADCipher; + case aead: GenericAEADCipher; // New field } 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), @@ -1158,43 +1169,41 @@ 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, Mohamed Badra, Joel Halpern, Ted - Hardie, Allison Mankin, Robin Seggelman and Michael Tuexen. + from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Joel + Halpern, Ted Hardie, Allison Mankin, Robin Seggelman and Michael + Tuexen. 7. IANA Considerations This document uses the same identifier space as TLS [TLS12], 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 [TLS12]. 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. - [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC4821] Mathis, M., and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher