draft-ietf-tls-rfc4347-bis-02.txt   draft-ietf-tls-rfc4347-bis-03.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-02.txt> Stanford University <draft-ietf-tls-rfc4347-bis-03.txt> Stanford University
March 7, 2009 (Expires September 2009) October 7, 2009 (Expires April 2010)
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
skipping to change at page 3, line 7 skipping to change at page 3, line 7
4.1. Record Layer 7 4.1. Record Layer 7
4.1.1. Transport Layer Mapping 9 4.1.1. Transport Layer Mapping 9
4.1.1.1. PMTU Issues 10 4.1.1.1. PMTU Issues 10
4.1.2. Record Payload Protection 11 4.1.2. Record Payload Protection 11
4.1.2.1. MAC 11 4.1.2.1. MAC 11
4.1.2.2. Null or Standard Stream Cipher 12 4.1.2.2. Null or Standard Stream Cipher 12
4.1.2.3. Block Cipher 12 4.1.2.3. Block Cipher 12
4.1.2.3. AEAD Ciphers 12 4.1.2.3. AEAD Ciphers 12
4.1.2.5. New Cipher Suites 12 4.1.2.5. New Cipher Suites 12
4.1.2.6. Anti-replay 13 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.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.3. Message Fragmentation and Reassembly 18
4.2.4. Timeout and Retransmission 18 4.2.4. Timeout and Retransmission 19
4.2.4.1. Timer Values 22 4.2.4.1. Timer Values 23
4.2.5. ChangeCipherSpec 22 4.2.5. ChangeCipherSpec 23
4.2.6. CertificateVerify and Finished Messages 22 4.2.6. CertificateVerify and Finished Messages 23
4.2.7. Alert Messages 22 4.2.7. Alert Messages 23
4.3. Summary of new syntax 23 4.3. Summary of new syntax 24
4.3.1. Record Layer 24 4.3.1. Record Layer 25
4.3.2. Handshake Protocol 24 4.3.2. Handshake Protocol 25
5. Security Considerations 25 5. Security Considerations 26
6. Acknowledgements 26 6. Acknowledgements 27
7. IANA Considerations 26 7. IANA Considerations 27
8. References 26 8. References 27
8.1. Normative References 26 8.1. Normative References 27
8.2. Informative References 27 8.2. Informative References 28
1. Introduction 1. Introduction
TLS [TLS] is the most widely deployed protocol for securing network TLS [TLS] is the most widely deployed protocol for securing network
traffic. It is widely used for protecting Web traffic and for e-mail traffic. It is widely used for protecting Web traffic and for e-mail
protocols such as IMAP [IMAP] and POP [POP]. The primary advantage protocols such as IMAP [IMAP] and POP [POP]. The primary advantage
of TLS is that it provides a transparent connection-oriented channel. of TLS is that it provides a transparent connection-oriented channel.
Thus, it is easy to secure an application protocol by inserting TLS Thus, it is easy to secure an application protocol by inserting TLS
between the application layer and the transport layer. However, TLS between the application layer and the transport layer. However, TLS
must run over a reliable transport channel -- typically TCP [TCP]. must run over a reliable transport channel -- typically TCP [TCP].
skipping to change at page 12, line 18 skipping to change at page 12, line 18
which, in the case of DTLS, is the on-the-wire version, i.e., {254, which, in the case of DTLS, is the on-the-wire version, i.e., {254,
253} for DTLS 1.2. 253} for DTLS 1.2.
Note that one important difference between DTLS and TLS MAC handling Note that one important difference between DTLS and TLS MAC handling
is that in TLS MAC errors must result in connection termination. In is that in TLS MAC errors must result in connection termination. In
DTLS, the receiving implementation MAY simply discard the offending DTLS, the receiving implementation MAY simply discard the offending
record and continue with the connection. This change is possible record and continue with the connection. This change is possible
because DTLS records are not dependent on each other in the way that because DTLS records are not dependent on each other in the way that
TLS records are. TLS records are.
In general, DTLS implementations SHOULD silently discard data with In general, DTLS implementations SHOULD silently discard records with
bad MACs. If a DTLS implementation chooses to generate an alert when bad MACs or that are otherwise invalid. If a DTLS implementation
it receives a message with an invalid MAC, it MUST generate a chooses to generate an alert when it receives a message with an
bad_record_mac alert with level fatal and terminate its connection invalid MAC, it MUST generate a bad_record_mac alert with level fatal
state. and terminate its connection state.
4.1.2.2. Null or Standard Stream Cipher 4.1.2.2. Null or Standard Stream Cipher
The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL 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 The only stream cipher described in TLS 1.2 is RC4, which cannot be
randomly accessed. RC4 MUST NOT be used with DTLS. randomly accessed. RC4 MUST NOT be used with DTLS.
4.1.2.3. Block Cipher 4.1.2.3. Block Cipher
skipping to change at page 13, line 42 skipping to change at page 13, line 42
list of received packets within the window. An efficient means for list of received packets within the window. An efficient means for
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
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 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,
reordering, and fragmentation. reordering, and fragmentation.
skipping to change at page 24, 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;
} 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 26, 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, Joel Halpern, Ted Hardie, and Allison from Mark Allman, Jari Arkko, Mohamed Badra, Joel Halpern, Ted
Mankin. 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.
 End of changes. 9 change blocks. 
25 lines changed or deleted 46 lines changed or added

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