--- 1/draft-ietf-tls-rfc4347-bis-02.txt 2009-10-07 20:12:10.000000000 +0200 +++ 2/draft-ietf-tls-rfc4347-bis-03.txt 2009-10-07 20:12:10.000000000 +0200 @@ -1,16 +1,16 @@ INTERNET-DRAFT E. Rescorla Obsoletes (if approved): RFC 4347 RTFM, Inc. Intended Status: Proposed Standard N. Modadugu - Stanford University - March 7, 2009 (Expires September 2009) + Stanford University + October 7, 2009 (Expires April 2010) 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 @@ -88,38 +88,39 @@ 4.1. Record Layer 7 4.1.1. Transport Layer Mapping 9 4.1.1.1. PMTU Issues 10 4.1.2. Record Payload Protection 11 4.1.2.1. MAC 11 4.1.2.2. Null or Standard Stream Cipher 12 4.1.2.3. Block Cipher 12 4.1.2.3. AEAD Ciphers 12 4.1.2.5. New Cipher Suites 12 4.1.2.6. Anti-replay 13 - 4.2. The DTLS Handshake Protocol 13 + 4.1.2.7. Handling Invalid Records 13 + 4.2. The DTLS Handshake Protocol 14 4.2.1. Denial of Service Countermeasures 14 - 4.2.2. Handshake Message Format 16 + 4.2.2. Handshake Message Format 17 4.2.3. Message Fragmentation and Reassembly 18 - 4.2.4. Timeout and Retransmission 18 - 4.2.4.1. Timer Values 22 - 4.2.5. ChangeCipherSpec 22 - 4.2.6. CertificateVerify and Finished Messages 22 - 4.2.7. Alert Messages 22 - 4.3. Summary of new syntax 23 - 4.3.1. Record Layer 24 - 4.3.2. Handshake Protocol 24 - 5. Security Considerations 25 - 6. Acknowledgements 26 - 7. IANA Considerations 26 - 8. References 26 - 8.1. Normative References 26 - 8.2. Informative References 27 + 4.2.4. Timeout and Retransmission 19 + 4.2.4.1. Timer Values 23 + 4.2.5. ChangeCipherSpec 23 + 4.2.6. CertificateVerify and Finished Messages 23 + 4.2.7. Alert Messages 23 + 4.3. Summary of new syntax 24 + 4.3.1. Record Layer 25 + 4.3.2. Handshake Protocol 25 + 5. Security Considerations 26 + 6. Acknowledgements 27 + 7. IANA Considerations 27 + 8. References 27 + 8.1. Normative References 27 + 8.2. Informative References 28 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]. @@ -519,25 +520,25 @@ which, in the case of DTLS, is the on-the-wire version, i.e., {254, 253} for DTLS 1.2. Note that one important difference between DTLS and TLS MAC handling is that in TLS MAC errors must result in connection termination. In DTLS, the receiving implementation MAY simply discard the offending record and continue with the connection. This change is possible because DTLS records are not dependent on each other in the way that TLS records are. - In general, DTLS implementations SHOULD silently discard data with - bad MACs. If a DTLS implementation chooses to generate an alert when - it receives a message with an invalid MAC, it MUST generate a - bad_record_mac alert with level fatal and terminate its connection - state. + In general, DTLS implementations SHOULD silently discard records with + bad MACs or that are otherwise invalid. If a DTLS implementation + chooses to generate an alert when it receives a message with an + invalid MAC, it MUST generate a bad_record_mac alert with level fatal + and terminate its connection state. 4.1.2.2. Null or Standard Stream 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 randomly accessed. RC4 MUST NOT be used with DTLS. 4.1.2.3. Block Cipher @@ -586,20 +587,38 @@ list of received packets within the window. An efficient means for 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. + 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, reordering, and fragmentation. @@ -1063,21 +1080,23 @@ } 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; } 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), @@ -1139,22 +1158,22 @@ 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. + from Mark Allman, Jari Arkko, Mohamed Badra, 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.