Network Working Group N. Modadugu
Internet-Draft Stanford University
Expires: August 29, 2006 E. Rescorla
Network Resonance
February 25, 2006
Extensions for Datagram Transport Layer Security (TLS) in Low Bandwidth
Environments
draft-modadugu-dtls-short-00.txt
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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a series of extensions to Datagram Transport
Layer Security (DTLS) which reduce the per-record bandwidth of the
data channel. These extensions apply only to the on-the-wire
representation of the protocol and do not affect cryptographic
processing.
Modadugu & Rescorla Expires August 29, 2006 [Page 1]
Internet-Draft DTLS Low Bandwidth February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used In This Document . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Sequence Number Length . . . . . . . . . . . . . . . . . . . . 4
4. Version Field Elimination . . . . . . . . . . . . . . . . . . 5
5. Length Field Elimination . . . . . . . . . . . . . . . . . . . 6
6. Implicit Application Data Header . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Modadugu & Rescorla Expires August 29, 2006 [Page 2]
Internet-Draft DTLS Low Bandwidth February 2006
1. Introduction
Datagram Transport Layer Security (DTLS) [5] is a protocol which
provides channel-oriented communications security for datagram
traffic. A communication channel that uses DTLS as security protocol
incurs some bandwidth overhead that results from additional per-
record headers and encryption overhead. Reducing this bandwidth
overhead is desireable when DTLS is used in wireless environments or
to secure real-time traffic. This document describes a series of
extensions to DTLS which reduce the per-record bandwidth. These
extensions apply only to the on-the-wire representation of the
protocol and do not affect the data subject to cryptographic
processing.
1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].
2. Background
The DTLS record format (based on the TLS [3] record format) is shown
below:
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
The major sources of per-record overhead in DTLS are:
+---------------------------------------------------+---------------+
| Field | size(bytes) |
+---------------------------------------------------+---------------+
| type | 1 |
| version | 2 |
| epoch | 2 |
| sequence_number | 6 |
| length | 2 |
| MAC | 10-20 bytes |
| encryption overhead | 9-32 |
+---------------------------------------------------+---------------+
Modadugu & Rescorla Expires August 29, 2006 [Page 3]
Internet-Draft DTLS Low Bandwidth February 2006
The largest performance improvement can be obtained by moving to a
cipher suite with less overhead. DTLS-CTR [7] describes such a mode.
This document describes how to reduce packet size further by reducing
the size of some of the fields in the record.
All the optimizations described in this memo are implemented using
the TLS Extensions mechanism [4].
3. Sequence Number Length
TLS, on which DTLS is based, uses a 64-bit sequence number. However,
because TLS must run on a reliable protocol, the sequence number is
implicit and does not take up space on the wire. In DTLS, the
sequence number is explicit and broken up into a 16-bit "epoch"
describing the number of handshakes that have happened on this
association and a 48-bit per-epoch sequence number. This has the
advantage of simplicity, but the disadvantage of taking up a fair
amount of space in the packet.
The sequence_number_length extension shortens the on-the-wire
representation of the sequence number without shortening the actual
sequence number. This means that the high order bits are not present
in the packet but rather MUST be deduced. Implementations SHOULD use
the technique of Appendix A of [6] to compute the high order bits of
the sequence number and epoch number.
When the client sends the sequence_number_length extension
"extension_data" field must contain a SequenceNumberLengthValues
field:
uint8 SequenceNumberLengthValue;
SequenceNumberLengthValue SequenceNumberLengthValues<1..7>;
This field contains the sequence number lengths which the client is
willing to accept. These lengths are the combined length in bytes of
the sequence number and epoch. Permissible values are 2,3,4,5,6,7,8,
with the sequence number and epoch divided up according to the
following table:
Modadugu & Rescorla Expires August 29, 2006 [Page 4]
Internet-Draft DTLS Low Bandwidth February 2006
+----------------------+---------------------+----------------------+
| Total | Epoch | Sequence |
+----------------------+---------------------+----------------------+
| 2 | 2 bits | 14 bits |
| 3 | 4 bits | 20 bits |
| 4 | 6 bits | 26 bits |
| 5 | 1 byte | 4 bytes |
| 6 | 1 byte | 5 bytes |
| 7 | 1 byte | 6 bytes |
| 8 | 2 bytes | 6 bytes |
+----------------------+---------------------+----------------------+
When the sequence number crosses a byte boundary, the high order bits
of that byte SHALL be considered to be the epoch and the low order
bits SHALL be considered to be the high order bits of the sequence
number. Note that the 8-byte value is equivalent to the default DTLS
behavior and is provided purely for completeness.
If the server receives a SequenceNumberLengthValue that is not one of
the allowed values, it MUST abort the handshake with an
"illegal_parameter" alert. If the server receives a
sequence_number_length extension and does not wish to negotiate
sequence_number_length it should ignore the sequence_number_length
extension.
If the server wishes to negotiate sequence_number_length it responds
with its own sequence_number_length extension. The server's
"extension_data" field for this extension shall consist of a single
SequenceNumberLengthValue value, which MUST be selected from the list
provided by the client. If the client receives a
SequenceNumberLengthValue that was not on its supplied list, it MUST
abort the handshake with an "illegal_parameter" exception.
The new sequence number length takes effect following the
change_cipher_spec for the new cipher suite. Because the epoch value
is used to differentiate data from different cipher suite states
(different negotiations) care must be taken when renegotiating
sequence number length during active data transfer. In the worst
case scenario, the receiver may need to try to parse/decrypt the
packet under both potential state settings. Because only one
produces a valid parse with a valid MAC, the correct choice is
unambiguous.
4. Version Field Elimination
Every TLS/DTLS record contains a two-byte version field. This field
is mostly redundant because the correct version is negotiated during
Modadugu & Rescorla Expires August 29, 2006 [Page 5]
Internet-Draft DTLS Low Bandwidth February 2006
the TLS/DTLS handshake. The NoVersionField extension eliminates the
version field from the wire representation.
In order to negotiate the non-use of the version field clients MAY
include an extension of type "no_version_field" in the extended
client hello. The "extension_data" field of this extension shall be
empty.
Servers that receive an extended hello containing a
"no_version_field" extension, MAY agree to omit the version field
including an extension of type "no_version_field", with empty
"extension_data", in the extended server hello.
Once the "no_version_field" extension is negotiated, packets in the
newly negotiated association (i.e., after the change_cipher_spec)
SHALL omit the version field. This does not affect the computation
of the HMAC, which MUST include the version field as negotiated by
the DTLS handshake, i.e., as it would have been included in the
header.
5. Length Field Elimination
DTLS records contain a length field, which allows more than one
record to be carried in a single datagram (though each record must
fit inside a single datagram). However, if the peers agree to place
only one record per datagram, the length field becomes superfluous.
The "no_length_field" extension is used to make this agreement.
In order to negotiate the non-use of the length field clients MAY
include an extension of type "no_length_field" in the extended client
hello. The "extension_data" field of this extension shall be empty.
Servers that receive an extended hello containing a "no_length_field"
extension, MAY agree to omit the length field including an extension
of type "no_length_field", with empty "extension_data", in the
extended server hello.
Once the "no_length_field" extension is negotiated, packets in the
newly negotiated association (i.e., after the change_cipher_spec)
SHALL omit the length field. This does not affect the computation of
the HMAC, which MUST include the length field as negotiated by the
DTLS handshake, i.e., as it would have been included in the header.
When the "no_length_field" extension is in effect, implementations
MUST NOT place more than one record per datagram.
Modadugu & Rescorla Expires August 29, 2006 [Page 6]
Internet-Draft DTLS Low Bandwidth February 2006
6. Implicit Application Data Header
In principle, because all the data in the DTLS header is incorporated
into the DTLS record MAC, the entire header can be omitted and
reconstructed by trying all candidate headers. We propose a somewhat
less radical approach: omitting the header for records of type
"application_data". Because these records comprise the majority of
the traffic on a DTLS connection, this extension provides a
significant optimization while minimizing ambiguity.
In order to negotiate the implicit application data header, clients
MAY include an extension of type "implicit_header" in the extended
client hello. The "extension_data" field of this extension shall be
empty.
Servers that receive an extended hello containing a "implicit_header"
extension, MAY agree to this optimization extension of type
"implicit_header", with empty "extension_data", in the extended
server hello.
Once the "implicit_header" extension is negotiated, application data
records in the newly negotiated association (i.e., after the
change_cipher_spec) SHOULD omit the following values in the DTLS
header:
Content type
Version
Length
Sequence Number
This does not affect the computation of the HMAC, which MUST include
these values as if they were present. In addition, as with the
"no_length_field" extension, there must only be one record per
transport-level datagram.
The "implicit_header" extension introduces some ambiguity in record
receipt processing. This ambiguity can, however, be resolved by
trial decryption. Implementations MAY use the algorithm described
below in order to properly receive a given record. The initial value
of ESN (the expected sequence number) is set to 1 + (sequence number
of the Finished message record), which should be the sequence number
of the first application data record.
1. If the first byte does not match a known content type go to step
5.
2. If the version field does not match the current version go to
step 5.
3. If the length does not match the rest of the record, go to step
5.
Modadugu & Rescorla Expires August 29, 2006 [Page 7]
Internet-Draft DTLS Low Bandwidth February 2006
4. Attempt to decrypt the record as a record with header present.
If the MAC verifies, set ESN to the record sequence number+1 and
pass the record it to the next layer. Otherwise, proceed to step
5.
5. Prepend an application_data header with sequence number of ESN.
Attempt to decrypt. If the MAC checks, set ESN to the record
sequence number+1 and pass the record to the next layer.
6. Repeat step 5 with all ESN values in the current replay window.
7. If no valid ESN can be found, discard the record.
The above algorithm is generic. However, in applications where an
application layer sequence number is present in plaintext in the
record payload (see TODO) (e.g., RTP), it MAY be appropriate to
maintain an offset between the two sequence numbers and use that to
generate the initial ESN estimate in step 5. However, they MUST
still use the sequence number of the last valid packet to set the
replay--and hence resynchronization--window.
Note that although in principle this specification allows the inter-
mixture of application_data records with and without the header,
senders SHOULD generally send records without the header when the
extension is in effect. The one reasonable exception would be if an
application layer sequence number is present and makes a large jump.
Implementations MAY add an explicit application_data header to
several frames to effect a resynchronization.
7. Security Considerations
There are two security concerns introduced by these extensions. The
first involves the security of the negotiation and the second the
security of the transport protocol. Because the negotiation is
protected by the TLS/DTLS handshake, attackers can neither force the
use of these extensions nor block them while allowing the negotiation
to succeed.
Although these extensions involve changing the bits on the wire, the
transformations involved are made in authenticated but unencrypted
data. This has two implications: (1) Any attacker who possesses the
encrypted stream of an ordinary DTLS connection can generate a stream
with any or all of these fields removed. Thus, if a connection uses
these extensions and is weak, the underlying TLS connection must be
weak as well. (2) Although the receiver needs to deduce certain
values, this does not produce a security threat because the attacker
could have replaced the real values on the wire with the values that
the receiver deduces in the low bandwidth version. In both cases,
what stops tampering is the use of a strong MAC.
Modadugu & Rescorla Expires August 29, 2006 [Page 8]
Internet-Draft DTLS Low Bandwidth February 2006
8. IANA Considerations
This document defines four new extensions for DTLS, in accordance
with [4]:
enum { sequence_number_length (??), no_version_field (??),
no_length_field(??), implicit_header (??)} ExtensionType;
[[ NOTE: These values need to be assigned by IANA ]]
The "sequence_number_length", "no_length_field" and "implicit_header"
extensions MAY only be used with DTLS and MUST NOT be used with TLS.
The "no_version_field" extension MAY be used with either DTLS or TLS.
9. References
9.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005.
[4] Blake-Wilson, S., "Transport Layer Security (TLS) Extensions",
draft-ietf-tls-rfc3546bis-02 (work in progress), October 2005.
[5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", draft-rescorla-dtls-05 (work in progress), June 2005.
[6] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005.
9.2. Informative References
[7] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher Suites
for TLS and DTLS", draft-modadugu-tls-ctr-00 (work in progress),
October 2005.
Modadugu & Rescorla Expires August 29, 2006 [Page 9]
Internet-Draft DTLS Low Bandwidth February 2006
Authors' Addresses
Nagendra Modadugu
Stanford University
353 Serra Mall
Stanford, CA 94305
USA
Email: nagendra@cs.stanford.edu
Eric Rescorla
Network Resonance
2483 E. Bayshore Rd., #212
Palo Alto, CA 94303
USA
Email: ekr@networkresonance.com
Modadugu & Rescorla Expires August 29, 2006 [Page 10]
Internet-Draft DTLS Low Bandwidth February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Modadugu & Rescorla Expires August 29, 2006 [Page 11]