idnits 2.17.1 draft-modadugu-dtls-short-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 421. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2006) is 6634 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 356, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. '3') ** Downref: Normative reference to an Historic draft: draft-rescorla-dtls (ref. '5') Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Modadugu 3 Internet-Draft Stanford University 4 Expires: August 29, 2006 E. Rescorla 5 Network Resonance 6 February 25, 2006 8 Extensions for Datagram Transport Layer Security (TLS) in Low Bandwidth 9 Environments 10 draft-modadugu-dtls-short-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 29, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes a series of extensions to Datagram Transport 44 Layer Security (DTLS) which reduce the per-record bandwidth of the 45 data channel. These extensions apply only to the on-the-wire 46 representation of the protocol and do not affect cryptographic 47 processing. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Sequence Number Length . . . . . . . . . . . . . . . . . . . . 4 55 4. Version Field Elimination . . . . . . . . . . . . . . . . . . 5 56 5. Length Field Elimination . . . . . . . . . . . . . . . . . . . 6 57 6. Implicit Application Data Header . . . . . . . . . . . . . . . 7 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 62 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . . . 11 66 1. Introduction 68 Datagram Transport Layer Security (DTLS) [5] is a protocol which 69 provides channel-oriented communications security for datagram 70 traffic. A communication channel that uses DTLS as security protocol 71 incurs some bandwidth overhead that results from additional per- 72 record headers and encryption overhead. Reducing this bandwidth 73 overhead is desireable when DTLS is used in wireless environments or 74 to secure real-time traffic. This document describes a series of 75 extensions to DTLS which reduce the per-record bandwidth. These 76 extensions apply only to the on-the-wire representation of the 77 protocol and do not affect the data subject to cryptographic 78 processing. 80 1.1. Conventions Used In This Document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [2]. 86 2. Background 88 The DTLS record format (based on the TLS [3] record format) is shown 89 below: 91 struct { 92 ContentType type; 93 ProtocolVersion version; 94 uint16 epoch; 95 uint48 sequence_number; 96 uint16 length; 97 opaque fragment[DTLSPlaintext.length]; 98 } DTLSPlaintext; 100 The major sources of per-record overhead in DTLS are: 102 +---------------------------------------------------+---------------+ 103 | Field | size(bytes) | 104 +---------------------------------------------------+---------------+ 105 | type | 1 | 106 | version | 2 | 107 | epoch | 2 | 108 | sequence_number | 6 | 109 | length | 2 | 110 | MAC | 10-20 bytes | 111 | encryption overhead | 9-32 | 112 +---------------------------------------------------+---------------+ 113 The largest performance improvement can be obtained by moving to a 114 cipher suite with less overhead. DTLS-CTR [7] describes such a mode. 115 This document describes how to reduce packet size further by reducing 116 the size of some of the fields in the record. 118 All the optimizations described in this memo are implemented using 119 the TLS Extensions mechanism [4]. 121 3. Sequence Number Length 123 TLS, on which DTLS is based, uses a 64-bit sequence number. However, 124 because TLS must run on a reliable protocol, the sequence number is 125 implicit and does not take up space on the wire. In DTLS, the 126 sequence number is explicit and broken up into a 16-bit "epoch" 127 describing the number of handshakes that have happened on this 128 association and a 48-bit per-epoch sequence number. This has the 129 advantage of simplicity, but the disadvantage of taking up a fair 130 amount of space in the packet. 132 The sequence_number_length extension shortens the on-the-wire 133 representation of the sequence number without shortening the actual 134 sequence number. This means that the high order bits are not present 135 in the packet but rather MUST be deduced. Implementations SHOULD use 136 the technique of Appendix A of [6] to compute the high order bits of 137 the sequence number and epoch number. 139 When the client sends the sequence_number_length extension 140 "extension_data" field must contain a SequenceNumberLengthValues 141 field: 143 uint8 SequenceNumberLengthValue; 144 SequenceNumberLengthValue SequenceNumberLengthValues<1..7>; 146 This field contains the sequence number lengths which the client is 147 willing to accept. These lengths are the combined length in bytes of 148 the sequence number and epoch. Permissible values are 2,3,4,5,6,7,8, 149 with the sequence number and epoch divided up according to the 150 following table: 152 +----------------------+---------------------+----------------------+ 153 | Total | Epoch | Sequence | 154 +----------------------+---------------------+----------------------+ 155 | 2 | 2 bits | 14 bits | 156 | 3 | 4 bits | 20 bits | 157 | 4 | 6 bits | 26 bits | 158 | 5 | 1 byte | 4 bytes | 159 | 6 | 1 byte | 5 bytes | 160 | 7 | 1 byte | 6 bytes | 161 | 8 | 2 bytes | 6 bytes | 162 +----------------------+---------------------+----------------------+ 164 When the sequence number crosses a byte boundary, the high order bits 165 of that byte SHALL be considered to be the epoch and the low order 166 bits SHALL be considered to be the high order bits of the sequence 167 number. Note that the 8-byte value is equivalent to the default DTLS 168 behavior and is provided purely for completeness. 170 If the server receives a SequenceNumberLengthValue that is not one of 171 the allowed values, it MUST abort the handshake with an 172 "illegal_parameter" alert. If the server receives a 173 sequence_number_length extension and does not wish to negotiate 174 sequence_number_length it should ignore the sequence_number_length 175 extension. 177 If the server wishes to negotiate sequence_number_length it responds 178 with its own sequence_number_length extension. The server's 179 "extension_data" field for this extension shall consist of a single 180 SequenceNumberLengthValue value, which MUST be selected from the list 181 provided by the client. If the client receives a 182 SequenceNumberLengthValue that was not on its supplied list, it MUST 183 abort the handshake with an "illegal_parameter" exception. 185 The new sequence number length takes effect following the 186 change_cipher_spec for the new cipher suite. Because the epoch value 187 is used to differentiate data from different cipher suite states 188 (different negotiations) care must be taken when renegotiating 189 sequence number length during active data transfer. In the worst 190 case scenario, the receiver may need to try to parse/decrypt the 191 packet under both potential state settings. Because only one 192 produces a valid parse with a valid MAC, the correct choice is 193 unambiguous. 195 4. Version Field Elimination 197 Every TLS/DTLS record contains a two-byte version field. This field 198 is mostly redundant because the correct version is negotiated during 199 the TLS/DTLS handshake. The NoVersionField extension eliminates the 200 version field from the wire representation. 202 In order to negotiate the non-use of the version field clients MAY 203 include an extension of type "no_version_field" in the extended 204 client hello. The "extension_data" field of this extension shall be 205 empty. 207 Servers that receive an extended hello containing a 208 "no_version_field" extension, MAY agree to omit the version field 209 including an extension of type "no_version_field", with empty 210 "extension_data", in the extended server hello. 212 Once the "no_version_field" extension is negotiated, packets in the 213 newly negotiated association (i.e., after the change_cipher_spec) 214 SHALL omit the version field. This does not affect the computation 215 of the HMAC, which MUST include the version field as negotiated by 216 the DTLS handshake, i.e., as it would have been included in the 217 header. 219 5. Length Field Elimination 221 DTLS records contain a length field, which allows more than one 222 record to be carried in a single datagram (though each record must 223 fit inside a single datagram). However, if the peers agree to place 224 only one record per datagram, the length field becomes superfluous. 225 The "no_length_field" extension is used to make this agreement. 227 In order to negotiate the non-use of the length field clients MAY 228 include an extension of type "no_length_field" in the extended client 229 hello. The "extension_data" field of this extension shall be empty. 231 Servers that receive an extended hello containing a "no_length_field" 232 extension, MAY agree to omit the length field including an extension 233 of type "no_length_field", with empty "extension_data", in the 234 extended server hello. 236 Once the "no_length_field" extension is negotiated, packets in the 237 newly negotiated association (i.e., after the change_cipher_spec) 238 SHALL omit the length field. This does not affect the computation of 239 the HMAC, which MUST include the length field as negotiated by the 240 DTLS handshake, i.e., as it would have been included in the header. 241 When the "no_length_field" extension is in effect, implementations 242 MUST NOT place more than one record per datagram. 244 6. Implicit Application Data Header 246 In principle, because all the data in the DTLS header is incorporated 247 into the DTLS record MAC, the entire header can be omitted and 248 reconstructed by trying all candidate headers. We propose a somewhat 249 less radical approach: omitting the header for records of type 250 "application_data". Because these records comprise the majority of 251 the traffic on a DTLS connection, this extension provides a 252 significant optimization while minimizing ambiguity. 254 In order to negotiate the implicit application data header, clients 255 MAY include an extension of type "implicit_header" in the extended 256 client hello. The "extension_data" field of this extension shall be 257 empty. 259 Servers that receive an extended hello containing a "implicit_header" 260 extension, MAY agree to this optimization extension of type 261 "implicit_header", with empty "extension_data", in the extended 262 server hello. 264 Once the "implicit_header" extension is negotiated, application data 265 records in the newly negotiated association (i.e., after the 266 change_cipher_spec) SHOULD omit the following values in the DTLS 267 header: 268 Content type 269 Version 270 Length 271 Sequence Number 272 This does not affect the computation of the HMAC, which MUST include 273 these values as if they were present. In addition, as with the 274 "no_length_field" extension, there must only be one record per 275 transport-level datagram. 277 The "implicit_header" extension introduces some ambiguity in record 278 receipt processing. This ambiguity can, however, be resolved by 279 trial decryption. Implementations MAY use the algorithm described 280 below in order to properly receive a given record. The initial value 281 of ESN (the expected sequence number) is set to 1 + (sequence number 282 of the Finished message record), which should be the sequence number 283 of the first application data record. 284 1. If the first byte does not match a known content type go to step 285 5. 286 2. If the version field does not match the current version go to 287 step 5. 288 3. If the length does not match the rest of the record, go to step 289 5. 291 4. Attempt to decrypt the record as a record with header present. 292 If the MAC verifies, set ESN to the record sequence number+1 and 293 pass the record it to the next layer. Otherwise, proceed to step 294 5. 295 5. Prepend an application_data header with sequence number of ESN. 296 Attempt to decrypt. If the MAC checks, set ESN to the record 297 sequence number+1 and pass the record to the next layer. 298 6. Repeat step 5 with all ESN values in the current replay window. 299 7. If no valid ESN can be found, discard the record. 301 The above algorithm is generic. However, in applications where an 302 application layer sequence number is present in plaintext in the 303 record payload (see TODO) (e.g., RTP), it MAY be appropriate to 304 maintain an offset between the two sequence numbers and use that to 305 generate the initial ESN estimate in step 5. However, they MUST 306 still use the sequence number of the last valid packet to set the 307 replay--and hence resynchronization--window. 309 Note that although in principle this specification allows the inter- 310 mixture of application_data records with and without the header, 311 senders SHOULD generally send records without the header when the 312 extension is in effect. The one reasonable exception would be if an 313 application layer sequence number is present and makes a large jump. 314 Implementations MAY add an explicit application_data header to 315 several frames to effect a resynchronization. 317 7. Security Considerations 319 There are two security concerns introduced by these extensions. The 320 first involves the security of the negotiation and the second the 321 security of the transport protocol. Because the negotiation is 322 protected by the TLS/DTLS handshake, attackers can neither force the 323 use of these extensions nor block them while allowing the negotiation 324 to succeed. 326 Although these extensions involve changing the bits on the wire, the 327 transformations involved are made in authenticated but unencrypted 328 data. This has two implications: (1) Any attacker who possesses the 329 encrypted stream of an ordinary DTLS connection can generate a stream 330 with any or all of these fields removed. Thus, if a connection uses 331 these extensions and is weak, the underlying TLS connection must be 332 weak as well. (2) Although the receiver needs to deduce certain 333 values, this does not produce a security threat because the attacker 334 could have replaced the real values on the wire with the values that 335 the receiver deduces in the low bandwidth version. In both cases, 336 what stops tampering is the use of a strong MAC. 338 8. IANA Considerations 340 This document defines four new extensions for DTLS, in accordance 341 with [4]: 343 enum { sequence_number_length (??), no_version_field (??), 344 no_length_field(??), implicit_header (??)} ExtensionType; 346 [[ NOTE: These values need to be assigned by IANA ]] 348 The "sequence_number_length", "no_length_field" and "implicit_header" 349 extensions MAY only be used with DTLS and MUST NOT be used with TLS. 350 The "no_version_field" extension MAY be used with either DTLS or TLS. 352 9. References 354 9.1. Normative References 356 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 357 "RTP: A Transport Protocol for Real-Time Applications", 358 RFC 1889, January 1996. 360 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 361 Levels", BCP 14, RFC 2119, March 1997. 363 [3] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 364 draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. 366 [4] Blake-Wilson, S., "Transport Layer Security (TLS) Extensions", 367 draft-ietf-tls-rfc3546bis-02 (work in progress), October 2005. 369 [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 370 Security", draft-rescorla-dtls-05 (work in progress), June 2005. 372 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", 373 draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005. 375 9.2. Informative References 377 [7] Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher Suites 378 for TLS and DTLS", draft-modadugu-tls-ctr-00 (work in progress), 379 October 2005. 381 Authors' Addresses 383 Nagendra Modadugu 384 Stanford University 385 353 Serra Mall 386 Stanford, CA 94305 387 USA 389 Email: nagendra@cs.stanford.edu 391 Eric Rescorla 392 Network Resonance 393 2483 E. Bayshore Rd., #212 394 Palo Alto, CA 94303 395 USA 397 Email: ekr@networkresonance.com 399 Intellectual Property Statement 401 The IETF takes no position regarding the validity or scope of any 402 Intellectual Property Rights or other rights that might be claimed to 403 pertain to the implementation or use of the technology described in 404 this document or the extent to which any license under such rights 405 might or might not be available; nor does it represent that it has 406 made any independent effort to identify any such rights. Information 407 on the procedures with respect to rights in RFC documents can be 408 found in BCP 78 and BCP 79. 410 Copies of IPR disclosures made to the IETF Secretariat and any 411 assurances of licenses to be made available, or the result of an 412 attempt made to obtain a general license or permission for the use of 413 such proprietary rights by implementers or users of this 414 specification can be obtained from the IETF on-line IPR repository at 415 http://www.ietf.org/ipr. 417 The IETF invites any interested party to bring to its attention any 418 copyrights, patents or patent applications, or other proprietary 419 rights that may cover technology that may be required to implement 420 this standard. Please address the information to the IETF at 421 ietf-ipr@ietf.org. 423 Disclaimer of Validity 425 This document and the information contained herein are provided on an 426 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 427 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 428 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 429 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 430 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 431 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 433 Copyright Statement 435 Copyright (C) The Internet Society (2006). This document is subject 436 to the rights, licenses and restrictions contained in BCP 78, and 437 except as set forth therein, the authors retain all their rights. 439 Acknowledgment 441 Funding for the RFC Editor function is currently provided by the 442 Internet Society.