draft-ietf-tls-rfc4347-bis-05.txt   draft-ietf-tls-rfc4347-bis-06.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
Expires: September 14, 2011 Stanford University Expires: January 4, 2012 Stanford University
March 14, 2011 July 4, 2011
Datagram Transport Layer Security version 1.2 Datagram Transport Layer Security version 1.2
draft-ietf-tls-rfc4347-bis-05.txt draft-ietf-tls-rfc4347-bis-06.txt
Abstract Abstract
This document specifies Version 1.2 of the Datagram Transport Layer This document specifies Version 1.2 of the Datagram Transport Layer
Security (DTLS) protocol. The DTLS protocol provides communications Security (DTLS) protocol. The DTLS protocol provides communications
privacy for datagram protocols. The protocol allows client/server privacy for datagram protocols. The protocol allows client/server
applications to communicate in a way that is designed to prevent applications to communicate in a way that is designed to prevent
eavesdropping, tampering, or message forgery. The DTLS protocol is eavesdropping, tampering, or message forgery. The DTLS protocol is
based on the Transport Layer Security (TLS) protocol and provides based on the Transport Layer Security (TLS) protocol and provides
equivalent security guarantees. Datagram semantics of the underlying equivalent security guarantees. Datagram semantics of the underlying
skipping to change at page 3, line 14 skipping to change at page 3, line 14
4.1.2.3. Block Cipher 12 4.1.2.3. Block Cipher 12
4.1.2.3. AEAD Ciphers 13 4.1.2.3. AEAD Ciphers 13
4.1.2.5. New Cipher Suites 13 4.1.2.5. New Cipher Suites 13
4.1.2.6. Anti-replay 13 4.1.2.6. Anti-replay 13
4.1.2.7. Handling Invalid Records 14 4.1.2.7. Handling Invalid Records 14
4.2. The DTLS Handshake Protocol 14 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 17 4.2.2. Handshake Message Format 17
4.2.3. Handshake Message Fragmentation and Reassembly 19 4.2.3. Handshake Message Fragmentation and Reassembly 19
4.2.4. Timeout and Retransmission 19 4.2.4. Timeout and Retransmission 19
4.2.4.1. Timer Values 23 4.2.4.1. Timer Values 24
4.2.5. ChangeCipherSpec 23 4.2.5. ChangeCipherSpec 24
4.2.6. CertificateVerify and Finished Messages 24 4.2.6. CertificateVerify and Finished Messages 25
4.2.7. Alert Messages 24 4.2.7. Alert Messages 25
4.2.8. Establishing New Associations With Existing Parameters 24 4.2.8. Establishing New Associations With Existing Parameters 25
4.3. Summary of new syntax 24 4.3. Summary of new syntax 26
4.3.1. Record Layer 26 4.3.1. Record Layer 27
4.3.2. Handshake Protocol 26 4.3.2. Handshake Protocol 27
5. Security Considerations 27 5. Security Considerations 28
6. Acknowledgements 29 6. Acknowledgements 30
7. IANA Considerations 29 7. IANA Considerations 30
8. Changes Since DTLS 1.0 29 8. Changes Since DTLS 1.0 30
9. References 30 9. References 31
9.1. Normative References 30 9.1. Normative References 31
9.2. Informative References 31 9.2. Informative References 32
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 9, line 5 skipping to change at page 9, line 5
order to ensure that any given sequence/epoch pair is unique, order to ensure that any given sequence/epoch pair is unique,
implementations MUST NOT allow the same epoch value to be reused implementations MUST NOT allow the same epoch value to be reused
within two times the TCP maximum segment lifetime. In practice, TLS within two times the TCP maximum segment lifetime. In practice, TLS
implementations rarely rehandshake and we therefore do not expect implementations rarely rehandshake and we therefore do not expect
this to be a problem. this to be a problem.
Note that because DTLS records may be reordered, a record from epoch Note that because DTLS records may be reordered, a record from epoch
1 may be received after epoch 2 has begun. In general, 1 may be received after epoch 2 has begun. In general,
implementations SHOULD discard packets from earlier epochs, but if implementations SHOULD discard packets from earlier epochs, but if
packet loss causes noticeable problems MAY choose to retain keying packet loss causes noticeable problems MAY choose to retain keying
material from previous epochs for up to 120 seconds (the default TCP material from previous epochs for up to the default MSL specified for
MSL) to allow for packet reordering. Until the handshake has TCP [TCP] to allow for packet reordering. (Note: the intention here
completed, implementations MUST accept packets from the old epoch. is that implementors use the current guidance from the IETF for MSL,
not that they attempt to interrogate the MSL the system TCP stack is
using.) Until the handshake has completed, implementations MUST
accept packets from the old epoch.
Conversely, it is possible for records that are protected by the Conversely, it is possible for records that are protected by the
newly negotiated context to be received prior to the completion of a newly negotiated context to be received prior to the completion of a
handshake. For instance, the server may send its Finished and then handshake. For instance, the server may send its Finished and then
start transmitting data. Implementations MAY either buffer or start transmitting data. Implementations MAY either buffer or
discard such packets, though when DTLS is used over reliable discard such packets, though when DTLS is used over reliable
transports (e.g., SCTP), they SHOULD be buffered and processed once transports (e.g., SCTP), they SHOULD be buffered and processed once
the handshake completes. Note that TLS's restrictions on when the handshake completes. Note that TLS's restrictions on when
packets may be sent still apply, and the receiver treats the packets 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 as if they were sent in the right order. In particular, it is still
skipping to change at page 16, line 15 skipping to change at page 16, line 15
The definition of HelloVerifyRequest is as follows: The definition of HelloVerifyRequest is as follows:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
opaque cookie<0..2^8-1>; opaque cookie<0..2^8-1>;
} HelloVerifyRequest; } HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3). The HelloVerifyRequest message type is hello_verify_request(3).
The server_version field is defined as in TLS. The server_version field has the same syntax as in TLS. However, in
order to avoid the requirement to do version negotiation in the
initial handshake, DTLS 1.2 serverimplementations SHOULD use DTLS
version 1.0 regardless of the version of TLS which is expected to be
negotiated. DTLS 1.2 and 1.0 clients MUST use the version solely to
indicate packet formatting (which is the same in both DTLS 1.2 and
1.0) and not as part of version negotiation. In particular, DTLS 1.2
clients MUST NOT assume that because the server uses version 1.0 in
the HelloVerifyRequest that the server is not DTLS 1.2 or that it
will eventually negotiate DTLS 1.0 rather than DTLS 1.2.
When responding to a HelloVerifyRequest the client MUST use the same When responding to a HelloVerifyRequest the client MUST use the same
parameter values (version, random, session_id, cipher_suites, parameter values (version, random, session_id, cipher_suites,
compression_method) as it did in the original ClientHello. The compression_method) as it did in the original ClientHello. The
server SHOULD use those values to generate its cookie and verify that server SHOULD use those values to generate its cookie and verify that
they are correct upon cookie receipt. The server MUST use the same they are correct upon cookie receipt. The server MUST use the same
version number in the HelloVerifyRequest that it would use when version number in the HelloVerifyRequest that it would use when
sending a ServerHello. Upon receipt of the ServerHello, the client sending a ServerHello. Upon receipt of the ServerHello, the client
MUST verify that the server version values match. MUST verify that the server version values match. In order to avoid
sequence number duplication in case of multiple HelloVerifyRequests,
the server MUST use the record sequence number in the ClientHello as
the record sequence number in the HelloVerifyRequest.
Note: this specification increases the cookie size limit to 255 bytes Note: this specification increases the cookie size limit to 255 bytes
for greater future flexibility. The limit remains 32 for previous for greater future flexibility. The limit remains 32 for previous
versions of DTLS. versions of DTLS.
The DTLS server SHOULD generate cookies in such a way that they can The DTLS server SHOULD generate cookies in such a way that they can
be verified without retaining any per-client state on the server. be verified without retaining any per-client state on the server.
One technique is to have a randomly generated secret and generate One technique is to have a randomly generated secret and generate
cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters) cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters)
When the second ClientHello is received, the server can verify that When the second ClientHello is received, the server can verify that
the Cookie is valid and that the client can receive packets at the the Cookie is valid and that the client can receive packets at the
given IP address. given IP address. In order to avoid sequence number duplication in
case of multiple cookie exchanges, the server MUST use the record
sequence number in the ClientHello as the record sequence number in
its initial ServerHello. Subsequent ServerHellos will only be sent
after the server has created state and MUST increment normally.
One potential attack on this scheme is for the attacker to collect a One potential attack on this scheme is for the attacker to collect a
number of cookies from different addresses and then reuse them to number of cookies from different addresses and then reuse them to
attack the server. The server can defend against this attack by attack the server. The server can defend against this attack by
changing the Secret value frequently, thus invalidating those changing the Secret value frequently, thus invalidating those
cookies. If the server wishes that legitimate clients be able to cookies. If the server wishes that legitimate clients be able to
handshake through the transition (e.g., they received a cookie with handshake through the transition (e.g., they received a cookie with
Secret 1 and then sent the second ClientHello after the server has Secret 1 and then sent the second ClientHello after the server has
changed to Secret 2), the server can have a limited window during changed to Secret 2), the server can have a limited window during
which it accepts both secrets. [IKEv2] suggests adding a version which it accepts both secrets. [IKEv2] suggests adding a version
skipping to change at page 17, line 25 skipping to change at page 17, line 41
verify_data (for the Finished message). verify_data (for the Finished message).
If a server receives a ClientHello with an invalid cookie, it SHOULD If a server receives a ClientHello with an invalid cookie, it SHOULD
treat it the same as a ClientHello with no cookie. This avoids treat it the same as a ClientHello with no cookie. This avoids
race/deadlock conditions if the client somehow gets a bad cookie race/deadlock conditions if the client somehow gets a bad cookie
(e.g., because the server changes its cookie signing key). (e.g., because the server changes its cookie signing key).
Note to implementors: this may results in clients receiving multiple Note to implementors: this may results in clients receiving multiple
HelloVerifyRequest messages with different cookies. Clients SHOULD HelloVerifyRequest messages with different cookies. Clients SHOULD
handle this by sending a new ClientHello with a cookie in response to handle this by sending a new ClientHello with a cookie in response to
the new HelloVerifyRequest. Note that this message should have the the new HelloVerifyRequest.
same handshake sequence number (0) and record sequence number (0),
thus avoiding the need to create state on the server. This also
implies that the client MUST NOT do replay suppression during the
initial handshake (this is safe as handshake messages have their own
sequence numbers). [OPEN ISSUE: It's not clear that this is the best
choice. Michael Tuexen suggested mimicing the client's record
sequence number instead.]
4.2.2. Handshake Message Format 4.2.2. Handshake Message Format
In order to support message loss, reordering, and message In order to support message loss, reordering, and message
fragmentation, DTLS modifies the TLS 1.2 handshake header: fragmentation, DTLS modifies the TLS 1.2 handshake header:
struct { struct {
HandshakeType msg_type; HandshakeType msg_type;
uint24 length; uint24 length;
uint16 message_seq; // New field uint16 message_seq; // New field
skipping to change at page 18, line 15 skipping to change at page 18, line 24
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone; case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange; case client_key_exchange: ClientKeyExchange;
case finished: Finished; case finished: Finished;
} body; } body;
} Handshake; } Handshake;
The first message each side transmits in each handshake always has The first message each side transmits in each handshake always has
message_seq = 0. Whenever each new message is generated, the message_seq = 0. Whenever each new message is generated, the
message_seq value is incremented by one. When a message is message_seq value is incremented by one. Note that in the case of a
rehandshake, this implies that the HelloRequest will have message_seq
= 0 and the ServerHello will have message_seq = 1. When a message is
retransmitted, the same message_seq value is used. For example: retransmitted, the same message_seq value is used. For example:
Client Server Client Server
------ ------ ------ ------
ClientHello (seq=0) ------> ClientHello (seq=0) ------>
X<-- HelloVerifyRequest (seq=0) X<-- HelloVerifyRequest (seq=0)
(lost) (lost)
[Timer Expires] [Timer Expires]
skipping to change at page 22, line 50 skipping to change at page 23, line 50
Because DTLS clients send the first message (ClientHello), they start Because DTLS clients send the first message (ClientHello), they start
in the PREPARING state. DTLS servers start in the WAITING state, but in the PREPARING state. DTLS servers start in the WAITING state, but
with empty buffers and no retransmit timer. with empty buffers and no retransmit timer.
When the server desires a rehandshake, it transitions from the When the server desires a rehandshake, it transitions from the
FINISHED state to the PREPARING state to transmit the HelloRequest. FINISHED state to the PREPARING state to transmit the HelloRequest.
When the client receives a HelloRequest it transitions from FINISHED 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 In addition, for at least twice the default MSL defined for [TCP],
which transmits the last flight (the server in an ordinary handshake when in the FINISHED state, the node which transmits the last flight
or the client in a resumed handshake) MUST respond to a retransmit of (the server in an ordinary handshake or the client in a resumed
the peer's last flight with a retransmit of the last flight. This handshake) MUST respond to a retransmit of the peer's last flight
avoids deadlock conditions if the last flight gets lost. This with a retransmit of the last flight. This avoids deadlock conditions
requirement applies to DTLS 1.0 as well, and though not explicit in if the last flight gets lost. This requirement applies to DTLS 1.0 as
[DTLS1] but was always required for the state machine to function well, and though not explicit in [DTLS1] but was always required for
correctly. To see why this is necessary, consider what happens in an the state machine to function correctly. To see why this is
ordinary handshake if the server's Finished is lost: the server necessary, consider what happens in an ordinary handshake if the
believes the handshake is complete but it actually is not. As the server's Finished is lost: the server believes the handshake is
client is waiting for the Finished, the client's retransmit timer complete but it actually is not. As the client is waiting for the
will fire and it will retransmit the client Finished, causing the Finished, the client's retransmit timer will fire and it will
server to respond with its own Finished, completing the handshake. retransmit the client Finished, causing the server to respond with
The same logic applies on the server side for the resumed handshake. its own Finished, completing the handshake. The same logic applies
on the server side for the resumed handshake.
Note that because of packet loss it is possible for one side to be Note that because of packet loss it is possible for one side to be
sending application data even though the other side has not received sending application data even though the other side has not received
the first side's Finished. Implementations MUST either discard or the first side's Finished. Implementations MUST either discard or
buffer all application data packets for the new epoch until they have buffer all application data packets for the new epoch until they have
received the Finished for that epoch. Implementations MAY treat received the Finished for that epoch. Implementations MAY treat
receipt of application data with a new epoch prior to receipt of the receipt of application data with a new epoch prior to receipt of the
corresponding Finished as evidence of reordering or packet loss and corresponding Finished as evidence of reordering or packet loss and
retransmit their final flight immediately, shortcutting the retransmit their final flight immediately, shortcutting the
retransmission timer. retransmission timer.
skipping to change at page 24, line 5 skipping to change at page 25, line 6
reset to the initial value. After a long period of idleness, no less reset to the initial value. After a long period of idleness, no less
than 10 times the current timer value, implementations may reset the than 10 times the current timer value, implementations may reset the
timer to the initial value. One situation where this might occur is timer to the initial value. One situation where this might occur is
when a rehandshake is used after substantial data transfer. when a rehandshake is used after substantial data transfer.
4.2.5. ChangeCipherSpec 4.2.5. ChangeCipherSpec
As with TLS, the ChangeCipherSpec message is not technically a As with TLS, the ChangeCipherSpec message is not technically a
handshake message but MUST be treated as part of the same flight as handshake message but MUST be treated as part of the same flight as
the associated Finished message for the purposes of timeout and the associated Finished message for the purposes of timeout and
retransmission. retransmission. This creates a potential ambiguity because the order
of the ChangeCipherSpec cannot be established unambiguously with
respect to the handshake messages in case of message loss.
This is not a problem with any current TLS mode because the expected
set of handshake messages which occur the ChangeCipherSpec is
predictable from the rest of the handshake state. However, future
modes MUST take care to avoid creating ambiguity.
4.2.6. CertificateVerify and Finished Messages 4.2.6. CertificateVerify and Finished Messages
CertificateVerify and Finished messages have the same format as in CertificateVerify and Finished messages have the same format as in
TLS. Hash calculations include entire handshake messages, including TLS. Hash calculations include entire handshake messages, including
DTLS specific fields: message_seq, fragment_offset and DTLS specific fields: message_seq, fragment_offset and
fragment_length. However, in order to remove sensitivity to fragment_length. However, in order to remove sensitivity to
handshake message fragmentation, the Finished MAC MUST be computed as handshake message fragmentation, the Finished MAC MUST be computed as
if each handshake message had been sent as a single fragment. Note if each handshake message had been sent as a single fragment. Note
that in cases where the cookie exchange is used, the initial that in cases where the cookie exchange is used, the initial
skipping to change at page 30, line 16 skipping to change at page 31, line 16
- Some new text describing how to avoid handshake deadlock conditions - Some new text describing how to avoid handshake deadlock conditions
at the end of Section 4.2.4. at the end of Section 4.2.4.
- Some new text about CertificateVerify messages in Section 4.2.6. - Some new text about CertificateVerify messages in Section 4.2.6.
- A prohibition on epoch wrapping in Section 4.1. - A prohibition on epoch wrapping in Section 4.1.
- Clarification of the IANA requirements and the explicit requirement - Clarification of the IANA requirements and the explicit requirement
for a new IANA registration flag for each parameter. for a new IANA registration flag for each parameter.
- Added a record sequence number mirroring technique for handling
repeated ClientHello messages.
- Recommend a fixed version number for HelloVerifyRequest.
- Numerous editorial changes. - Numerous editorial changes.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1885] Conta, A., and S. Deering, "Internet Control Message [RFC1885] Conta, A., and S. Deering, "Internet Control Message
 End of changes. 12 change blocks. 
48 lines changed or deleted 75 lines changed or added

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