idnits 2.17.1 draft-ietf-tls-rfc4347-bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 25 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 615 has weird spacing: '...ttacker rep...' == Line 621 has weird spacing: '...tant to for...' == Line 622 has weird spacing: '... alerts beca...' == Line 623 has weird spacing: '...m which will ...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 909, but not defined ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS1') (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS11') (Obsoleted by RFC 5246) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT E. Rescorla 3 Obsoletes (if approved): RFC 4347 RTFM, Inc. 4 Intended Status: Proposed Standard N. Modadugu 5 Stanford University 6 July 12, 2010 (Expires January 2011) 8 Datagram Transport Layer Security version 1.2 10 Status of This Memo 12 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 14 Copyright (c) 2010 IETF Trust and the persons identified as 15 the document authors. All rights reserved. 17 This document is subject to BCP 78 and the IETF Trust's Legal 18 Provisions Relating to IETF Documents 19 (http://trustee.ietf.org/license-info) in effect on the date of 20 publication of this document. Please review these documents carefully, 21 as they describe your rights and restrictions with respect to this 22 document. Code Components extracted from this document must include 23 Simplified BSD License text as described in Section 4.e of the Trust 24 Legal Provisions and are provided without warranty as described in the 25 Simplified BSD License. 27 This document may contain material from IETF Documents or IETF 28 Contributions published or made publicly available before November 29 10, 2008. The person(s) controlling the copyright in some of this 30 material may not have granted the IETF Trust the right to allow 31 modifications of such material outside the IETF Standards Process. 32 Without obtaining an adequate license from the person(s) 33 controlling the copyright in such materials, this document may not 34 be modified outside the IETF Standards Process, and derivative 35 works of it may not be created outside the IETF Standards Process, 36 except to format it for publication as an RFC or to translate it 37 into languages other than English. 39 Internet-Drafts are working documents of the Internet Engineering Task 40 Force (IETF), its areas, and its working groups. Note that other 41 groups may also distribute working documents as Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 Copyright Notice 55 Copyright (c) 2009 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents in effect on the date of 60 publication of this document (http://trustee.ietf.org/license-info). 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. 64 Abstract 66 This document specifies Version 1.2 of the Datagram Transport Layer 67 Security (DTLS) protocol. The DTLS protocol provides communications 68 privacy for datagram protocols. The protocol allows client/server 69 applications to communicate in a way that is designed to prevent 70 eavesdropping, tampering, or message forgery. The DTLS protocol is 71 based on the Transport Layer Security (TLS) protocol and provides 72 equivalent security guarantees. Datagram semantics of the underlying 73 transport are preserved by the DTLS protocol. This document updates 74 DTLS 1.0 to work with TLS version 1.2. 76 Legal 78 This documents and the information contained therein are provided on 79 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 80 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 81 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 82 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 83 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 84 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 85 FOR A PARTICULAR PURPOSE. 87 Table of Contents 89 1. Introduction 3 90 1.1. Requirements Terminology 4 91 2. Usage Model 4 92 3. Overview of DTLS 5 93 3.1. Loss-Insensitive Messaging 5 94 3.2. Providing Reliability for Handshake 5 95 3.2.1. Packet Loss 6 96 3.2.2. Reordering 6 97 3.2.3. Message Size 6 98 3.3. Replay Detection 7 99 4. Differences from TLS 7 100 4.1. Record Layer 7 101 4.1.1. Transport Layer Mapping 9 102 4.1.1.1. PMTU Issues 10 103 4.1.2. Record Payload Protection 11 104 4.1.2.1. MAC 11 105 4.1.2.2. Null or Standard Stream Cipher 12 106 4.1.2.3. Block Cipher 12 107 4.1.2.3. AEAD Ciphers 12 108 4.1.2.5. New Cipher Suites 12 109 4.1.2.6. Anti-replay 13 110 4.1.2.7. Handling Invalid Records 13 111 4.2. The DTLS Handshake Protocol 14 112 4.2.1. Denial of Service Countermeasures 14 113 4.2.2. Handshake Message Format 17 114 4.2.3. Message Fragmentation and Reassembly 18 115 4.2.4. Timeout and Retransmission 19 116 4.2.4.1. Timer Values 23 117 4.2.5. ChangeCipherSpec 23 118 4.2.6. CertificateVerify and Finished Messages 23 119 4.2.7. Alert Messages 23 120 4.3. Summary of new syntax 24 121 4.3.1. Record Layer 25 122 4.3.2. Handshake Protocol 25 123 5. Security Considerations 26 124 6. Acknowledgements 27 125 7. IANA Considerations 27 126 8. References 27 127 8.1. Normative References 27 128 8.2. Informative References 28 130 1. Introduction 132 TLS [TLS] is the most widely deployed protocol for securing network 133 traffic. It is widely used for protecting Web traffic and for e-mail 134 protocols such as IMAP [IMAP] and POP [POP]. The primary advantage 135 of TLS is that it provides a transparent connection-oriented channel. 136 Thus, it is easy to secure an application protocol by inserting TLS 137 between the application layer and the transport layer. However, TLS 138 must run over a reliable transport channel -- typically TCP [TCP]. 139 It therefore cannot be used to secure unreliable datagram traffic. 141 However, an increasing number of application layer protocols have 142 been designed that use UDP transport. In particular protocols such 143 as the Session Initiation Protocol (SIP) [SIP] and electronic gaming 144 protocols are increasingly popular. (Note that SIP can run over both 145 TCP and UDP, but that there are situations in which UDP is 146 preferable). Currently, designers of these applications are faced 147 with a number of unsatisfactory choices. First, they can use IPsec 148 [RFC4301]. However, for a number of reasons detailed in [WHYIPSEC], 149 this is only suitable for some applications. Second, they can design 150 a custom application layer security protocol. Unfortunately, 151 although application layer security protocols generally provide 152 superior security properties (e.g., end-to-end security in the case 153 of S/MIME), they typically require a large amount of effort to design 154 -- in contrast to the relatively small amount of effort required to 155 run the protocol over TLS. 157 In many cases, the most desirable way to secure client/server 158 applications would be to use TLS; however, the requirement for 159 datagram semantics automatically prohibits use of TLS. This memo 160 describes a protocol for this purpose: Datagram Transport Layer 161 Security (DTLS). DTLS is deliberately designed to be as similar to 162 TLS as possible, both to minimize new security invention and to 163 maximize the amount of code and infrastructure reuse. 165 DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This 166 document introduces a new version of DTLS, DTLS 1.2, which is defined 167 as a series of deltas to TLS 1.2 [TLS12] There is no DTLS 1.1. That 168 version number was skipped in order to harmonize version numbers with 169 TLS. This version also clarifies some confusing points in the DTLS 170 1.0 specification. 172 1.1. Requirements Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [REQ]. 178 2. Usage Model 180 The DTLS protocol is designed to secure data between communicating 181 applications. It is designed to run in application space, without 182 requiring any kernel modifications. 184 Datagram transport does not require or provide reliable or in-order 185 delivery of data. The DTLS protocol preserves this property for 186 payload data. Applications such as media streaming, Internet 187 telephony, and online gaming use datagram transport for communication 188 due to the delay-sensitive nature of transported data. The behavior 189 of such applications is unchanged when the DTLS protocol is used to 190 secure communication, since the DTLS protocol does not compensate for 191 lost or re-ordered data traffic. 193 3. Overview of DTLS 195 The basic design philosophy of DTLS is to construct "TLS over 196 datagram transport." The reason that TLS cannot be used directly in 197 datagram environments is simply that packets may be lost or 198 reordered. TLS has no internal facilities to handle this kind of 199 unreliability, and therefore TLS implementations break when rehosted 200 on datagram transport. The purpose of DTLS is to make only the 201 minimal changes to TLS required to fix this problem. To the greatest 202 extent possible, DTLS is identical to TLS. Whenever we need to 203 invent new mechanisms, we attempt to do so in such a way that 204 preserves the style of TLS. 206 Unreliability creates problems for TLS at two levels: 208 1. TLS does not allow independent decryption of individual 209 records. Because the integrity check depends on the sequence 210 number, if record N is not received, then the integrity check on 211 record N+1 will be based on the wrong sequence number and thus 212 will fail. [Note that prior to TLS 1.1, there was no explicit IV 213 and so decryption would also fail.] 215 2. The TLS handshake layer assumes that handshake messages are 216 delivered reliably and breaks if those messages are lost. 218 The rest of this section describes the approach that DTLS uses to 219 solve these problems. 221 3.1. Loss-Insensitive Messaging 223 In TLS's traffic encryption layer (called the TLS Record Layer), 224 records are not independent. There are two kinds of inter-record 225 dependency: 227 1. Cryptographic context (stream cipher key stream) is retained 228 between records. 230 2. Anti-replay and message reordering protection are provided by a 231 MAC that includes a sequence number, but the sequence numbers are 232 implicit in the records. 234 DTLS solves the first problem by banning stream ciphers. DTLS solves 235 the second problem by adding explicit sequence numbers. 237 3.2. Providing Reliability for Handshake 238 The TLS handshake is a lockstep cryptographic handshake. Messages 239 must be transmitted and received in a defined order, and any other 240 order is an error. Clearly, this is incompatible with reordering and 241 message loss. In addition, TLS handshake messages are potentially 242 larger than any given datagram, thus creating the problem of 243 fragmentation. DTLS must provide fixes for both of these problems. 245 3.2.1. Packet Loss 247 DTLS uses a simple retransmission timer to handle packet loss. The 248 following figure demonstrates the basic concept, using the first 249 phase of the DTLS handshake: 251 Client Server 252 ------ ------ 253 ClientHello ------> 255 X<-- HelloVerifyRequest 256 (lost) 258 [Timer Expires] 260 ClientHello ------> 261 (retransmit) 263 Once the client has transmitted the ClientHello message, it expects 264 to see a HelloVerifyRequest from the server. However, if the 265 server's message is lost the client knows that either the ClientHello 266 or the HelloVerifyRequest has been lost and retransmits. When the 267 server receives the retransmission, it knows to retransmit. The 268 server also maintains a retransmission timer and retransmits when 269 that timer expires. 271 Note: timeout and retransmission do not apply to the 272 HelloVerifyRequest, because this requires creating state on the 273 server. 275 3.2.2. Reordering 277 In DTLS, each handshake message is assigned a specific sequence 278 number within that handshake. When a peer receives a handshake 279 message, it can quickly determine whether that message is the next 280 message it expects. If it is, then it processes it. If not, it 281 queues it up for future handling once all previous messages have been 282 received. 284 3.2.3. Message Size 285 TLS and DTLS handshake messages can be quite large (in theory up to 286 2^24-1 bytes, in practice many kilobytes). By contrast, UDP 287 datagrams are often limited to <1500 bytes if fragmentation is not 288 desired. In order to compensate for this limitation, each DTLS 289 handshake message may be fragmented over several DTLS records. Each 290 DTLS handshake message contains both a fragment offset and a fragment 291 length. Thus, a recipient in possession of all bytes of a handshake 292 message can reassemble the original unfragmented message. 294 3.3. Replay Detection 296 DTLS optionally supports record replay detection. The technique used 297 is the same as in IPsec AH/ESP, by maintaining a bitmap window of 298 received records. Records that are too old to fit in the window and 299 records that have previously been received are silently discarded. 300 The replay detection feature is optional, since packet duplication is 301 not always malicious, but can also occur due to routing errors. 302 Applications may conceivably detect duplicate packets and accordingly 303 modify their data transmission strategy. 305 4. Differences from TLS 307 As mentioned in Section 3, DTLS is intentionally very similar to TLS. 308 Therefore, instead of presenting DTLS as a new protocol, we present 309 it as a series of deltas from TLS 1.2 [TLS12]. Where we do not 310 explicitly call out differences, DTLS is the same as in [TLS12]. 312 4.1. Record Layer 314 The DTLS record layer is extremely similar to that of TLS 1.2. The 315 only change is the inclusion of an explicit sequence number in the 316 record. This sequence number allows the recipient to correctly 317 verify the TLS MAC. The DTLS record format is shown below: 319 struct { 320 ContentType type; 321 ProtocolVersion version; 322 uint16 epoch; // New field 323 uint48 sequence_number; // New field 324 uint16 length; 325 opaque fragment[DTLSPlaintext.length]; 326 } DTLSPlaintext; 328 type 329 Equivalent to the type field in a TLS 1.2 record. 331 version 332 The version of the protocol being employed. This document 333 describes DTLS Version 1.2, which uses the version { 254, 253 334 }. The version value of 254.253 is the 1's complement of DTLS 335 Version 1.2. This maximal spacing between TLS and DTLS version 336 numbers ensures that records from the two protocols can be 337 easily distinguished. It should be noted that future on-the-wire 338 version numbers of DTLS are decreasing in value (while the true 339 version number is increasing in value.) 341 epoch 342 A counter value that is incremented on every cipher state 343 change. 345 sequence_number 346 The sequence number for this record. 348 length 349 Identical to the length field in a TLS 1.2 record. As in TLS 350 1.2, the length should not exceed 2^14. 352 fragment 353 Identical to the fragment field of a TLS 1.2 record. 355 DTLS uses an explicit sequence number, rather than an implicit one, 356 carried in the sequence_number field of the record. Sequence numbers 357 are maintained separately for each epoch, with each sequence_number 358 initially being 0 for each epoch. For instance, if a handshake 359 message from epoch 0 is retransmitted, it might have a sequence 360 number after a message from epoch 1, even if the message from epoch 1 361 was transmitted first. Note that some care needs to be taken during 362 the handshake to ensure that retransmitted messages use the right 363 epoch and keying material. 365 If several handshakes are performed in close succession, there might 366 be multiple records on the wire with the same sequence number but 367 from different cipher states. The epoch field allows recipients to 368 distinguish such packets. The epoch number is initially zero and is 369 incremented each time the ChangeCipherSpec messages is sent. In 370 order to ensure that any given sequence/epoch pair is unique, 371 implementations MUST NOT allow the same epoch value to be reused 372 within two times the TCP maximum segment lifetime. In practice, TLS 373 implementations rarely rehandshake and we therefore do not expect 374 this to be a problem. 376 Note that because DTLS records may be reordered, a record from epoch 377 1 may be received after epoch 2 has begun. In general, 378 implementations SHOULD discard packets from earlier epochs, but if 379 packet loss causes noticeable problems MAY choose to retain keying 380 material from previous epochs for up to 120 seconds (the default TCP 381 MSL) to allow for packet reordering. Until the handshake has 382 completed, implementations MUST accept packets from the old epoch. 384 Conversely, it is possible for records that are protected by the 385 newly negotiated context to be received prior to the completion of a 386 handshake. For instance, the server may send its Finished and then 387 start transmitting data. Implementations MAY either buffer or 388 discard such packets, though when DTLS is used over reliable 389 transports (e.g., SCTP), they SHOULD be buffered and processed once 390 the handshake completes. Note that TLS's restrictions on when 391 packets may be sent still apply, and the receiver treats the packets 392 as if they were sent in the right order. In particular, it is still 393 impermissible to send data prior to completion of the first 394 handshake. 396 Note that in the special case of a rehandshake on an existing 397 association, it is safe to process a data packet immediately even if 398 the ChangeCipherSpec or Finished has not yet been received provided 399 that either the rehandshake resumes the existing session or that it 400 uses exactly the same security parameters as the existing 401 association. In an other case, the implementation MUST wait for the 402 receipt of the Finished to prevent downgrade attack. 404 4.1.1. Transport Layer Mapping 406 Each DTLS record MUST fit within a single datagram. In order to 407 avoid fragmentation, clients of the DTLS record layer SHOULD attempt 408 to size records so that they fit within any PMTU estimates obtained 409 from the record layer. 411 Note that unlike IPsec, DTLS records do not contain any association 412 identifiers. Applications must arrange to multiplex between 413 associations. With UDP, this is presumably done with host/port 414 number. 416 Multiple DTLS records may be placed in a single datagram. They are 417 simply encoded consecutively. The DTLS record framing is sufficient 418 to determine the boundaries. Note, however, that the first byte of 419 the datagram payload must be the beginning of a record. Records may 420 not span datagrams. 422 Some transports, such as DCCP [DCCP] provide their own sequence 423 numbers. When carried over those transports, both the DTLS and the 424 transport sequence numbers will be present. Although this introduces 425 a small amount of inefficiency, the transport layer and DTLS sequence 426 numbers serve different purposes, and therefore for conceptual 427 simplicity it is superior to use both sequence numbers. In the 428 future, extensions to DTLS may be specified that allow the use of 429 only one set of sequence numbers for deployment in constrained 430 environments. 432 Some transports, such as DCCP, provide congestion control for traffic 433 carried over them. If the congestion window is sufficiently narrow, 434 DTLS handshake retransmissions may be held rather than transmitted 435 immediately, potentially leading to timeouts and spurious 436 retransmission. When DTLS is used over such transports, care should 437 be taken not to overrun the likely congestion window. [DCCPDTLS] 438 defines a mapping of DTLS to DCCP that takes these issues into 439 account. 441 4.1.1.1. PMTU Issues 443 In general, DTLS's philosophy is to leave PMTU discovery to the 444 application. However, DTLS cannot completely ignore PMTU for three 445 reasons: 447 - The DTLS record framing expands the datagram size, 448 thus lowering the effective PMTU from the application's 449 perspective. 451 - In some implementations the application may not directly 452 talk to the network, in which case the DTLS stack may 453 absorb ICMP [RFC1191] Datagram Too Big indications. 455 - The DTLS handshake messages can exceed the PMTU. 457 In order to deal with the first two issues, the DTLS record layer 458 SHOULD behave as described below. 460 If PMTU estimates are available from the underlying transport 461 protocol, they should be made available to upper layer protocols. In 462 particular: 464 - For DTLS over UDP, the upper layer protocol SHOULD be allowed 465 to obtain the PMTU estimate maintained in the IP layer. 467 - For DTLS over DCCP, the upper layer protocol 468 SHOULD be allowed to obtain the current estimate of the 469 PMTU. 471 - For DTLS over TCP or SCTP, which automatically fragment 472 and reassemble datagrams, there is no PMTU limitation. 473 However, the upper layer protocol MUST NOT write any 474 record that exceeds the maximum record size of 2^14 bytes. 476 The DTLS record layer SHOULD allow the upper layer protocol to 477 discover the amount of record expansion expected by the DTLS 478 processing. Note that this number is only an estimate because of 479 block padding and the potential use of DTLS compression. 481 If there is a transport protocol indication (either via ICMP or via a 482 refusal to send the datagram as in DCCP Section 14), then DTLS record 483 layer should inform the upper layer protocol of the error. 485 The DTLS record layer SHOULD NOT interfere with upper layer protocols 486 performing PMTU discovery, whether via [RFC1191] or [RFC4821] 487 mechanisms. In particular: 489 - Where allowed by the underlying transport protocol, 490 the upper layer protocol SHOULD be allowed to set 491 the state of the DF bit (in IPv4) or prohibit local 492 fragmentation (in IPv6). 494 - If the underlying transport protocol allows the application 495 to request PMTU probing (e.g., DCCP), the DTLS record 496 layer should honor this request. 498 The final issue is the DTLS handshake protocol. From the perspective 499 of the DTLS record layer, this is merely another upper layer 500 protocol. However, DTLS handshakes occur infrequently and involve 501 only a few round trips, and therefore the handshake protocol PMTU 502 handling places a premium on rapid completion over accurate PMTU 503 discovery. In order to allow connections under these circumstances, 504 DTLS implementations SHOULD follow the following rules: 506 - If the DTLS record layer informs the DTLS handshake layer 507 that a message is too big, it SHOULD immediately attempt 508 to fragment it, using any existing information about the 509 PMTU. 511 - If repeated retransmissions do not result in a response, and the 512 PMTU is unknown, subsequent retransmissions SHOULD back off to a 513 smaller record size, fragmenting the handshake message as 514 appropriate. This standard does not specify an exact number 515 of retransmits to attempt before backing off, but 2-3 seems 516 appropriate. 518 4.1.2. Record Payload Protection 520 Like TLS, DTLS transmits data as a series of protected records. The 521 rest of this section describes the details of that format. 523 4.1.2.1. MAC 524 The DTLS MAC is the same as that of TLS 1.2. However, rather than 525 using TLS's implicit sequence number, the sequence number used to 526 compute the MAC is the 64-bit value formed by concatenating the epoch 527 and the sequence number in the order they appear on the wire. Note 528 that the DTLS epoch + sequence number is the same length as the TLS 529 sequence number. 531 TLS MAC calculation is parameterized on the protocol version number, 532 which, in the case of DTLS, is the on-the-wire version, i.e., {254, 533 253} for DTLS 1.2. 535 Note that one important difference between DTLS and TLS MAC handling 536 is that in TLS MAC errors must result in connection termination. In 537 DTLS, the receiving implementation MAY simply discard the offending 538 record and continue with the connection. This change is possible 539 because DTLS records are not dependent on each other in the way that 540 TLS records are. 542 In general, DTLS implementations SHOULD silently discard records with 543 bad MACs or that are otherwise invalid. If a DTLS implementation 544 chooses to generate an alert when it receives a message with an 545 invalid MAC, it MUST generate a bad_record_mac alert with level fatal 546 and terminate its connection state. 548 4.1.2.2. Null or Standard Stream Cipher 550 The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher. 552 The only stream cipher described in TLS 1.2 is RC4, which cannot be 553 randomly accessed. RC4 MUST NOT be used with DTLS. 555 4.1.2.3. Block Cipher 557 DTLS block cipher encryption and decryption are performed exactly as 558 with TLS 1.2. 560 4.1.2.3. AEAD Ciphers 562 TLS 1.2 introduced authenticated encryption with additional data 563 (AEAD) cipher suites. The existing AEAD cipher suites, defined in 564 [ECCGCM] and [RSAGCM] can be used with DTLS exactly as with TLS 1.2. 566 4.1.2.5. New Cipher Suites 568 Upon registration, new TLS cipher suites MUST indicate whether they 569 are suitable for DTLS usage and what, if any, adaptations must be 570 made. 572 4.1.2.6. Anti-replay 574 DTLS records contain a sequence number to provide replay protection. 575 Sequence number verification SHOULD be performed using the following 576 sliding window procedure, borrowed from Section 3.4.3 of [ESP]. 578 The receiver packet counter for this session MUST be initialized to 579 zero when the session is established. For each received record, the 580 receiver MUST verify that the record contains a Sequence Number that 581 does not duplicate the Sequence Number of any other record received 582 during the life of this session. This SHOULD be the first check 583 applied to a packet after it has been matched to a session, to speed 584 rejection of duplicate records. 586 Duplicates are rejected through the use of a sliding receive window. 587 (How the window is implemented is a local matter, but the following 588 text describes the functionality that the implementation must 589 exhibit.) A minimum window size of 32 MUST be supported, but a 590 window size of 64 is preferred and SHOULD be employed as the default. 591 Another window size (larger than the minimum) MAY be chosen by the 592 receiver. (The receiver does not notify the sender of the window 593 size.) 595 The "right" edge of the window represents the highest validated 596 Sequence Number value received on this session. Records that contain 597 Sequence Numbers lower than the "left" edge of the window are 598 rejected. Packets falling within the window are checked against a 599 list of received packets within the window. An efficient means for 600 performing this check, based on the use of a bit mask, is described 601 in Section 3.4.3 of [ESP]. 603 If the received record falls within the window and is new, or if the 604 packet is to the right of the window, then the receiver proceeds to 605 MAC verification. If the MAC validation fails, the receiver MUST 606 discard the received record as invalid. The receive window is 607 updated only if the MAC verification succeeds. 609 4.1.2.7. Handling Invalid Records 610 Unlike TLS, DTLS is resilient in the face of invalid 611 records (e.g., invalid formatting, length, MAC, etc.) In 612 general, invalid records SHOULD be silently discarded, thus 613 preserving the association. Implementations which choose to 614 generate an alert instead, MUST generate fatal level alerts to 615 avoid attacks where the attacker repeatedly probes the 616 implementation to see how it responds to various types of error. 617 Note that if DTLS is run over UDP, then any implementation which 618 does this will be extremely susceptible to DoS attacks because 619 UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED 620 for such transports. If DTLS is being carried over a 621 transport which is resistant to forgery (e.g., SCTP with SCTP- 622 AUTH), then it is safer to send alerts because an attacker will 623 have difficulty forging a datagram which will not be rejected by the 624 transport layer. 626 4.2. The DTLS Handshake Protocol 628 DTLS uses all of the same handshake messages and flows as TLS, with 629 three principal changes: 631 1. A stateless cookie exchange has been added to prevent denial of 632 service attacks. 634 2. Modifications to the handshake header to handle message loss, 635 reordering, and fragmentation. 637 3. Retransmission timers to handle message loss. 639 With these exceptions, the DTLS message formats, flows, and logic are 640 the same as those of TLS 1.2. 642 4.2.1. Denial of Service Countermeasures 644 Datagram security protocols are extremely susceptible to a variety of 645 denial of service (DoS) attacks. Two attacks are of particular 646 concern: 648 1. An attacker can consume excessive resources on the server by 649 transmitting a series of handshake initiation requests, causing 650 the server to allocate state and potentially to perform expensive 651 cryptographic operations. 653 2. An attacker can use the server as an amplifier by sending 654 connection initiation messages with a forged source of the victim. 655 The server then sends its next message (in DTLS, a Certificate 656 message, which can be quite large) to the victim machine, thus 657 flooding it. 659 In order to counter both of these attacks, DTLS borrows the stateless 660 cookie technique used by Photuris [PHOTURIS] and IKE [IKEv2]. When 661 the client sends its ClientHello message to the server, the server 662 MAY respond with a HelloVerifyRequest message. This message contains 663 a stateless cookie generated using the technique of [PHOTURIS]. The 664 client MUST retransmit the ClientHello with the cookie added. The 665 server then verifies the cookie and proceeds with the handshake only 666 if it is valid. This mechanism forces the attacker/client to be able 667 to receive the cookie, which makes DoS attacks with spoofed IP 668 addresses difficult. This mechanism does not provide any defense 669 against DoS attacks mounted from valid IP addresses. 671 The exchange is shown below: 673 Client Server 674 ------ ------ 675 ClientHello ------> 677 <----- HelloVerifyRequest 678 (contains cookie) 680 ClientHello ------> 681 (with cookie) 683 [Rest of handshake] 685 DTLS therefore modifies the ClientHello message to add the cookie 686 value. 688 struct { 689 ProtocolVersion client_version; 690 Random random; 691 SessionID session_id; 692 opaque cookie<0..2^8-1>; // New field 693 CipherSuite cipher_suites<2..2^16-1>; 694 CompressionMethod compression_methods<1..2^8-1>; 695 } ClientHello; 697 When sending the first ClientHello, the client does not have a cookie 698 yet; in this case, the Cookie field is left empty (zero length). 700 The definition of HelloVerifyRequest is as follows: 702 struct { 703 ProtocolVersion server_version; 704 opaque cookie<0..2^8-1>; 705 } HelloVerifyRequest; 707 The HelloVerifyRequest message type is hello_verify_request(3). 709 The server_version field is defined as in TLS. 711 When responding to a HelloVerifyRequest the client MUST use the same 712 parameter values (version, random, session_id, cipher_suites, 713 compression_method) as it did in the original ClientHello. The 714 server SHOULD use those values to generate its cookie and verify that 715 they are correct upon cookie receipt. The server MUST use the same 716 version number in the HelloVerifyRequest that it would use when 717 sending a ServerHello. Upon receipt of the ServerHello, the client 718 MUST verify that the server version values match. 720 Note: this specification increases the cookie size limit to 255 bytes 721 for greater future flexibility. The limit remains 32 for previous 722 versions of DTLS. 724 The DTLS server SHOULD generate cookies in such a way that they can 725 be verified without retaining any per-client state on the server. 726 One technique is to have a randomly generated secret and generate 727 cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters) 729 When the second ClientHello is received, the server can verify that 730 the Cookie is valid and that the client can receive packets at the 731 given IP address. 733 One potential attack on this scheme is for the attacker to collect a 734 number of cookies from different addresses and then reuse them to 735 attack the server. The server can defend against this attack by 736 changing the Secret value frequently, thus invalidating those 737 cookies. If the server wishes that legitimate clients be able to 738 handshake through the transition (e.g., they received a cookie with 739 Secret 1 and then sent the second ClientHello after the server has 740 changed to Secret 2), the server can have a limited window during 741 which it accepts both secrets. [IKEv2] suggests adding a version 742 number to cookies to detect this case. An alternative approach is 743 simply to try verifying with both secrets. 745 DTLS servers SHOULD perform a cookie exchange whenever a new 746 handshake is being performed. If the server is being operated in an 747 environment where amplification is not a problem, the server MAY be 748 configured not to perform a cookie exchange. The default SHOULD be 749 that the exchange is performed, however. In addition, the server MAY 750 choose not to do a cookie exchange when a session is resumed. 751 Clients MUST be prepared to do a cookie exchange with every 752 handshake. 754 If HelloVerifyRequest is used, the initial ClientHello and 755 HelloVerifyRequest are not included in the calculation of the 756 handshake_messages (for the CertificateVerify message) and 757 verify_data (for the Finished message). 759 If a server receives a ClientHello with an invalid cookie, it SHOULD 760 treat it the same as a ClientHello with no cookie. This avoids 761 race/deadlock conditions if the client somehow gets a bad cookie 762 (e.g., because the server changes its cookie signing key). Note to 763 implementors: this may results in clients receiving multiple 764 HelloVerifyRequest messages with different cookies. Clients SHOULD 765 handle this by sending a new ClientHello with a cookie in response to 766 the new HelloVerifyRequest. 768 4.2.2. Handshake Message Format 770 In order to support message loss, reordering, and fragmentation, DTLS 771 modifies the TLS 1.2 handshake header: 773 struct { 774 HandshakeType msg_type; 775 uint24 length; 776 uint16 message_seq; // New field 777 uint24 fragment_offset; // New field 778 uint24 fragment_length; // New field 779 select (HandshakeType) { 780 case hello_request: HelloRequest; 781 case client_hello: ClientHello; 782 case hello_verify_request: HelloVerifyRequest; // New type 783 case server_hello: ServerHello; 784 case certificate:Certificate; 785 case server_key_exchange: ServerKeyExchange; 786 case certificate_request: CertificateRequest; 787 case server_hello_done:ServerHelloDone; 788 case certificate_verify: CertificateVerify; 789 case client_key_exchange: ClientKeyExchange; 790 case finished: Finished; 791 } body; 792 } Handshake; 794 The first message each side transmits in each handshake always has 795 message_seq = 0. Whenever each new message is generated, the 796 message_seq value is incremented by one. When a message is 797 retransmitted, the same message_seq value is used. For example: 799 Client Server 800 ------ ------ 801 ClientHello (seq=0) ------> 803 X<-- HelloVerifyRequest (seq=0) 804 (lost) 806 [Timer Expires] 808 ClientHello (seq=0) ------> 809 (retransmit) 811 <------ HelloVerifyRequest (seq=0) 813 ClientHello (seq=1) ------> 814 (with cookie) 816 <------ ServerHello (seq=1) 817 <------ Certificate (seq=2) 818 <------ ServerHelloDone (seq=3) 820 [Rest of handshake] 822 Note, however, that from the perspective of the DTLS record layer, 823 the retransmission is a new record. This record will have a new 824 DTLSPlaintext.sequence_number value. 826 DTLS implementations maintain (at least notionally) a 827 next_receive_seq counter. This counter is initially set to zero. 828 When a message is received, if its sequence number matches 829 next_receive_seq, next_receive_seq is incremented and the message is 830 processed. If the sequence number is less than next_receive_seq, the 831 message MUST be discarded. If the sequence number is greater than 832 next_receive_seq, the implementation SHOULD queue the message but MAY 833 discard it. (This is a simple space/bandwidth tradeoff). 835 4.2.3. Message Fragmentation and Reassembly 837 As noted in Section 4.1.1, each DTLS message MUST fit within a single 838 transport layer datagram. However, handshake messages are 839 potentially bigger than the maximum record size. Therefore, DTLS 840 provides a mechanism for fragmenting a handshake message over a 841 number of records. 843 When transmitting the handshake message, the sender divides the 844 message into a series of N contiguous data ranges. These ranges MUST 845 NOT be larger than the maximum handshake fragment size and MUST 846 jointly contain the entire handshake message. The ranges SHOULD NOT 847 overlap. The sender then creates N handshake messages, all with the 848 same message_seq value as the original handshake message. Each new 849 message is labelled with the fragment_offset (the number of bytes 850 contained in previous fragments) and the fragment_length (the length 851 of this fragment). The length field in all messages is the same as 852 the length field of the original message. An unfragmented message is 853 a degenerate case with fragment_offset=0 and fragment_length=length. 855 When a DTLS implementation receives a handshake message fragment, it 856 MUST buffer it until it has the entire handshake message. DTLS 857 implementations MUST be able to handle overlapping fragment ranges. 858 This allows senders to retransmit handshake messages with smaller 859 fragment sizes if the PMTU estimate changes. 861 Note that as with TLS, multiple handshake messages may be placed in 862 the same DTLS record, provided that there is room and that they are 863 part of the same flight. Thus, there are two acceptable ways to pack 864 two DTLS messages into the same datagram: in the same record or in 865 separate records. 867 4.2.4. Timeout and Retransmission 869 DTLS messages are grouped into a series of message flights, according 870 to the diagrams below. Although each flight of messages may consist 871 of a number of messages, they should be viewed as monolithic for the 872 purpose of timeout and retransmission. 874 Client Server 875 ------ ------ 877 ClientHello --------> Flight 1 879 <------- HelloVerifyRequest Flight 2 881 ClientHello --------> Flight 3 883 ServerHello \ 884 Certificate* \ 885 ServerKeyExchange* Flight 4 886 CertificateRequest* / 887 <-------- ServerHelloDone / 889 Certificate* \ 890 ClientKeyExchange \ 891 CertificateVerify* Flight 5 892 [ChangeCipherSpec] / 893 Finished --------> / 895 [ChangeCipherSpec] \ Flight 6 896 <-------- Finished / 898 Figure 1. Message flights for full handshake 900 Client Server 901 ------ ------ 903 ClientHello --------> Flight 1 905 ServerHello \ 906 [ChangeCipherSpec] Flight 2 907 <-------- Finished / 909 [ChangeCipherSpec] \Flight 3 910 Finished --------> / 912 Figure 2. Message flights for session-resuming handshake 913 (no cookie exchange) 915 DTLS uses a simple timeout and retransmission scheme with the 916 following state machine. Because DTLS clients send the first message 917 (ClientHello), they start in the PREPARING state. DTLS servers start 918 in the WAITING state, but with empty buffers and no retransmit timer. 920 +-----------+ 921 | PREPARING | 922 +---> | | <--------------------+ 923 | | | | 924 | +-----------+ | 925 | | | 926 | | | 927 | | Buffer next flight | 928 | | | 929 | \|/ | 930 | +-----------+ | 931 | | | | 932 | | SENDING |<------------------+ | 933 | | | | | Send 934 | +-----------+ | | HelloRequest 935 Receive | | | | 936 next | | Send flight | | or 937 flight | +--------+ | | 938 | | | Set retransmit timer | | Receive 939 | | \|/ | | HelloRequest 940 | | +-----------+ | | Send 941 | | | | | | ClientHello 942 +--)--| WAITING |-------------------+ | 943 | | | | Timer expires | | 944 | | +-----------+ | | 945 | | | | | 946 | | | | | 947 | | +------------------------+ | 948 | | Read retransmit | 949 Receive | | | 950 last | | | 951 flight | | | 952 | | | 953 \|/\|/ | 954 | 955 +-----------+ | 956 | | | 957 | FINISHED | -------------------------------+ 958 | | 959 +-----------+ 960 | /|\ 961 | | 962 | | 963 +---+ 965 Read retransmit 966 Retransmit last flight 967 Figure 3. DTLS timeout and retransmission state machine 969 The state machine has three basic states. 971 In the PREPARING state the implementation does whatever computations 972 are necessary to prepare the next flight of messages. It then 973 buffers them up for transmission (emptying the buffer first) and 974 enters the SENDING state. 976 In the SENDING state, the implementation transmits the buffered 977 flight of messages. Once the messages have been sent, the 978 implementation then enters the FINISHED state if this is the last 979 flight in the handshake. Or, if the implementation expects to 980 receive more messages, it sets a retransmit timer and then enters the 981 WAITING state. 983 There are three ways to exit the WAITING state: 985 1. The retransmit timer expires: the implementation transitions to 986 the SENDING state, where it retransmits the flight, resets the 987 retransmit timer, and returns to the WAITING state. 989 2. The implementation reads a retransmitted flight from the peer: 990 the implementation transitions to the SENDING state, where it 991 retransmits the flight, resets the retransmit timer, and returns 992 to the WAITING state. The rationale here is that the receipt of a 993 duplicate message is the likely result of timer expiry on the peer 994 and therefore suggests that part of one's previous flight was 995 lost. 997 3. The implementation receives the next flight of messages: if 998 this is the final flight of messages, the implementation 999 transitions to FINISHED. If the implementation needs to send a 1000 new flight, it transitions to the PREPARING state. Partial reads 1001 (whether partial messages or only some of the messages in the 1002 flight) do not cause state transitions or timer resets. 1004 Because DTLS clients send the first message (ClientHello), they start 1005 in the PREPARING state. DTLS servers start in the WAITING state, but 1006 with empty buffers and no retransmit timer. 1008 When the server desires a rehandshake, it transitions from the 1009 FINISHED state to the PREPARING state to transmit the HelloRequest. 1010 When the client receives a HelloRequest it transitions from FINISHED 1011 to PREPARING to transmit the ClientHello. In addition, for at least 1012 2MSL, when in the FINISHED state, the node which transmits the last 1013 flight (the server in an ordinary handshake or the client in a 1014 resumed handshake) MUST respond to a retransmit of the peer's last 1015 flight with a retransmit of the last flight. This avoids deadlock 1016 conditions if the last flight gets lost. This requirement applies to 1017 DTLS 1.0 as well, and though not explicit in [DTLS1] but was always 1018 required for the state machine to function correctly. 1020 4.2.4.1. Timer Values 1022 Though timer values are the choice of the implementation, mishandling 1023 of the timer can lead to serious congestion problems; for example, if 1024 many instances of a DTLS time out early and retransmit too quickly on 1025 a congested link. Implementations SHOULD use an initial timer value 1026 of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double 1027 the value at each retransmission, up to no less than the RFC 2988 1028 maximum of 60 seconds. Note that we recommend a 1-second timer 1029 rather than the 3-second RFC 2988 default in order to improve latency 1030 for time-sensitive applications. Because DTLS only uses 1031 retransmission for handshake and not dataflow, the effect on 1032 congestion should be minimal. 1034 Implementations SHOULD retain the current timer value until a 1035 transmission without loss occurs, at which time the value may be 1036 reset to the initial value. After a long period of idleness, no less 1037 than 10 times the current timer value, implementations may reset the 1038 timer to the initial value. One situation where this might occur is 1039 when a rehandshake is used after substantial data transfer. 1041 4.2.5. ChangeCipherSpec 1043 As with TLS, the ChangeCipherSpec message is not technically a 1044 handshake message but MUST be treated as part of the same flight as 1045 the associated Finished message for the purposes of timeout and 1046 retransmission. 1048 4.2.6. CertificateVerify and Finished Messages 1050 CertificateVerify and Finished messages have the same format as in 1051 TLS. Hash calculations include entire handshake messages, including 1052 DTLS specific fields: message_seq, fragment_offset and 1053 fragment_length. However, in order to remove sensitivity to 1054 fragmentation, the Finished MAC MUST be computed as if each handshake 1055 message had been sent as a single fragment. Note that in cases where 1056 the cookie exchange is used, the initial ClientHello and 1057 HelloVerifyRequest MUST NOT be included in the CertificateVerify or 1058 Finished MAC computations. 1060 4.2.7. Alert Messages 1061 Note that Alert messages are not retransmitted at all, even when they 1062 occur in the context of a handshake. However, a DTLS implementation 1063 SHOULD generate a new alert message if the offending record is 1064 received again (e.g., as a retransmitted handshake message). 1065 Implementations SHOULD detect when a peer is persistently sending bad 1066 messages and terminate the local connection state after such 1067 misbehavior is detected. 1069 4.3. Summary of new syntax 1071 This section includes specifications for the data structures that 1072 have changed between TLS 1.2 and DTLS. 1074 4.3.1. Record Layer 1076 struct { 1077 ContentType type; 1078 ProtocolVersion version; 1079 uint16 epoch; // New field 1080 uint48 sequence_number; // New field 1081 uint16 length; 1082 opaque fragment[DTLSPlaintext.length]; 1083 } DTLSPlaintext; 1085 struct { 1086 ContentType type; 1087 ProtocolVersion version; 1088 uint16 epoch; // New field 1089 uint48 sequence_number; // New field 1090 uint16 length; 1091 opaque fragment[DTLSCompressed.length]; 1092 } DTLSCompressed; 1094 struct { 1095 ContentType type; 1096 ProtocolVersion version; 1097 uint16 epoch; // New field 1098 uint48 sequence_number; // New field 1099 uint16 length; 1100 select (CipherSpec.cipher_type) { 1101 case block: GenericBlockCipher; 1102 case aead: GenericAEADCipher; // New field 1103 } fragment; 1104 } DTLSCiphertext; 1106 4.3.2. Handshake Protocol 1108 enum { 1109 hello_request(0), client_hello(1), server_hello(2), 1110 hello_verify_request(3), // New field 1111 certificate(11), server_key_exchange (12), 1112 certificate_request(13), server_hello_done(14), 1113 certificate_verify(15), client_key_exchange(16), 1114 finished(20), (255) 1115 } HandshakeType; 1117 struct { 1118 HandshakeType msg_type; 1119 uint24 length; 1120 uint16 message_seq; // New field 1121 uint24 fragment_offset; // New field 1122 uint24 fragment_length; // New field 1123 select (HandshakeType) { 1124 case hello_request: HelloRequest; 1125 case client_hello: ClientHello; 1126 case server_hello: ServerHello; 1127 case hello_verify_request: HelloVerifyRequest; // New field 1128 case certificate:Certificate; 1129 case server_key_exchange: ServerKeyExchange; 1130 case certificate_request: CertificateRequest; 1131 case server_hello_done:ServerHelloDone; 1132 case certificate_verify: CertificateVerify; 1133 case client_key_exchange: ClientKeyExchange; 1134 case finished: Finished; 1135 } body; 1136 } Handshake; 1138 struct { 1139 ProtocolVersion client_version; 1140 Random random; 1141 SessionID session_id; 1142 opaque cookie<0..2^8-1>; // New field 1143 CipherSuite cipher_suites<2..2^16-1>; 1144 CompressionMethod compression_methods<1..2^8-1>; 1145 } ClientHello; 1147 struct { 1148 ProtocolVersion server_version; 1149 opaque cookie<0..2^8-1>; 1150 } HelloVerifyRequest; 1152 5. Security Considerations 1154 This document describes a variant of TLS 1.2 and therefore most of 1155 the security considerations are the same as those of TLS 1.2 [TLS12], 1156 described in Appendices D, E, and F. 1158 The primary additional security consideration raised by DTLS is that 1159 of denial of service. DTLS includes a cookie exchange designed to 1160 protect against denial of service. However, implementations which do 1161 not use this cookie exchange are still vulnerable to DoS. In 1162 particular, DTLS servers which do not use the cookie exchange may be 1163 used as attack amplifiers even if they themselves are not 1164 experiencing DoS. Therefore, DTLS servers SHOULD use the cookie 1165 exchange unless there is good reason to believe that amplification is 1166 not a threat in their environment. Clients MUST be prepared to do a 1167 cookie exchange with every handshake. 1169 6. Acknowledgements 1171 The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley, 1172 Constantine Sapuntzakis, and Hovav Shacham for discussions and 1173 comments on the design of DTLS. Thanks to the anonymous NDSS 1174 reviewers of our original NDSS paper on DTLS [DTLS] for their 1175 comments. Also, thanks to Steve Kent for feedback that helped 1176 clarify many points. The section on PMTU was cribbed from the DCCP 1177 specification [DCCP]. Pasi Eronen provided a detailed review of this 1178 specification. Helpful comments on the document were also received 1179 from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Joel 1180 Halpern, Ted Hardie, Allison Mankin, Robin Seggelman and Michael 1181 Tuexen. 1183 7. IANA Considerations 1185 This document uses the same identifier space as TLS [TLS12], so no 1186 new IANA registries are required. When new identifiers are assigned 1187 for TLS, authors MUST specify whether they are suitable for DTLS. 1189 This document defines a new handshake message, hello_verify_request, 1190 whose value has been allocated from the TLS HandshakeType registry 1191 defined in [TLS12]. The value "3" has been assigned by the IANA. 1193 8. References 1195 8.1. Normative References 1197 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1198 November 1990. 1200 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1201 Internet Protocol", RFC 4301, December 2005. 1203 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 1204 Timer", RFC 2988, November 2000. 1206 [RFC4821] Mathis, M., and J. Heffner, "Packetization Layer Path MTU 1207 Discovery", RFC 4821, March 2007. 1209 [RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher 1210 Suites for TLS", RFC 5288, August 2008. 1212 [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 1213 793, September 1981. 1215 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 1216 (TLS) Protocol Version 1.2", RFC 5246, May 2008. 1218 8.2. Informative References 1220 [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram 1221 Congestion Control Protocol", Work in Progress, 10 March 1222 2005. 1224 [DCCPDTLS] T. Phelan, "Datagram Transport Layer Security (DTLS) over 1225 the Datagram Congestion Control Protocol (DCCP)", RFC 1226 5238, May 2008. 1228 [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation 1229 of Datagram TLS", Proceedings of ISOC NDSS 2004, February 1230 2004. 1232 [DTLS1] Rescorla, E., and N. Modadugu, "Datagram Transport Layer 1233 Security", RFC 4347, April 2006. 1235 [ECCGCM] E. Rescorla, "TLS Elliptic Curve Cipher Suites with 1236 SHA-256/384 and AES Galois Counter Mode", RFC 5289, August 1237 2008. 1239 [ESP] S. Kent "IP Encapsulating Security Payload (ESP)", RFC 1240 4303, December 2005. 1242 [IKEv2] C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol", 1243 RFC 4306, December 2005. 1245 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 1246 December 2005. 1248 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1249 4rev1", RFC 3501, March 2003. 1251 [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management 1252 Protocol", RFC 2522, March 1999. 1254 [POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1255 STD 53, RFC 1939, May 1996. 1257 [REQ] Bradner, S., "Key words for use in RFCs to Indicate 1258 Requirement Levels", BCP 14, RFC 2119, March 1997. 1260 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1261 A., Peterson, J., Sparks, R., Handley, M., and E. 1262 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1263 June 2002. 1265 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1266 RFC 2246, January 1999. 1268 [TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security 1269 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1271 [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", 1272 Work in Progress, October 2003. 1274 Authors' Addresses 1276 Eric Rescorla 1277 RTFM, Inc. 1278 2064 Edgewood Drive 1279 Palo Alto, CA 94303 1281 EMail: ekr@rtfm.com 1283 Nagendra Modadugu 1284 Computer Science Department 1285 Stanford University 1286 353 Serra Mall 1287 Stanford, CA 94305 1289 EMail: nagendra@cs.stanford.edu