RFC 6347
Datagram Transport Layer Security Version 1.2
Datagram Transport Layer Security Version 1.2 🎀
- RFC: 6347 🦋
- Authors: E. Rescorla (RTFM, Inc.) and N. Modadugu (Google, Inc.) 💅
- Category: Standards Track ✨
- Date: January 2012 🌸
- Obsoletes: 4347 💀
- Updates: DTLS 1.0, to work with TLS version 1.2 (see the Abstract) 🔥
- ISSN: 2070-1721
- Publisher: Internet Engineering Task Force (IETF) 👑
Abstract
okay so this doc specs DTLS version 1.2 🎀 DTLS gives datagram protocols communications privacy. Client/server apps can talk in a way that's built to stop eavesdropping, tampering, and message forgery 🔒 It's based on TLS and gives you equivalent security guarantees, no cap 💖 The datagram semantics of the underlying transport are still preserved, which is so important 🦋 And yeah, this document updates DTLS 1.0 to work with TLS version 1.2 ✨
Status of This Memo
This is an Internet Standards Track document. 👑
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 📚
Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6347 🌈
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🩷
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please review these docs carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 💜
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🙈
Table of Contents 🧚
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
2. Usage Model .....................................................5
3. Overview of DTLS ................................................5
3.1. Loss-Insensitive Messaging .................................6
3.2. Providing Reliability for Handshake ........................6
3.2.1. Packet Loss .........................................6
3.2.2. Reordering ..........................................7
3.2.3. Message Size ........................................7
3.3. Replay Detection ...........................................7
4. Differences from TLS ............................................7
4.1. Record Layer ...............................................8
4.1.1. Transport Layer Mapping ............................10
4.1.1.1. PMTU Issues ...............................10
4.1.2. Record Payload Protection ..........................12
4.1.2.1. MAC .......................................12
4.1.2.2. Null or Standard Stream Cipher ............13
4.1.2.3. Block Cipher ..............................13
4.1.2.4. AEAD Ciphers ..............................13
4.1.2.5. New Cipher Suites .........................13
4.1.2.6. Anti-Replay ...............................13
4.1.2.7. Handling Invalid Records ..................14
4.2. The DTLS Handshake Protocol ...............................14
4.2.1. Denial-of-Service Countermeasures ..................15
4.2.2. Handshake Message Format ...........................18
4.2.3. Handshake Message Fragmentation and Reassembly .....19
4.2.4. Timeout and Retransmission .........................20
4.2.4.1. Timer Values ..............................24
4.2.5. ChangeCipherSpec ...................................25
4.2.6. CertificateVerify and Finished Messages ............25
4.2.7. Alert Messages .....................................25
4.2.8. Establishing New Associations with Existing
Parameters .........................................25
4.3. Summary of New Syntax .....................................26
4.3.1. Record Layer .......................................26
4.3.2. Handshake Protocol .................................27
5. Security Considerations ........................................27
6. Acknowledgments ................................................28
7. IANA Considerations ............................................28
8. Changes since DTLS 1.0 .........................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................311. Introduction ✨
okay so TLS [TLS] is the most widely deployed protocol for securing network traffic, and it's literally everywhere 🌍 It's used for Web traffic and for e-mail protocols like IMAP [IMAP] and POP [POP] 💌 The big perk of TLS is that it gives you a transparent connection-oriented channel, so it's easy to secure an app protocol by sliding TLS in between the application layer and the transport layer 🧁 The catch is that TLS must run over a reliable transport channel -- typically TCP [TCP] -- so it can't be used to secure unreliable datagram traffic 😭
More and more application layer protocols use UDP transport now. Protocols like the Session Initiation Protocol (SIP) [SIP] and electronic gaming protocols are getting super popular 🎮 (Fun fact: SIP can run over both TCP and UDP, but there are situations where UDP is preferable.) Right now, designers of these apps are stuck with a bunch of unsatisfactory choices 🙃 First, they can use IPsec [RFC4301]. But for a number of reasons detailed in [WHYIPSEC], that's only suitable for some apps. Second, they can design a custom application layer security protocol. Unfortunately, even though app layer security protocols generally have superior security properties (e.g., end-to-end security in the case of S/MIME), they usually take a huge amount of effort to design -- compared to the relatively small effort it takes to run a protocol over TLS 🥲
In lots of cases, the most desirable way to secure client/server apps would be to use TLS. But the requirement for datagram semantics automatically prohibits TLS 🚫 So this memo describes a protocol for exactly this purpose: Datagram Transport Layer Security (DTLS) 🦋 DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse. Main character energy for code reuse, honestly 💅
DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This document introduces a new version of DTLS, DTLS 1.2, which is defined as a series of deltas to TLS 1.2 [TLS12]. There is no DTLS 1.1 -- that version number got skipped so the numbers would line up with TLS 🫶 This version also clarifies some confusing points in the DTLS 1.0 spec 💡
Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS 1.0, of course). Same goes for TLS 1.2 implementations interoperating with previous versions of TLS (see Appendix E.1 of [TLS12] for details). The one exception is that there's no DTLS version of SSLv2 or SSLv3, so backward compatibility issues for those protocols don't apply 🌸
1.1. Requirements Terminology
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 RFC 2119 [REQ]. 📖
2. Usage Model 🧚
The DTLS protocol is designed to secure data between communicating applications. It's built to run in application space, without requiring any kernel modifications ✨
Datagram transport doesn't require or provide reliable or in-order delivery of data, and DTLS keeps that property for payload data 🌊 Apps like media streaming, Internet telephony, and online gaming use datagram transport because their data is delay-sensitive 🎮 Their behavior doesn't change when DTLS is used to secure the communication, since DTLS doesn't compensate for lost or re-ordered data traffic. It's giving honest, unbothered energy 💅
3. Overview of DTLS 🌈
The basic design philosophy of DTLS is to construct "TLS over datagram transport" 🦋 The reason TLS can't be used directly in datagram environments is simply that packets may be lost or reordered. TLS has no internal facilities to handle that kind of unreliability, so TLS implementations break when rehosted on datagram transport 😵 The whole point of DTLS is to make only the minimal changes to TLS required to fix this problem. To the greatest extent possible, DTLS is identical to TLS. And whenever we need to invent new mechanisms, we try to do it in a way that keeps the style of TLS 💖
Unreliability causes problems for TLS at two levels:
- TLS doesn't allow independent decryption of individual records. Because the integrity check depends on the sequence number, if record N isn't received, then the integrity check on record N+1 will be based on the wrong sequence number and will therefore fail. (Note that before TLS 1.1 there was no explicit IV, so decryption would also fail. 🙈)
- The TLS handshake layer assumes handshake messages are delivered reliably, and it breaks if those messages get lost 💀
The rest of this section describes how DTLS solves these problems 🛠️
3.1. Loss-Insensitive Messaging 🫧
In TLS's traffic encryption layer (called the TLS Record Layer), records are not independent. There are two kinds of inter-record dependency:
- Cryptographic context (stream cipher key stream) is retained between records.
- Anti-replay and message reordering protection are provided by a MAC that includes a sequence number, but the sequence numbers are implicit in the records.
DTLS solves the first problem by banning stream ciphers 🚫 And DTLS solves the second problem by adding explicit sequence numbers 🔢 Iconic fix, honestly 👑
3.2. Providing Reliability for Handshake ✨
Okay bestie, the TLS handshake is a super strict lockstep dance 💃. Messages must be transmitted and received in a defined order, and any other order is an error 🙅♀️. Obviously that is not compatible with reordering and message loss 😭. On top of that, TLS handshake messages can be bigger than a single datagram, which creates the IP fragmentation problem 💀. So DTLS has to fix BOTH of these things 💅.
3.2.1. Packet Loss 📦
DTLS uses a simple retransmission timer to handle packet loss. Here's the basic concept, using the first phase of the DTLS handshake 👀:
Client Server
------ ------
ClientHello ------>
X<-- HelloVerifyRequest
(lost)
[Timer Expires]
ClientHello ------>
(retransmit)Once the client has sent the ClientHello, it expects to see a HelloVerifyRequest from the server. But if the server's message gets lost, the client knows that either the ClientHello or the HelloVerifyRequest went missing, so it retransmits 🔁. When the server gets that retransmission, it knows to retransmit too 🫶.
The server also has its own retransmission timer, and it retransmits when that timer expires ⏰.
Note that timeout and retransmission do NOT apply to the HelloVerifyRequest, because that would mean creating state on the server 🙈. The HelloVerifyRequest is designed to be small enough that it won't get fragmented itself, which avoids the mess of interleaving multiple HelloVerifyRequests 🧚.
3.2.2. Reordering 🔀
In DTLS, every handshake message gets a specific sequence number within that handshake. When a peer receives a handshake message, it can quickly figure out whether that message is the next one it expects 👀. If it is, then it processes it ✅. If it isn't, it queues the message for later handling, once all the previous messages have been received 📥.
3.2.3. Message Size 📏
TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes) 😳. By contrast, UDP datagrams are often limited to <1500 bytes if IP fragmentation isn't desired 🧃. To compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records, and each of those records is intended to fit in a single IP datagram 🧩. Each DTLS handshake message contains both a fragment offset and a fragment length. So a recipient that has all the bytes of a handshake message can reassemble the original unfragmented message 🎀.
3.3. Replay Detection 🔁
DTLS optionally supports record replay detection 🛡️. The technique is the same one used in IPsec AH/ESP: it maintains a bitmap window of received records. Records that are too old to fit in the window, and records that have already been received, get silently discarded 🤫. Replay detection is optional, since packet duplication isn't always malicious. It can also happen because of routing errors 🗺️. Applications may conceivably detect duplicate packets and adjust their data transmission strategy accordingly 💖.
4. Differences from TLS 🌸
As mentioned in Section 3, DTLS is intentionally very similar to TLS 👯♀️. So instead of presenting DTLS as a brand-new protocol, we present it as a series of deltas from TLS 1.2 [TLS12]. Where we don't explicitly call out differences, DTLS is the same as in [TLS12] ✨.
4.1. Record Layer 🍰
The DTLS record layer is extremely similar to TLS 1.2, and honestly it's giving déjà vu 😭. The only change is the inclusion of an explicit sequence number in the record. This sequence number lets the recipient correctly verify the TLS MAC 🔐. The DTLS record format looks like this:
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;Here's what each field does 👇
type is equivalent to the type field in a TLS 1.2 record 📝.
version is the version of the protocol being used 🏷️. This document describes DTLS version 1.2, which uses the version { 254, 253 }. The version value 254.253 is the 1's complement of DTLS version 1.2. This maximal spacing between the TLS and DTLS version numbers makes sure records from the two protocols can be easily told apart 🙌. Also, it's worth noting that future on-the-wire version numbers of DTLS are decreasing in value, while the true version number is increasing in value 🤯.
epoch is a counter value that gets incremented on every cipher state change 🔢.
sequence_number is the sequence number for this record 🔖.
length is identical to the length field in a TLS 1.2 record. As in TLS 1.2, the length should not exceed 2^14 📐.
fragment is identical to the fragment field of a TLS 1.2 record 🧁.
DTLS uses an explicit sequence number instead of an implicit one, carried in the sequence_number field of the record. Sequence numbers are maintained separately for each epoch, with each sequence_number initially being 0 for each epoch 🧮. For instance, if a handshake message from epoch 0 gets retransmitted, it might have a sequence number after a message from epoch 1, even if the epoch 1 message was sent first 🤪. Note that some care needs to be taken during the handshake to make sure retransmitted messages use the right epoch and keying material 🔑.
If several handshakes happen in close succession, there might be multiple records on the wire with the same sequence number but from different cipher states 🌀. The epoch field lets recipients tell those packets apart 🕵️♀️. The epoch number starts at zero and is incremented each time a ChangeCipherSpec message is sent. To make sure any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime ⏳. In practice, TLS implementations rarely rehandshake, so we don't expect this to be a problem 🥰.
Note that because DTLS records may be reordered, a record from epoch 1 might be received after epoch 2 has begun 😵💫. In general, implementations SHOULD discard packets from earlier epochs. But if packet loss causes noticeable problems, they MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP [TCP], to allow for packet reordering 🫠. (Note that the intention here is that implementors use the current guidance from the IETF for MSL, NOT that they try to interrogate the MSL that the system TCP stack is using 🙅♀️.) Until the handshake has completed, implementations MUST accept packets from the old epoch 🙏.
Conversely, it's possible for records protected by the newly negotiated context to be received before the handshake completes 🏃♀️. For instance, the server may send its Finished message and then start transmitting data. Implementations MAY either buffer or discard such packets. However, when DTLS is used over reliable transports (e.g., SCTP), they SHOULD be buffered and processed once the handshake completes 📦. Note that TLS's restrictions on when packets may be sent still apply, and the receiver treats the packets as if they were sent in the right order 🧠. In particular, it is still impermissible to send data prior to completion of the first handshake 🚫.
Note that in the special case of a rehandshake on an existing association, it is safe to process a data packet immediately, even if the ChangeCipherSpec or Finished messages haven't been received yet. This is only true provided that either the rehandshake resumes the existing session, or it uses exactly the same security parameters as the existing association 🔐. In any other case, the implementation MUST wait for the receipt of the Finished message to prevent a downgrade attack 🚨. Let's be careful out here, babe 😤.
As in TLS, implementations MUST either abandon an association or rehandshake prior to allowing the sequence number to wrap 🔄.
Similarly, implementations MUST NOT allow the epoch to wrap. Instead, they MUST establish a new association, terminating the old association as described in Section 4.2.8 🌅. In practice, implementations rarely rehandshake repeatedly on the same channel, so this is not likely to be an issue 💤.
4.1.1. Transport Layer Mapping 🚚
Each DTLS record MUST fit within a single datagram 📨. To avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer 🎯.
Note that unlike IPsec, DTLS records don't contain any association identifiers 🙃. So applications must arrange to multiplex between associations. With UDP, this is presumably done with the host/port number 🔌.
Multiple DTLS records can be placed in a single datagram 🗂️. They're simply encoded consecutively, and the DTLS record framing is sufficient to determine the boundaries 📏. Note, however, that the first byte of the datagram payload must be the beginning of a record. Records may NOT span datagrams 🚫.
Some transports, such as DCCP [DCCP], provide their own sequence numbers 🔢. When carried over those transports, both the DTLS and the transport sequence numbers will be present 👯. Although this introduces a small amount of inefficiency, the transport layer and DTLS sequence numbers serve different purposes. So for conceptual simplicity, it is superior to use both sequence numbers 🧘♀️. In the future, extensions to DTLS may be specified that allow the use of only one set of sequence numbers for deployment in constrained environments 🔮.
Some transports, such as DCCP, provide congestion control for the traffic carried over them 🚦. If the congestion window is sufficiently narrow, DTLS handshake retransmissions may be held rather than transmitted immediately, which can potentially lead to timeouts and spurious retransmission 😬. When DTLS is used over such transports, care should be taken not to overrun the likely congestion window 🫧. [DCCPDTLS] defines a mapping of DTLS to DCCP that takes these issues into account 💜.
4.1.1.1. PMTU Issues ✨
Okay so, DTLS's whole philosophy is to leave PMTU (path MTU) discovery to the app 💅 But DTLS can't completely ignore PMTU, bestie, and there are three reasons why:
- The DTLS record framing makes the datagram bigger, so the effective PMTU from the app's point of view gets lower 📉
- In some implementations, the app doesn't talk to the network directly, so the DTLS stack might absorb ICMP [RFC1191] "Datagram Too Big" or ICMPv6 [RFC4443] "Packet Too Big" indications 🙈
- DTLS handshake messages can be bigger than the PMTU 😭
To deal with the first two, the DTLS record layer SHOULD behave like this:
If PMTU estimates are available from the underlying transport protocol, they should be made available to upper layer protocols. Specifically:
- For DTLS over UDP, the upper layer protocol SHOULD be allowed to get the PMTU estimate kept in the IP layer 🌸
- For DTLS over DCCP, the upper layer protocol SHOULD be allowed to get the current PMTU estimate 🦋
- For DTLS over TCP or SCTP, which automatically fragment and reassemble datagrams, there's no PMTU limitation, bestie 🫶 Still, the upper layer protocol MUST NOT write any record bigger than the maximum record size of
2^14bytes.
The DTLS record layer SHOULD let the upper layer protocol find out how much record expansion DTLS processing is expected to add. Heads up, though: this number is only an estimate, because of block padding and the potential use of DTLS compression 🎀
If the transport protocol sends an indication (either through ICMP or by refusing to send the datagram, as in Section 14 of [DCCP]), then the DTLS record layer MUST tell the upper layer protocol about the error 🚨
The DTLS record layer SHOULD NOT interfere with upper layer protocols doing PMTU discovery, whether they use the [RFC1191] or [RFC4821] mechanisms. Specifically:
- Where the underlying transport protocol allows it, the upper layer protocol SHOULD be allowed to set the DF bit (in IPv4) or prohibit local fragmentation (in IPv6) 💖
- If the underlying transport protocol lets the app request PMTU probing (e.g., DCCP), the DTLS record layer should honor that request ✨
The final issue is the DTLS handshake protocol. From the DTLS record layer's point of view, it's just another upper layer protocol. BUT, DTLS handshakes happen infrequently and only involve a few round trips, so the handshake's PMTU handling puts a premium on finishing fast over getting an accurate PMTU discovery 🏃♀️ To allow connections in these situations, DTLS implementations SHOULD follow these rules:
- If the DTLS record layer tells the DTLS handshake layer that a message is too big, it SHOULD immediately try to fragment it, using any existing PMTU information 🧩
- If repeated retransmissions don't get a response and the PMTU is unknown, later retransmissions SHOULD back off to a smaller record size, fragmenting the handshake message as needed. This standard doesn't specify an exact number of retransmits to try before backing off, but 2-3 seems appropriate 🌈
4.1.2. Record Payload Protection 🔐
Like TLS, DTLS sends data as a series of protected records. The rest of this section breaks down the details of that format 💜
4.1.2.1. MAC 🧁
The DTLS MAC is the same as TLS 1.2's. But instead of using TLS's implicit sequence number, the sequence number used to compute the MAC is the 64-bit value you get by concatenating the epoch and the sequence number, in the order they appear on the wire. Fun fact: the DTLS epoch + sequence number is the same length as the TLS sequence number 🤓
TLS's MAC calculation depends on the protocol version number. In DTLS, that's the on-the-wire version, i.e., {254, 253} for DTLS 1.2.
Here's one important difference between DTLS and TLS MAC handling: in TLS, MAC errors MUST result in connection termination. In DTLS, the receiving implementation MAY simply discard the offending record and keep going with the connection 🙌 This is possible because DTLS records don't depend on each other the way TLS records do.
In general, DTLS implementations SHOULD silently discard records with bad MACs or that are otherwise invalid. They MAY log an error. If a DTLS implementation chooses to send an alert when it gets a message with an invalid MAC, it MUST generate a bad_record_mac alert with level fatal and terminate its connection state.
Careful, bestie 🙈 Because errors don't cause connection termination, DTLS stacks are more efficient error type oracles than TLS stacks. So it's especially important that the advice in Section 6.2.3.2 of [TLS12] gets followed!
4.1.2.2. Null or Standard Stream Cipher 🌊
The DTLS NULL cipher works exactly like the TLS 1.2 NULL cipher.
The only stream cipher described in TLS 1.2 is RC4, which can't be randomly accessed. So RC4 MUST NOT be used with DTLS 🚫
4.1.2.3. Block Cipher 🧱
DTLS block cipher encryption and decryption work exactly like they do in TLS 1.2 ✨
4.1.2.4. AEAD Ciphers 🔑
TLS 1.2 brought in authenticated encryption with additional data (AEAD) cipher suites. The existing AEAD cipher suites, defined in [ECCGCM] and [RSAGCM], can be used with DTLS exactly like they're used with TLS 1.2 💅
4.1.2.5. New Cipher Suites 🆕
When new TLS cipher suites get registered, they MUST indicate whether they're suitable for DTLS usage, and what adaptations (if any) must be made (see Section 7 for IANA considerations) 📋
4.1.2.6. Anti-Replay 🛡️
DTLS records contain a sequence number to provide replay protection. Sequence number verification SHOULD be done with the following sliding window procedure, borrowed from Section 3.4.3 of [ESP] 🪟
The receiver packet counter for a session MUST be initialized to zero when the session is established. For each received record, the receiver MUST verify that the record has a sequence number that doesn't duplicate the sequence number of any other record received during the life of this session. This SHOULD be the first check applied to a packet after it's been matched to a session, so duplicate records get rejected faster 🏎️
Duplicates get rejected using a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A minimum window size of 32 MUST be supported, but a window size of 64 is preferred and SHOULD be used as the default. The receiver MAY choose another window size (larger than the minimum). (The receiver doesn't tell the sender what window size it's using.) 🤫
The "right" edge of the window is the highest validated sequence number received on this session. Records with sequence numbers lower than the "left" edge of the window are rejected. Packets that fall within the window are checked against a list of received packets within the window. An efficient way to do this check, based on a bit mask, is described in Section 3.4.3 of [ESP] 🎭
If the received record falls within the window and is new, or if the packet is to the right of the window, then the receiver goes on to MAC verification. If MAC validation fails, the receiver MUST discard the received record as invalid. The receive window is only updated if MAC verification succeeds 🔥
4.1.2.7. Handling Invalid Records 🙅♀️
Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.) 💪 In general, invalid records SHOULD be silently discarded, which preserves the association. An error MAY be logged for diagnostic purposes. Implementations that choose to generate an alert instead MUST generate fatal level alerts, to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error.
Serious moment, bestie 😭 If DTLS runs over UDP, then any implementation that does this will be extremely susceptible to denial-of-service (DoS) attacks, because UDP forgery is so easy. So this practice is NOT RECOMMENDED for such transports. ⚠️
If DTLS is carried over a transport that resists forgery (e.g., SCTP with SCTP-AUTH), then it's safer to send alerts, because an attacker will have a hard time forging a datagram that the transport layer won't reject 🛡️
4.2. The DTLS Handshake Protocol 🤝
DTLS uses all of the same handshake messages and flows as TLS, with three principal changes:
- A stateless cookie exchange has been added to prevent denial-of-service attacks. 🍪
- Modifications to the handshake header to handle message loss, reordering, and DTLS message fragmentation (in order to avoid IP fragmentation). 🧩
- Retransmission timers to handle message loss. ⏰
With these exceptions, the DTLS message formats, flows, and logic are the same as TLS 1.2's. Lowkey iconic, right? 👑
4.2.1. Denial-of-Service Countermeasures ✨
okay bestie, datagram security protocols are lowkey SO easy to DoS 😭 like it's giving open door. There are two attacks we really need to worry about 🫣
- An attacker can eat up the server's resources by sending a bunch of handshake initiation requests, which makes the server allocate state and maybe do expensive cryptographic operations. 💀
- An attacker can use the server as an amplifier 📣 by sending connection initiation messages with a forged source address, the victim's address. The server then sends its next message (in DTLS, a Certificate message, which can be quite large) to the victim, and now the victim is getting flooded. not cute 😤
To shut down both of these, DTLS borrows the stateless cookie technique from Photuris [PHOTURIS] and IKE [IKEv2] 🍓 When the client sends its ClientHello to the server, the server MAY respond with a HelloVerifyRequest message. That message carries a stateless cookie made with the technique from [PHOTURIS]. The client MUST retransmit the ClientHello with the cookie added. Then the server checks the cookie and only keeps going with the handshake if it's valid. This forces the attacker/client to actually be able to receive the cookie, which makes spoofed-IP DoS attacks way harder 🔥
Heads up: this doesn't protect against DoS attacks coming from valid IP addresses. Those still get through 💔
Here's how the exchange goes 🦋
Client Server
------ ------
ClientHello ------>
<----- HelloVerifyRequest
(contains cookie)
ClientHello ------>
(with cookie)
[Rest of handshake]So DTLS modifies the ClientHello message to add a cookie value 🎀
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;When the client sends its very first ClientHello, it doesn't have a cookie yet, so the Cookie field is left empty (zero length) 🌸
Here's the definition of HelloVerifyRequest 🧚
struct {
ProtocolVersion server_version;
opaque cookie<0..2^8-1>;
} HelloVerifyRequest;The HelloVerifyRequest message type is hello_verify_request(3). ✨
The server_version field has the same syntax as in TLS. BUT, to avoid having to do version negotiation in the initial handshake, DTLS 1.2 server implementations SHOULD use DTLS version 1.0, no matter which version of TLS is expected to get negotiated 🙈 DTLS 1.2 and 1.0 clients MUST use the version only to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0), and NOT as part of version negotiation. Like, DTLS 1.2 clients MUST NOT assume that just because the server uses version 1.0 in the HelloVerifyRequest, the server isn't DTLS 1.2, or that it'll eventually negotiate DTLS 1.0 instead of DTLS 1.2. don't fall for it bestie 💅
When responding to a HelloVerifyRequest, the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) it used in the original ClientHello. The server SHOULD use those values to generate its cookie, and check that they're correct when the cookie comes back. The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. When the ServerHello arrives, the client MUST verify that the server version values match. And to avoid sequence number duplication when there are multiple HelloVerifyRequests, the server MUST use the record sequence number from the ClientHello as the record sequence number in the HelloVerifyRequest 🫶
Note: this spec bumps the cookie size limit to 255 bytes for more flexibility in the future. The limit stays at 32 for older versions of DTLS.
The DTLS server SHOULD generate cookies in a way that they can be verified without keeping any per-client state on the server 🧠 One technique is to have a randomly generated secret and make cookies like this:
Cookie = HMAC(Secret, Client-IP, Client-Parameters)When the second ClientHello shows up, the server can check that the Cookie is valid and that the client can actually receive packets at that IP address 💜 To avoid sequence number duplication across multiple cookie exchanges, the server MUST use the record sequence number from the ClientHello as the record sequence number in its initial ServerHello. Later ServerHellos only get sent once the server has created state, and they MUST increment normally 📈
One possible attack on this scheme is that the attacker collects a bunch of cookies from different addresses and then reuses them to attack the server 👀 The server can defend against that by changing the Secret value often, which invalidates those old cookies. If the server wants legit clients to be able to finish a handshake during the transition (like, they got a cookie with Secret 1 and then sent the second ClientHello after the server switched to Secret 2), the server can keep a limited window where it accepts both secrets. [IKEv2] suggests adding a version number to cookies so you can detect this case. Another option is to just try verifying with both secrets 🌈
DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed. If the server runs somewhere amplification isn't a problem, the server MAY be configured not to do a cookie exchange. The default SHOULD be that the exchange is performed, though 🛡️ On top of that, the server MAY choose not to do a cookie exchange when a session is resumed. And clients MUST be ready to do a cookie exchange with every handshake 💪
If HelloVerifyRequest is used, the initial ClientHello and HelloVerifyRequest are NOT included in the calculation of the handshake_messages (for the CertificateVerify message) or the verify_data (for the Finished message) 🙅♀️
If a server gets a ClientHello with an invalid cookie, it SHOULD treat it the same as a ClientHello with no cookie. This avoids race/deadlock conditions if the client somehow ends up with a bad cookie (for example, because the server changed its cookie signing key) 🔄
Note to implementors: this may result in clients receiving multiple HelloVerifyRequest messages with different cookies. Clients SHOULD handle this by sending a new ClientHello with a cookie in response to the new HelloVerifyRequest 🧁
4.2.2. Handshake Message Format
So in order to support message loss, reordering, and message fragmentation, DTLS modifies the TLS 1.2 handshake header 🎀
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello;
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;The first message each side sends in each handshake always has message_seq = 0. Every time a new message gets generated, message_seq goes up by one. Note that in the case of a rehandshake, this means the HelloRequest will have message_seq = 0 and the ServerHello will have message_seq = 1. When a message gets retransmitted, the same message_seq value gets used. Check out this example 👇
Client Server
------ ------
ClientHello (seq=0) ------>
X<-- HelloVerifyRequest (seq=0)
(lost)
[Timer Expires]
ClientHello (seq=0) ------>
(retransmit)
<------ HelloVerifyRequest (seq=0)
ClientHello (seq=1) ------>
(with cookie)
<------ ServerHello (seq=1)
<------ Certificate (seq=2)
<------ ServerHelloDone (seq=3)
[Rest of handshake]Now, here's the sneaky bit 🕵️♀️ from the DTLS record layer's point of view, the retransmission is a brand new record. That record gets a new DTLSPlaintext.sequence_number value.
DTLS implementations keep track of (at least notionally) a next_receive_seq counter 🧮 It starts at zero. When a message comes in, if its sequence number matches next_receive_seq, next_receive_seq goes up by one and the message gets processed. If the sequence number is less than next_receive_seq, the message MUST be discarded. If the sequence number is greater than next_receive_seq, the implementation SHOULD queue the message, but it MAY discard it instead. (It's a simple space/bandwidth tradeoff, so no stress 🫶)
4.2.3. Handshake Message Fragmentation and Reassembly
As noted in Section 4.1.1, each DTLS message MUST fit within a single transport layer datagram 📦 But handshake messages can be bigger than the maximum record size. So DTLS has a way to fragment a handshake message across several records, each of which can be sent separately, which dodges IP fragmentation 🦋
When sending a handshake message, the sender splits it into a series of N contiguous data ranges. These ranges MUST NOT be larger than the maximum handshake fragment size, and they MUST together contain the entire handshake message. The ranges SHOULD NOT overlap. Then the sender creates N handshake messages, all with the same message_seq value as the original. Each new message is labeled with the fragment_offset (how many bytes came in previous fragments) and the fragment_length (how long this fragment is). The length field in every message is the same as the length field of the original message. An unfragmented message is just a degenerate case where fragment_offset=0 and fragment_length=length 🌸
When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the whole handshake message. DTLS implementations MUST be able to handle overlapping fragment ranges too. That lets senders retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes 🧚
Last thing: like with TLS, multiple handshake messages can go in the same DTLS record, as long as there's room and they're part of the same flight. So there are two acceptable ways to pack two DTLS messages into one datagram: in the same record, or in separate records 💖
4.2.4. Timeout and Retransmission ✨
okay so DTLS messages get grouped into flights 🧚 (think of them as little squads). A flight can have a bunch of messages in it, but for timeouts and retransmission they should be treated as one monolithic unit. Here's how the full handshake flights look:
Client Server
------ ------
ClientHello --------> Flight 1
<------- HelloVerifyRequest Flight 2
ClientHello --------> Flight 3
ServerHello \
Certificate* \
ServerKeyExchange* Flight 4
CertificateRequest* /
<-------- ServerHelloDone /
Certificate* \
ClientKeyExchange \
CertificateVerify* Flight 5
[ChangeCipherSpec] /
Finished --------> /
[ChangeCipherSpec] \ Flight 6
<-------- Finished /Figure 1. Message Flights for Full Handshake
And the session-resuming version, which skips the cookie exchange 🌸:
Client Server
------ ------
ClientHello --------> Flight 1
ServerHello \
[ChangeCipherSpec] Flight 2
<-------- Finished /
[ChangeCipherSpec] \Flight 3
Finished --------> /Figure 2. Message Flights for Session-Resuming Handshake (No Cookie Exchange)
DTLS uses a simple timeout and retransmission scheme, and it's basically a little state machine 💅. Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.
+-----------+
| PREPARING |
+---> | | <--------------------+
| | | |
| +-----------+ |
| | |
| | Buffer next flight |
| | |
| \|/ |
| +-----------+ |
| | | |
| | SENDING |<------------------+ |
| | | | | Send
| +-----------+ | | HelloRequest
Receive | | | |
next | | Send flight | | or
flight | +--------+ | |
| | | Set retransmit timer | | Receive
| | \|/ | | HelloRequest
| | +-----------+ | | Send
| | | | | | ClientHello
+--)--| WAITING |-------------------+ |
| | | | Timer expires | |
| | +-----------+ | |
| | | | |
| | | | |
| | +------------------------+ |
| | Read retransmit |
Receive | | |
last | | |
flight | | |
| | |
\|/\|/ |
|
+-----------+ |
| | |
| FINISHED | -------------------------------+
| |
+-----------+
| /|\
| |
| |
+---+
Read retransmit
Retransmit last flightFigure 3. DTLS Timeout and Retransmission State Machine
The state machine has three basic states 👑.
In the PREPARING state, the implementation does whatever computations are necessary to prepare the next flight of messages. It then buffers them up for transmission (emptying the buffer first) and enters the SENDING state.
In the SENDING state, the implementation transmits the buffered flight of messages. Once the messages have been sent, the implementation then enters the FINISHED state if this is the last flight in the handshake. Or, if the implementation expects to receive more messages, it sets a retransmit timer and then enters the WAITING state.
There are three ways to exit the WAITING state:
- The retransmit timer expires: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state.
- The implementation reads a retransmitted flight from the peer: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state. The rationale here is that the receipt of a duplicate message is the likely result of timer expiry on the peer and therefore suggests that part of one's previous flight was lost. 🙈
- The implementation receives the next flight of messages: if this is the final flight of messages, the implementation transitions to FINISHED. If the implementation needs to send a new flight, it transitions to the PREPARING state. Partial reads (whether partial messages or only some of the messages in the flight) do not cause state transitions or timer resets.
Again, because DTLS clients send the first message (ClientHello), they start in the PREPARING state, and DTLS servers start in the WAITING state with empty buffers and no retransmit timer. Same energy as before, just making sure it's locked in 🔒.
When the server wants a rehandshake, it transitions from the FINISHED state to the PREPARING state to transmit the HelloRequest. When the client receives a HelloRequest, it transitions from FINISHED to PREPARING to transmit the ClientHello.
Now the important part 🚨. For at least twice the default MSL defined for [TCP], when in the FINISHED state, the node that transmits the last flight (the server in an ordinary handshake or the client in a resumed handshake) MUST respond to a retransmit of the peer's last flight with a retransmit of the last flight. This avoids deadlock conditions if the last flight gets lost. This requirement applies to DTLS 1.0 as well, and though not explicit in [DTLS1], it was always required for the state machine to function correctly.
Why does this matter? Picture an ordinary handshake where the server's Finished message gets lost. The server thinks the handshake is complete, but it actually isn't. Meanwhile the client is waiting for that Finished message, so the client's retransmit timer fires and it resends the client's Finished message. That makes the server respond with its own Finished message, and now the handshake is finished for real 🥹. The same logic applies on the server side for the resumed handshake.
Heads up, bestie: because of packet loss, one side can be sending application data before the other side has received its Finished message. Implementations MUST either discard or buffer all application data packets for the new epoch until they have received the Finished message for that epoch. Implementations MAY treat receipt of application data with a new epoch prior to receipt of the corresponding Finished message as evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer.
4.2.4.1. Timer Values ⏲️
Timer values are up to the implementation, but mishandling the timer can cause serious congestion problems. For example, if lots of DTLS instances time out early and retransmit too quickly on a congested link, everyone gets sad 😭. Implementations SHOULD use an initial timer value of 1 second (the minimum defined in RFC 6298 [RFC6298]) and double the value at each retransmission, up to no less than the RFC 6298 maximum of 60 seconds. We recommend a 1-second timer rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications. Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal.
Implementations SHOULD retain the current timer value until a transmission without loss occurs, at which point the value may be reset to the initial value. After a long period of idleness, no less than 10 times the current timer value, implementations may reset the timer to the initial value. One situation where this might happen is when a rehandshake is used after substantial data transfer.
4.2.5. ChangeCipherSpec 🔐
As with TLS, the ChangeCipherSpec message isn't technically a handshake message, but it MUST be treated as part of the same flight as the associated Finished message for the purposes of timeout and retransmission. This creates a potential ambiguity, because the order of the ChangeCipherSpec can't be established unambiguously with respect to the handshake messages in case of message loss.
This isn't a problem with any current TLS mode, because the expected set of handshake messages logically preceding the ChangeCipherSpec is predictable from the rest of the handshake state. However, future modes MUST take care to avoid creating ambiguity.
4.2.6. CertificateVerify and Finished Messages 🎀
CertificateVerify and Finished messages have the same format as in TLS. Hash calculations include entire handshake messages, including DTLS-specific fields: message_seq, fragment_offset, and fragment_length. However, in order to remove sensitivity to handshake message fragmentation, the Finished MAC MUST be computed as if each handshake message had been sent as a single fragment. Note that in cases where the cookie exchange is used, the initial ClientHello and HelloVerifyRequest MUST NOT be included in the CertificateVerify or Finished MAC computations.
4.2.7. Alert Messages 🚫
Alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected.
4.2.8. Establishing New Associations with Existing Parameters ✨
okay so picture this: a DTLS client and server keep connecting on the same host/port quartet 🎀 and the client quietly ditches one connection and starts a new one with the same settings (like after a reboot 🔄). To the server, it looks like a brand new handshake with epoch=0. 👀
Here's the rule. If the server thinks it already has an association on that quartet and gets an epoch=0 ClientHello, it SHOULD go ahead with a new handshake, but it MUST NOT destroy the existing association until the client proves it's reachable. The client can prove that by finishing a cookie exchange or by completing a full handshake that includes a verifiable Finished message. 🔐 Once a correct Finished message comes in, the server MUST abandon the old association so two valid associations with overlapping epochs don't get mixed up. 🙅♀️
Why all the fuss? That reachability check stops off-path or blind attackers from wiping out associations just by sending forged ClientHellos. Main character protection, honestly 💅🛡️
4.3. Summary of New Syntax 🧚
This section has the data structures that changed between TLS 1.2 and DTLS 1.2. For the actual definition of the syntax, go check [TLS12]. 📖
4.3.1. Record Layer 🍓
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSCompressed.length];
} DTLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
select (CipherSpec.cipher_type) {
case block: GenericBlockCipher;
case aead: GenericAEADCipher; // New field
} fragment;
} DTLSCiphertext;4.3.2. Handshake Protocol 🌸
enum {
hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255) } HandshakeType;
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // New field
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body; } Handshake;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; } ClientHello;
struct {
ProtocolVersion server_version;
opaque cookie<0..2^8-1>; } HelloVerifyRequest;5. Security Considerations 🔐💀
This doc describes a variant of TLS 1.2, so most of the security stuff is the same as TLS 1.2 [TLS12], which you'll find in Appendices D, E, and F. 📚
The big new security issue DTLS brings is denial of service (DoS) 😱. DTLS has a cookie exchange built to protect against it, but implementations that skip the cookie exchange are still exposed to DoS. Even worse, DTLS servers that skip it can get used as attack amplifiers, even when they aren't under attack themselves. 🚨 So DTLS servers SHOULD use the cookie exchange unless there's a really good reason to think amplification isn't a threat where they live. Clients MUST be ready to do a cookie exchange with every handshake. 🍵
Unlike TLS implementations, DTLS implementations SHOULD NOT kill the connection just because they got an invalid record. Section 4.1.2.7 has the details on that. 🫶
6. Acknowledgments 🫶🌈
The authors want to thank Dan Boneh, Eu-Jin Goh, Russ Housley, Constantine Sapuntzakis, and Hovav Shacham for chatting with them about and commenting on the design of DTLS. 💜 Thanks to the anonymous NDSS reviewers of the original NDSS paper on DTLS [DTLS] for their comments. Also, thanks to Steve Kent for feedback that helped clarify lots of points. The section on PMTU was cribbed from the DCCP specification [DCCP]. Pasi Eronen gave a detailed review of this specification. Peter Saint-Andre made the list of changes in Section 8. Helpful comments on the document also came from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Adrian Farrell, Joel Halpern, Ted Hardie, Charlia Kaufman, Pekka Savola, Allison Mankin, Nikos Mavrogiannopoulos, Alexey Melnikov, Robin Seggelmann, Michael Tuexen, Juho Vaha-Herttua, and Florian Weimer. 🙌
7. IANA Considerations 📋
This doc uses the same identifier space as TLS [TLS12], so no new IANA registries are needed. 🎉 When new identifiers get assigned for TLS, authors MUST say whether they're suitable for DTLS. IANA has updated all the TLS parameter registries with a DTLS-OK flag, which shows whether the spec can be used with DTLS. At publication time, every [TLS12] registration is suitable for DTLS except the ones listed below. The full table lives at [IANA]. 📑
From the TLS Cipher Suite Registry:
0x00,0x03 TLS_RSA_EXPORT_WITH_RC4_40_MD5 [RFC4346]
0x00,0x04 TLS_RSA_WITH_RC4_128_MD5 [RFC5246]
0x00,0x05 TLS_RSA_WITH_RC4_128_SHA [RFC5246]
0x00,0x17 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 [RFC4346]
0x00,0x18 TLS_DH_anon_WITH_RC4_128_MD5 [RFC5246]
0x00,0x20 TLS_KRB5_WITH_RC4_128_SHA [RFC2712]
0x00,0x24 TLS_KRB5_WITH_RC4_128_MD5 [RFC2712]
0x00,0x28 TLS_KRB5_EXPORT_WITH_RC4_40_SHA [RFC2712]
0x00,0x2B TLS_KRB5_EXPORT_WITH_RC4_40_MD5 [RFC2712]
0x00,0x8A TLS_PSK_WITH_RC4_128_SHA [RFC4279]
0x00,0x8E TLS_DHE_PSK_WITH_RC4_128_SHA [RFC4279]
0x00,0x92 TLS_RSA_PSK_WITH_RC4_128_SHA [RFC4279]
0xC0,0x02 TLS_ECDH_ECDSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x07 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x0C TLS_ECDH_RSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x11 TLS_ECDHE_RSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x16 TLS_ECDH_anon_WITH_RC4_128_SHA [RFC4492]
0xC0,0x33 TLS_ECDHE_PSK_WITH_RC4_128_SHA [RFC5489]From the TLS Exporter Label Registry:
client EAP encryption [RFC5216]
ttls keying material [RFC5281]
ttls challenge [RFC5281]This doc defines a brand new handshake message, hello_verify_request 🧚, and its value came from the TLS HandshakeType registry defined in [TLS12]. IANA assigned the value "3" to it. ✨
8. Changes since DTLS 1.0 🦋
This doc reflects the following changes since DTLS 1.0 [DTLS1]. 📝
- Updated to match TLS 1.2 [TLS12].
- Addition of AEAD Ciphers in Section 4.1.2.3 (tracking changes in TLS 1.2.
- Clarifications regarding sequence numbers and epochs in Section 4.1 and a clear procedure for dealing with state loss in Section 4.2.8.
- Clarifications and more detailed rules regarding Path MTU issues in Section 4.1.1.1. Clarification of the fragmentation text throughout.
- Clarifications regarding handling of invalid records in Section 4.1.2.7.
- A new paragraph describing handling of invalid cookies at the end of Section 4.2.1.
- Some new text describing how to avoid handshake deadlock conditions at the end of Section 4.2.4.
- Some new text about CertificateVerify messages in Section 4.2.6.
- A prohibition on epoch wrapping in Section 4.1.
- Clarification of the IANA requirements and the explicit requirement for a new IANA registration flag for each parameter.
- Added a record sequence number mirroring technique for handling repeated ClientHello messages.
- Recommend a fixed version number for HelloVerifyRequest.
- Numerous editorial changes.
9. References 📚💖
9.1. Normative References
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, March
2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, June
2011.
[RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.9.2. Informative References ✨
okay bestie, here's the reading list 📚 these ones aren't required to build the thing, but they're the background drama that makes the whole design make sense 💅
[DCCP]Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 🦋[DCCPDTLS]Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008. 🌸[DTLS]Modadugu, N. and E. Rescorla, "The Design and Implementation of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. 💜[DTLS1]Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. 🎀[ECCGCM]Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008. ✨[ESP]Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 🔥[IANA]IANA, "Transport Layer Security (TLS) Parameters",http://www.iana.org/assignments/tls-parameters. 🧚[IKEv2]Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 🍓[IMAP]Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. 🌈[PHOTURIS]Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999. ⭐[POP]Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. 💌[SIP]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📞[TLS]Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 🫶[TLS11]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 💖[WHYIPSEC]Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009. 🌸
Authors' Addresses ✨
Here are the people who wrote it, with their addresses exactly as they appear in the document 🫶
Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
EMail: ekr@rtfm.com
Nagendra Modadugu
Google, Inc.
EMail: nagendra@cs.stanford.eduAnd that's the whole spec, bestie! 🎀 Go forth and implement responsibly 💅👑
📦 where this page comes from
- ietf: rfc6347 2012-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms