draft-ietf-tls-rfc4347-bis-00.txt   draft-ietf-tls-rfc4347-bis-01.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-00.txt> Stanford University <draft-ietf-tls-rfc4347-bis-01.txt> Stanford University
June 2008 (Expires December 2008) November 2008 (Expires May 2009)
Datagram Transport Layer Security version 1.2 Datagram Transport Layer Security version 1.2
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3. Overview of DTLS 4 3. Overview of DTLS 4
3.1. Loss-Insensitive Messaging 4 3.1. Loss-Insensitive Messaging 4
3.2. Providing Reliability for Handshake 5 3.2. Providing Reliability for Handshake 5
3.2.1. Packet Loss 5 3.2.1. Packet Loss 5
3.2.2. Reordering 5 3.2.2. Reordering 5
3.2.3. Message Size 6 3.2.3. Message Size 6
3.3. Replay Detection 6 3.3. Replay Detection 6
4. Differences from TLS 6 4. Differences from TLS 6
4.1. Record Layer 6 4.1. Record Layer 6
4.1.1. Transport Layer Mapping 8 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. Record Payload Protection 10
4.1.2.1. MAC 10 4.1.2.1. MAC 10
4.1.2.2. Null or Standard Stream Cipher 11 4.1.2.2. Null or Standard Stream Cipher 11
4.1.2.3. Block Cipher 11 4.1.2.3. Block Cipher 11
4.1.2.3. AEAD Ciphers 11 4.1.2.3. AEAD Ciphers 11
4.1.2.5. New Cipher Suites 11 4.1.2.5. New Cipher Suites 11
4.1.2.6. Anti-replay 11 4.1.2.6. Anti-replay 11
4.2. The DTLS Handshake Protocol 12 4.2. The DTLS Handshake Protocol 12
4.2.1. Denial of Service Countermeasures 12 4.2.1. Denial of Service Countermeasures 12
4.2.2. Handshake Message Format 15 4.2.2. Handshake Message Format 15
4.2.3. Message Fragmentation and Reassembly 16 4.2.3. Message Fragmentation and Reassembly 16
4.2.4. Timeout and Retransmission 17 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.5. ChangeCipherSpec 21
4.2.6. CertificateVerify and Finished Messages 21 4.2.6. CertificateVerify and Finished Messages 21
4.2.7. Alert Messages 21 4.2.7. Alert Messages 21
4.3. Summary of new syntax 21 4.3. Summary of new syntax 22
4.3.1. Record Layer 22 4.3.1. Record Layer 23
4.3.2. Handshake Protocol 22 4.3.2. Handshake Protocol 23
5. Security Considerations 23 5. Security Considerations 24
6. Acknowledgements 24 6. Acknowledgements 25
7. IANA Considerations 24 7. IANA Considerations 25
8. References 24 8. References 25
8.1. Normative References 24 8.1. Normative References 25
8.2. Informative References 25 8.2. Informative References 26
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 6, line 35 skipping to change at page 6, line 35
records that have previously been received are silently discarded. records that have previously been received are silently discarded.
The replay detection feature is optional, since packet duplication is The replay detection feature is optional, since packet duplication is
not always malicious, but can also occur due to routing errors. not always malicious, but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy. modify their data transmission strategy.
4. Differences from TLS 4. Differences from TLS
As mentioned in Section 3, DTLS is intentionally very similar to TLS. As mentioned in Section 3, DTLS is intentionally very similar to TLS.
Therefore, instead of presenting DTLS as a new protocol, we present 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]. explicitly call out differences, DTLS is the same as in [TLS12].
4.1. Record Layer 4.1. Record Layer
The DTLS record layer is extremely similar to that of TLS 1.2. The 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 only change is the inclusion of an explicit sequence number in the
record. This sequence number allows the recipient to correctly record. This sequence number allows the recipient to correctly
verify the TLS MAC. The DTLS record format is shown below: verify the TLS MAC. The DTLS record format is shown below:
struct { struct {
skipping to change at page 8, line 8 skipping to change at page 8, line 8
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 120 seconds (the default TCP
MSL) to allow for packet reordering. 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 4.1.1. Transport Layer Mapping
Each DTLS record MUST fit within a single datagram. In order to Each DTLS record MUST fit within a single datagram. In order to
avoid fragmentation, that clients of the DTLS record layer SHOULD avoid fragmentation, that clients of the DTLS record layer SHOULD
attempt to size records so that they fit within any PMTU estimates attempt to size records so that they fit within any PMTU estimates
obtained from the record layer. obtained from the record layer.
Note that unlike IPsec, DTLS records do not contain any association Note that unlike IPsec, DTLS records do not contain any association
identifiers. Applications must arrange to multiplex between identifiers. Applications must arrange to multiplex between
associations. With UDP, this is presumably done with host/port associations. With UDP, this is presumably done with host/port
skipping to change at page 15, line 4 skipping to change at page 15, line 15
which it accepts both secrets. [IKEv2] suggests adding a version which it accepts both secrets. [IKEv2] suggests adding a version
number to cookies to detect this case. An alternative approach is number to cookies to detect this case. An alternative approach is
simply to try verifying with both secrets. simply to try verifying with both secrets.
DTLS servers SHOULD perform a cookie exchange whenever a new DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed. If the server is being operated in an handshake is being performed. If the server is being operated in an
environment where amplification is not a problem, the server MAY be environment where amplification is not a problem, the server MAY be
configured not to perform a cookie exchange. The default SHOULD be configured not to perform a cookie exchange. The default SHOULD be
that the exchange is performed, however. In addition, the server MAY that the exchange is performed, however. In addition, the server MAY
choose not to do a cookie exchange when a session is resumed. choose not to do a cookie exchange when a session is resumed.
Clients MUST be prepared to do a cookie exchange with every Clients MUST be prepared to do a cookie exchange with every
handshake. handshake.
If HelloVerifyRequest is used, the initial ClientHello and If HelloVerifyRequest is used, the initial ClientHello and
HelloVerifyRequest are not included in the calculation of the HelloVerifyRequest are not included in the calculation of the
handshake_messages (for the CertificateVerify message) and handshake_messages (for the CertificateVerify message) and
verify_data (for the Finished message). 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 4.2.2. Handshake Message Format
In order to support message loss, reordering, and fragmentation, DTLS In order to support message loss, reordering, and fragmentation, DTLS
modifies the TLS 1.2 handshake header: 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
uint24 fragment_offset; // New field uint24 fragment_offset; // New field
skipping to change at page 19, line 45 skipping to change at page 19, line 45
last | | | last | | |
flight | | | flight | | |
| | | | | |
\|/\|/ | \|/\|/ |
| |
+-----------+ | +-----------+ |
| | | | | |
| FINISHED | -------------------------------+ | FINISHED | -------------------------------+
| | | |
+-----------+ +-----------+
| /|\
| |
| |
+---+
Read retransmit
Retransmit last flight
Figure 3. DTLS timeout and retransmission state machine Figure 3. DTLS timeout and retransmission state machine
The state machine has three basic states. The state machine has three basic states.
In the PREPARING state the implementation does whatever computations In the PREPARING state the implementation does whatever computations
are necessary to prepare the next flight of messages. It then are necessary to prepare the next flight of messages. It then
buffers them up for transmission (emptying the buffer first) and buffers them up for transmission (emptying the buffer first) and
enters the SENDING state. enters the SENDING state.
In the SENDING state, the implementation transmits the buffered In the SENDING state, the implementation transmits the buffered
skipping to change at page 20, line 45 skipping to change at page 20, line 48
(whether partial messages or only some of the messages in the (whether partial messages or only some of the messages in the
flight) do not cause state transitions or timer resets. flight) do not cause state transitions or timer resets.
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 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 4.2.4.1. Timer Values
Though timer values are the choice of the implementation, mishandling Though timer values are the choice of the implementation, mishandling
of the timer can lead to serious congestion problems; for example, if 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 many instances of a DTLS time out early and retransmit too quickly on
a congested link. Implementations SHOULD use an initial timer value a congested link. Implementations SHOULD use an initial timer value
of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double 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 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 maximum of 60 seconds. Note that we recommend a 1-second timer
skipping to change at page 24, line 32 skipping to change at page 25, line 32
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.
8. References 8. References
8.1. Normative 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, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. 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 [RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
Suites for TLS", draft-ietf-tls-rsa-aes-gcm-03 (work in Suites for TLS", RFC 5288, August 2008.
progress), April 2008.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, May 2008. (TLS) Protocol Version 1.2", RFC 5246, May 2008.
8.2. Informative References 8.2. Informative References
[AH] S. Kent, "IP Authentication Header", RFC 4302, December
2005.
[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
Congestion Control Protocol", Work in Progress, 10 March Congestion Control Protocol", Work in Progress, 10 March
2005. 2005.
[DCCPDTLS] T. Phelan, "Datagram Transport Layer Security (DTLS) over [DCCPDTLS] T. Phelan, "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)", draft- the Datagram Congestion Control Protocol (DCCP)", RFC
ietf-dccp-dtls-06 (work in progress), April 2008. 5238, May 2008.
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation
of Datagram TLS", Proceedings of ISOC NDSS 2004, February of Datagram TLS", Proceedings of ISOC NDSS 2004, February
2004. 2004.
[DTLS1] Rescorla, E., and N. Modadugu, "Datagram Transport Layer [DTLS1] Rescorla, E., and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. 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 [ESP] S. Kent "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol", [IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005. December 2005.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Messages", RFC 2521, March 1999. Protocol", RFC 2522, March 1999.
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate [REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
 End of changes. 18 change blocks. 
29 lines changed or deleted 57 lines changed or added

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