--- 1/draft-ietf-tls-rfc4347-bis-00.txt 2008-11-02 02:14:05.000000000 +0100 +++ 2/draft-ietf-tls-rfc4347-bis-01.txt 2008-11-02 02:14:05.000000000 +0100 @@ -1,16 +1,16 @@ INTERNET-DRAFT E. Rescorla Obsoletes (if approved): RFC 4347 RTFM, Inc. Intended Status: Proposed Standard N. Modadugu - Stanford University - June 2008 (Expires December 2008) + Stanford University + November 2008 (Expires May 2009) Datagram Transport Layer Security version 1.2 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -54,46 +54,46 @@ 3. Overview of DTLS 4 3.1. Loss-Insensitive Messaging 4 3.2. Providing Reliability for Handshake 5 3.2.1. Packet Loss 5 3.2.2. Reordering 5 3.2.3. Message Size 6 3.3. Replay Detection 6 4. Differences from TLS 6 4.1. Record Layer 6 4.1.1. Transport Layer Mapping 8 - 4.1.1.1. PMTU Issues 8 + 4.1.1.1. PMTU Issues 9 4.1.2. Record Payload Protection 10 4.1.2.1. MAC 10 4.1.2.2. Null or Standard Stream Cipher 11 4.1.2.3. Block Cipher 11 4.1.2.3. AEAD Ciphers 11 4.1.2.5. New Cipher Suites 11 4.1.2.6. Anti-replay 11 4.2. The DTLS Handshake Protocol 12 4.2.1. Denial of Service Countermeasures 12 4.2.2. Handshake Message Format 15 4.2.3. Message Fragmentation and Reassembly 16 4.2.4. Timeout and Retransmission 17 - 4.2.4.1. Timer Values 20 + 4.2.4.1. Timer Values 21 4.2.5. ChangeCipherSpec 21 4.2.6. CertificateVerify and Finished Messages 21 4.2.7. Alert Messages 21 - 4.3. Summary of new syntax 21 - 4.3.1. Record Layer 22 - 4.3.2. Handshake Protocol 22 - 5. Security Considerations 23 - 6. Acknowledgements 24 - 7. IANA Considerations 24 - 8. References 24 - 8.1. Normative References 24 - 8.2. Informative References 25 + 4.3. Summary of new syntax 22 + 4.3.1. Record Layer 23 + 4.3.2. Handshake Protocol 23 + 5. Security Considerations 24 + 6. Acknowledgements 25 + 7. IANA Considerations 25 + 8. References 25 + 8.1. Normative References 25 + 8.2. Informative References 26 1. Introduction TLS [TLS] is the most widely deployed protocol for securing network traffic. It is widely used for protecting Web traffic and for e-mail protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of TLS is that it provides a transparent connection-oriented channel. Thus, it is easy to secure an application protocol by inserting TLS between the application layer and the transport layer. However, TLS must run over a reliable transport channel -- typically TCP [TCP]. @@ -259,21 +259,21 @@ records that have previously been received are silently discarded. The replay detection feature is optional, since packet duplication is not always malicious, but can also occur due to routing errors. Applications may conceivably detect duplicate packets and accordingly modify their data transmission strategy. 4. Differences from TLS As mentioned in Section 3, DTLS is intentionally very similar to TLS. Therefore, instead of presenting DTLS as a new protocol, we present - it as a series of deltas from TLS 1.1 [TLS12]. Where we do not + it as a series of deltas from TLS 1.2 [TLS12]. Where we do not explicitly call out differences, DTLS is the same as in [TLS12]. 4.1. Record Layer The DTLS record layer is extremely similar to that of TLS 1.2. The only change is the inclusion of an explicit sequence number in the record. This sequence number allows the recipient to correctly verify the TLS MAC. The DTLS record format is shown below: struct { @@ -328,20 +328,32 @@ implementations rarely rehandshake and we therefore do not expect this to be a problem. Note that because DTLS records may be reordered, a record from epoch 1 may be received after epoch 2 has begun. In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems MAY choose to retain keying material from previous epochs for up to 120 seconds (the default TCP MSL) to allow for packet reordering. + Conversely, it is possible for records that are protected by the + newly negotiated context to be received prior to the completion of a + handshake. For instance, the server may send its Finished and then + start transmitting data. Implementations MAY either buffer or + 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. + 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. 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 @@ -659,29 +669,33 @@ which it accepts both secrets. [IKEv2] suggests adding a version number to cookies to detect this case. An alternative approach is simply to try verifying with both secrets. DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed. If the server is being operated in an environment where amplification is not a problem, the server MAY be configured not to perform a cookie exchange. The default SHOULD be that the exchange is performed, however. In addition, the server MAY choose not to do a cookie exchange when a session is resumed. - Clients MUST be prepared to do a cookie exchange with every handshake. If HelloVerifyRequest is used, the initial ClientHello and 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). + 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 uint24 fragment_offset; // New field @@ -859,21 +874,27 @@ last | | | flight | | | | | | \|/\|/ | | +-----------+ | | | | | FINISHED | -------------------------------+ | | +-----------+ + | /|\ + | | + | | + +---+ + Read retransmit + Retransmit last flight Figure 3. DTLS timeout and retransmission state machine The state machine has three basic states. In the PREPARING state the implementation does whatever computations are necessary to prepare the next flight of messages. It then buffers them up for transmission (emptying the buffer first) and enters the SENDING state. In the SENDING state, the implementation transmits the buffered @@ -904,21 +925,28 @@ (whether partial messages or only some of the messages in the flight) do not cause state transitions or timer resets. Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer. When the server desires a rehandshake, it transitions from the FINISHED state to the PREPARING state to transmit the HelloRequest. When the client receives a HelloRequest it transitions from FINISHED - to PREPARING to transmit the ClientHello. + to PREPARING to transmit the ClientHello. In addition, for at least + 2MSL, when in the FINISHED state, the node which transmits the last + flight (the server in an ordinary handshake or the client in a + resumed handshake) MUST respond to a retransmit of the peer's last + flight with a retransmit of the last flight. This avoids deadlock + conditions if the last flight gets lost. This 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. 4.2.4.1. Timer Values Though timer values are the choice of the implementation, mishandling 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 a congested link. Implementations SHOULD use an initial timer value 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 maximum of 60 seconds. Note that we recommend a 1-second timer @@ -1082,80 +1109,79 @@ 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 - [ECCGCM] E. Rescorla, "TLS Elliptic Curve Cipher Suites with - SHA-256/384 and AES Galois Counter Mode", draft-ietf-tls- - ecc-new-mac-06 (work in progress), April 2008. - [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 - Suites for TLS", draft-ietf-tls-rsa-aes-gcm-03 (work in - progress), April 2008. + Suites for TLS", RFC 5288, August 2008. [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, May 2008. 8.2. Informative References - [AH] S. Kent, "IP Authentication Header", RFC 4302, December - 2005. - [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram Congestion Control Protocol", Work in Progress, 10 March 2005. [DCCPDTLS] T. Phelan, "Datagram Transport Layer Security (DTLS) over - the Datagram Congestion Control Protocol (DCCP)", draft- - ietf-dccp-dtls-06 (work in progress), April 2008. + the Datagram Congestion Control Protocol (DCCP)", RFC + 5238, May 2008. [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. [DTLS1] Rescorla, E., and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. + [ECCGCM] E. Rescorla, "TLS Elliptic Curve Cipher Suites with + SHA-256/384 and AES Galois Counter Mode", RFC 5289, August + 2008. + [ESP] S. Kent "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 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. + [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management + Protocol", RFC 2522, 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. [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261,