[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]