3. <del> This specification uses the tls_flags extension defined in I-D.ietf- tls-tlsflags to allow a client and a server to negotiate support for this extension. </del>  <del> The RRC flag is assigned the value (TBD1) and is used in the ClientHello (CH) and the ServerHello (SH). </del>  4. before cryptographically validating the enclosed record(s) but instead perform a return routability check. <del> The newly introduced return_routability_check message contains a </del>  cookie.  The cookie is a 8-byte field containing arbitrary data. <del> The return_routability_check message MUST be authenticated and </del>  encrypted using the currently active security context. The receiver that observes the peer's address and or port update MUST a TBD threshold) and initiate the return routability check that proceeds as follows: <del> A cookie is placed in a return_routability_check message of type </del>  path_challenge; The message is sent to the observed new address and a timeout T is started; The peer endpoint, after successfully verifying the received <del> return_routability_check message echoes the cookie value in a return_routability_check message of type path_response; </del>  When the initiator receives and verifies the <del> return_routability_check message contains the sent cookie, it </del>  updates the peer address binding; If T expires, or the address confirmation fails, the peer address 7. IANA is requested to allocate an entry to the TLS "ContentType" <del> registry, for the return_routability_check(TBD) defined in this document. IANA is requested to allocate an entry to the TLS Flags registry in the tls_flags type: Value: [[IANA please assign a value from the 32-63 value range.]] Flag Name: RRC Message: CH,SH Recommended: Y </del>  <del> Reference: [[This document]] </del>  8.

Use a new extension type instead.
Yes, if tls-flags are not usable for DTLS 1.2, then go with this.
We'd like to use to negotiate RRC. At the moment, the document seems to be defined for (D)TLS 1.3 only, but the reason why the same scheme would not be applicable to 1.2 are not fully clear. For now (-01), optimistically, we are using it in a version agnostic fashion, hoping that eventually that will be the case. Achim has opened an . This issue is for tracking on the RRC side.

3.  <ins> The use of RRC is negotiated via the "rrc" DTLS-only extension.  On connecting, the client includes the "rrc" extension in its ClientHello if it wishes to use RRC.  If the server is capable of meeting this requirement, it responds with a "rrc" extension in its ServerHello.  The "extension_type" value for this extension is TBD1 and the "extension_data" field of this extension is empty.  The client and server MUST NOT use RRC unless both sides have successfully exchanged "rrc" extensions. </ins>  <ins> Note that the RRC extension applies to both DTLS 1.2 and DTLS 1.3. </ins> 4. before cryptographically validating the enclosed record(s) but instead perform a return routability check.  <ins> The newly introduced "return_routability_check" message contains a </ins> cookie.  The cookie is a 8-byte field containing arbitrary data.  <ins> The "return_routability_check" message MUST be authenticated and </ins> encrypted using the currently active security context. The receiver that observes the peer's address and or port update MUST a TBD threshold) and initiate the return routability check that proceeds as follows:  <ins> A cookie is placed in a "return_routability_check" message of type </ins> path_challenge; The message is sent to the observed new address and a timeout T is started; The peer endpoint, after successfully verifying the received  <ins> "return_routability_check" message echoes the cookie value in a "return_routability_check" message of type path_response; </ins> When the initiator receives and verifies the  <ins> "return_routability_check" message contains the sent cookie, it </ins> updates the peer address binding; If T expires, or the address confirmation fails, the peer address 7. IANA is requested to allocate an entry to the TLS "ContentType"  <ins> registry, for the "return_routability_check(TBD2)" defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3. </ins>  <ins> IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. </ins> 8.


Protocol.  However, TLS must run over a reliable transport channel - typically TCP RFC0793. <del> There are applications that utilize UDP as a transport and to offer communication security protection for those applications the Datagram Transport Layer Security (DTLS) protocol has been designed.  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. DTLS 1.0 was originally defined as a delta from TLS 1.1 and DTLS 1.2 was defined as a series of deltas to TLS 1.2.  There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS.  This specification describes the most current version of the DTLS protocol aligning with the efforts around TLS 1.3. </del>  Implementations that speak both DTLS 1.2 and DTLS 1.3 can interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of The following terms are used: <del> client: The endpoint initiating the TLS connection. </del>  connection: A transport-layer connection between two endpoints. session: An association between a client and a server resulting from a handshake. <del> server: The endpoint which did not initiate the TLS connection. </del>  The reader is assumed to be familiar with the TLS 1.3 specification since this document defined as a delta from TLS 1.3. 8. <del> Since TLS 1.3 introduce a large number of changes to TLS 1.2, the </del>  list of changes from DTLS 1.2 to DTLS 1.3 is equally large.  For this reason this section focuses on the most important changes only.

Add references to RFC 768: UDP RFC 4347: DTLS 1.0 RFC 4346: TLS 1.1 RFC 6347: DTLS 1.2 RFC 5246: TLS 1.2 in the Introduction section. Currently they are mentioned but with no citations.

Protocol.  However, TLS must run over a reliable transport channel - typically TCP RFC0793.  <ins> There are applications that utilize UDP RFC0768 as a transport and to offer communication security protection for those applications the Datagram Transport Layer Security (DTLS) protocol has been designed. 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. DTLS 1.0 RFC4347 was originally defined as a delta from TLS 1.1 RFC4346 and DTLS 1.2 RFC6347 was defined as a series of deltas to TLS 1.2 RFC5246.  There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS.  This specification describes the most current version of the DTLS protocol aligning with the efforts around TLS 1.3 I-D.ietf-tls-tls13. </ins> Implementations that speak both DTLS 1.2 and DTLS 1.3 can interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of The following terms are used:  <ins> client: The endpoint initiating the DTLS connection. </ins> connection: A transport-layer connection between two endpoints. session: An association between a client and a server resulting from a handshake.  <ins> server: The endpoint which did not initiate the DTLS connection. </ins> The reader is assumed to be familiar with the TLS 1.3 specification since this document defined as a delta from TLS 1.3. 8.  <ins> Since TLS 1.3 introduces a large number of changes to TLS 1.2, the </ins> list of changes from DTLS 1.2 to DTLS 1.3 is equally large.  For this reason this section focuses on the most important changes only.


IANA is requested to allocate a new value in the "TLS ContentType" registry for the ACK message, defined in ack-msg, with content type <del> 25.  IANA is requested to reserve the content type range 32-63 so </del>  that content types in this range are not allocated. IANA is requested to allocate two values in the "TLS Handshake Type"

DTLS recommends using 25 as the ACK Content Type. CID is using that number based on an early IANA assignment will change DTLS.

IANA is requested to allocate a new value in the "TLS ContentType" registry for the ACK message, defined in ack-msg, with content type  <ins> 26.  IANA is requested to reserve the content type range 32-63 so </ins> that content types in this range are not allocated. IANA is requested to allocate two values in the "TLS Handshake Type"


computing AES-ECB on the first 16 bytes of the ciphertext: When the AEAD is based on ChaCha20, then the mask is generated by <del> treating the first 12 bytes of the ciphertext as the Nonce and the next 4 bytes as the counter, passing them to the ChaCha20 block </del>  function (Section 2.3 of CHACHA): The sn_key is computed as follows:

NAME NAME
... takes its sample inputs in a different order to the one used in QUIC. This issue tracks the possibility of erasing that difference.

computing AES-ECB on the first 16 bytes of the ciphertext: When the AEAD is based on ChaCha20, then the mask is generated by  <ins> treating the first 4 bytes of the ciphertext as the block counter and the next 12 bytes as the nonce, passing them to the ChaCha20 block </ins> function (Section 2.3 of CHACHA): The sn_key is computed as follows:


datagrams are often limited to less than 1500 bytes if IP fragmentation is not desired.  In order to compensate for this limitation, each DTLS handshake message may be fragmented over <del> several DTLS records, each of which is intended to fit in a single IP packet.  Each DTLS handshake message contains both a fragment offset and a fragment length.  Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented </del>  message. 3.4. Because DTLS records could be reordered, a record from epoch M may be received after epoch N (where N > M) has begun.  In general, <del> implementations SHOULD discard packets from earlier epochs, but if </del>  packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that new epoch to be received prior to the completion of a handshake.  For instance, the server may send its Finished message and then start transmitting data.  Implementations MAY either buffer or discard such <del> packets, though when DTLS is used over reliable transports (e.g., </del>  SCTP RFC4960), they SHOULD be buffered and processed once the <del> handshake completes.  Note that TLS's restrictions on when packets may be sent still apply, and the receiver treats the packets as if </del>  they were sent in the right order. Implementations MUST send retransmissions of lost messages using the the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. <del> The received packet counter for a session MUST be initialized to zero </del>  when that session is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after <del> deprotecting the packet; otherwise the packet discard might itself </del>  serve as a timing channel for the record number.  Note that decompressing the records number is still a potential timing channel for the record number, though a less powerful one than whether it was The "right" edge of the window represents the highest validated sequence number value received on the session.  Records that contain sequence numbers lower than the "left" edge of the window are <del> rejected.  Packets falling within the window are checked against a list of received packets within the window.  An efficient means for </del>  performing this check, based on the use of a bit mask, is described in Section 3.4.3 of RFC4303.  If the received record falls within the <del> window and is new, or if the packet is to the right of the window, then the packet is new. </del>  <del> The window MUST NOT be updated until the packet has been deprotected </del>  successfully. 4.5.2. of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length. <del> Each range MUST be delivered in a single packet. </del>  When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message.  DTLS Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message.  Implementations MUST either <del> discard or buffer all application data packets for the new epoch </del>  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 ClientHellos. Note: it is not always possible to distinguish which association a <del> given packet is from.  For instance, if the client performs a </del>  handshake, abandons the connection, and then immediately starts a new handshake, it may not be possible to tell which connection a given protected record is for.  In these cases, trial decryption MAY be this requires implementations to track which messages appear in which records.  Once all the messages in a flight have been acknowledged, the implementation MUST cancel all retransmissions of that flight. <del> As noted above, the receipt of any packet responding to a given </del>  flight MUST be taken as an implicit acknowledgement for the entire flight. If implementations process out-of-epoch records as recommended in key-updates, then this creates a denial of service risk since an <del> adversary could inject packets with fake epoch values, forcing the </del>  recipient to compute the next-generation application_traffic_secret using the HKDF-Expand-Label construct to only find out that the message was does not pass the AEAD cipher processing.  The impact of

NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.

datagrams are often limited to less than 1500 bytes if IP fragmentation is not desired.  In order to compensate for this limitation, each DTLS handshake message may be fragmented over  <ins> several DTLS records, each of which is intended to fit in a single UDP datagram.  Each DTLS handshake message contains both a fragment offset and a fragment length.  Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented </ins> message. 3.4. Because DTLS records could be reordered, a record from epoch M may be received after epoch N (where N > M) has begun.  In general,  <ins> implementations SHOULD discard records from earlier epochs, but if </ins> packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that new epoch to be received prior to the completion of a handshake.  For instance, the server may send its Finished message and then start transmitting data.  Implementations MAY either buffer or discard such  <ins> records, though when DTLS is used over reliable transports (e.g., </ins> SCTP RFC4960), they SHOULD be buffered and processed once the  <ins> handshake completes.  Note that TLS's restrictions on when records may be sent still apply, and the receiver treats the records as if </ins> they were sent in the right order. Implementations MUST send retransmissions of lost messages using the the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303.  <ins> The received record counter for a session MUST be initialized to zero </ins> when that session is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after  <ins> deprotecting the record; otherwise the record discard might itself </ins> serve as a timing channel for the record number.  Note that decompressing the records number is still a potential timing channel for the record number, though a less powerful one than whether it was The "right" edge of the window represents the highest validated sequence number value received on the session.  Records that contain sequence numbers lower than the "left" edge of the window are  <ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for </ins> performing this check, based on the use of a bit mask, is described in Section 3.4.3 of RFC4303.  If the received record falls within the  <ins> window and is new, or if the record is to the right of the window, then the record is new. </ins>  <ins> The window MUST NOT be updated until the record has been deprotected </ins> successfully. 4.5.2. of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length.  <ins> Each range MUST be delivered in a single UDP datagram. </ins> When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message.  DTLS Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message.  Implementations MUST either  <ins> discard or buffer all application data records for the new epoch </ins> 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 ClientHellos. Note: it is not always possible to distinguish which association a  <ins> given record is from.  For instance, if the client performs a </ins> handshake, abandons the connection, and then immediately starts a new handshake, it may not be possible to tell which connection a given protected record is for.  In these cases, trial decryption MAY be this requires implementations to track which messages appear in which records.  Once all the messages in a flight have been acknowledged, the implementation MUST cancel all retransmissions of that flight.  <ins> As noted above, the receipt of any record responding to a given </ins> flight MUST be taken as an implicit acknowledgement for the entire flight. If implementations process out-of-epoch records as recommended in key-updates, then this creates a denial of service risk since an  <ins> adversary could inject records with fake epoch values, forcing the </ins> recipient to compute the next-generation application_traffic_secret using the HKDF-Expand-Label construct to only find out that the message was does not pass the AEAD cipher processing.  The impact of


The two low bits (0x03) include the low order two bits of the epoch. <del> Variable length CID.  The CID concept is described in DTLS-CID. An example can be found in connection-id-example. </del>  The low order 8 or 16 bits of the record sequence number.  This value is 16 bits if the S bit is set to 1, and 8 bits if the S bit association identifiers and applications must arrange to multiplex between associations.  With UDP, the host/port number is used to look up the appropriate security association for incoming records. <del> However, the CID extension defined in DTLS-CID adds an association identifier to DTLS records. </del>  Some transports, such as DCCP RFC4340, provide their own sequence numbers.  When carried over those transports, both the DTLS and the 9. If the client and server have negotiated the "connection_id" <del> extension DTLS-CID, either side can send a new CID which it wishes the other side to use in a NewConnectionId message. </del>  %%% Connection ID Management enum { cid_immediate(0), cid_spare(1), (255) } ConnectionIdUsage; Below is an example exchange for DTLS 1.3 using a single CID in each direction. <del> Note: The connection_id extension is defined in DTLS-CID, which is used in ClientHello and ServerHello messages. </del>  If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID. concerned about this form of attack can discard out-of-epoch records. The security and privacy properties of the CID for DTLS 1.3 builds on <del> top of what is described in DTLS-CID.  There are, however, several improvements: </del>  The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with

I-D.ietf-tls-dtls-connection-id became a normative reference Removed duplicate reference to I-D.ietf-tls-dtls-connection-id.

The two low bits (0x03) include the low order two bits of the epoch.  <ins> Variable length CID.  The CID concept is described in I-D.ietf- tls-dtls-connection-id.  An example can be found in connection-id- example. </ins> The low order 8 or 16 bits of the record sequence number.  This value is 16 bits if the S bit is set to 1, and 8 bits if the S bit association identifiers and applications must arrange to multiplex between associations.  With UDP, the host/port number is used to look up the appropriate security association for incoming records.  <ins> However, the CID extension defined in I-D.ietf-tls-dtls-connection-id adds an association identifier to DTLS records. </ins> Some transports, such as DCCP RFC4340, provide their own sequence numbers.  When carried over those transports, both the DTLS and the 9. If the client and server have negotiated the "connection_id"  <ins> extension I-D.ietf-tls-dtls-connection-id, either side can send a new CID which it wishes the other side to use in a NewConnectionId message. </ins> %%% Connection ID Management enum { cid_immediate(0), cid_spare(1), (255) } ConnectionIdUsage; Below is an example exchange for DTLS 1.3 using a single CID in each direction.  <ins> Note: The connection_id extension is defined in I-D.ietf-tls-dtls- connection-id, which is used in ClientHello and ServerHello messages. </ins> If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID. concerned about this form of attack can discard out-of-epoch records. The security and privacy properties of the CID for DTLS 1.3 builds on  <ins> top of what is described in I-D.ietf-tls-dtls-connection-id.  There are, however, several improvements: </ins> The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with


The cookie extension is defined in Section 4.2.2 of TLS13.  When sending the initial ClientHello, the client does not have a cookie yet.  In this case, the cookie extension is omitted and the <del> legacy_cookie field in the ClientHello message SHOULD be set to a zero length vector (i.e., a single zero byte length field) and MUST be ignored by a server negotiating DTLS 1.3. </del>  When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of

I can't reconcile: ... with: The MUSTs in these appear to be pulling in opposite directions. I suspect that the latter is correct though. It is possible that a DTLS 1.3 client could get a legacy cookie from a DTLS 1.2 server, so that it is valid for the legacy cookie to appear when supported_versions includes DTLS 1.3. However, that represents an attack and a DTLS 1.3 server shouldn't continue to establish the connection. Maybe it isn't a bad attack because the client doesn't change its posture in ways that would materially affect the resulting session, but we have generally tried to avoid these.

The cookie extension is defined in Section 4.2.2 of TLS13.  When sending the initial ClientHello, the client does not have a cookie yet.  In this case, the cookie extension is omitted and the  <ins> legacy_cookie field in the ClientHello message MUST be set to a zero length vector (i.e., a single zero byte length field). </ins> When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of


flight of messages.  If the implementation has received one or more ACKs (see ack-msg) from the peer, then it SHOULD omit any messages or message fragments which have already been ACKed.  Once the messages <del> 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 </del>  enters the WAITING state. There are four ways to exit the WAITING state:

The previous version erroneously specified that implementations should transition from SENDING to FINISHED after sending the last flight in a handshake. Instead, they should transition to WAITING and only move to FINISHED upon receipt of ACKs for the entire last flight. This PR fixes the state machine diagram and text.
lgtm

flight of messages.  If the implementation has received one or more ACKs (see ack-msg) from the peer, then it SHOULD omit any messages or message fragments which have already been ACKed.  Once the messages  <ins> have been sent, the implementation then sets a retransmit timer and </ins> enters the WAITING state. There are four ways to exit the WAITING state:


handshake, the server's transmission of the NewSessionTicket, and KeyUpdate messages.  ACKs SHOULD NOT be sent for other complete flights because they are implicitly acknowledged by the receipt of <del> the next flight, which generally immediately follows the flight. </del>  Each NewSessionTicket or KeyUpdate is an individual flight; in particular, a KeyUpdate sent in response to a KeyUpdate with update_requested does not implicitly acknowledge that message.

Hanno Becker writes: I have a minor comment on DTLS 1.3 draft 37. On the topic of sending ACKs, the draft recommends: I wonder if the case of post-handshake authentication should be explicitly mentioned as a potential exception to this rule, since the TLS 1.3 RFC explicitly mentions that responses to may be delayed in some contexts: In this case, it would be beneficial to immediately explicitly ACK the message even though it is also implicitly acked through the eventual response via the message.

handshake, the server's transmission of the NewSessionTicket, and KeyUpdate messages.  ACKs SHOULD NOT be sent for other complete flights because they are implicitly acknowledged by the receipt of  <ins> the next flight, which generally immediately follows the flight, unless generating the responding flight takes significant time.  In this case, implementations MAY send explicit ACKs for the complete received flight even though it will eventually also be implicitly acknowledged through the responding flight.  A notable example for this is the case of post-handshake client authentication in constrained environments, where generating the CertificateVerify message can take considerable time on the client. </ins> Each NewSessionTicket or KeyUpdate is an individual flight; in particular, a KeyUpdate sent in response to a KeyUpdate with update_requested does not implicitly acknowledge that message.


7. <del> The ACK message is used by an endpoint to indicate handshake- containing the TLS records it has received from the other side.  ACK is not a handshake message but is rather a separate content type, with code point TBD (proposed, 25).  This avoids having ACK being added to the handshake transcript.  Note that ACKs can still be sent in the same UDP datagram as handshake records. </del>  %%% ACKs struct { RecordNumber record_numbers<0..2^16-1>; } ACK; flight which the endpoint has received and either processed or buffered, in numerically increasing order. <del> Implementations MUST NOT acknowledge records containing non- duplicative handshake messages or fragments which have not been processed or buffered.  Otherwise, deadlock can ensue. </del>  During the handshake, ACKs only cover the current outstanding flight (this is possible because DTLS is generally a lockstep protocol). 7.1. <del> When an implementation receives a partial flight, it SHOULD generate an ACK that covers the messages from that flight which it has received so far.  Implementations have some discretion about when to generate ACKs, but it is RECOMMENDED that they do so under two circumstances: </del>  When they receive a message or fragment which is out of order, either because it is not the next expected message or because it <del> is not the next piece of the current message.  Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted. </del>  When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP

In response to feedback on the mailing list (URL), this PR attempts to clarify (a) when to generate ACKs, and (b) which records to ACK.
This is much clearer to me. I see that you have removed the sentence I was having a problem with in the bullet: "Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted"; logically, I believe you have captured this better by adding "and processed" above in "The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side."
NAME Thank you for your feedback! I have removed the sentence because its content is already implied by what's stated in the previous section . See the commit description of URL
NAME thanks. This sensibly improves readability and clarity. Hi Hanno, Thank you for your clarifications. The example you gave helps a lot. I believe I now understand the text as written in this bullet (first bullet, not second--my bad). I no longer think it needs re-wording. Best regards, Jonathan Hanno Becker wrote:

7.  <ins> The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side.  ACK is not a handshake message but is rather a separate content type, with code point TBD (proposed, 25).  This avoids having ACK being added to the handshake transcript.  Note that ACKs can still be sent in the same UDP datagram as handshake records. </ins> %%% ACKs struct { RecordNumber record_numbers<0..2^16-1>; } ACK; flight which the endpoint has received and either processed or buffered, in numerically increasing order.  <ins> Implementations MUST NOT acknowledge records containing handshake messages or fragments which have not been processed or buffered. Otherwise, deadlock can ensue.  As an example, implementations MUST NOT send ACKs for handshake messages which they discard as out-of- order. </ins> During the handshake, ACKs only cover the current outstanding flight (this is possible because DTLS is generally a lockstep protocol). 7.1.  <ins> When an implementation detects a disruption in the receipt of the current incoming flight, it SHOULD generate an ACK that covers the messages from that flight which it has received and processed so far. Implementations have some discretion about which events to treat as signs of disruption, but it is RECOMMENDED that they generate ACKs under two circumstances: </ins> When they receive a message or fragment which is out of order, either because it is not the next expected message or because it  <ins> is not the next piece of the current message. </ins> When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP


because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer.  5. DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the

And define limits for the CCM ciphers. This turned out to be a little tricky. I copied the text about AEADAES128CCM from the QUIC PR, which is easy, but AEADAES128CCM8 is a while different story. As that is defined in TLS 1.3, it seems necessary to address it here. QUIC simply doesn't allow that, but I assume that DTLS will. On the basis that DTLS will allow AEADAES128CCM_8, we need some language about it. I've tried to write something, but I'm not very happy with it. I'd greatly prefer not to allow this AEAD in DTLS. It's basically fine in TLS, but here the margins are just too narrow. I realize that 2^-57 is essentially arbitrary, you might reasonably say that 2^-40 is better, but that would change the analysis in other ways.
We cannot get rid of CCM_8 because this is used in various IoT standards and it is also implemented in hardware.
That's why this PR is shaped as it is. Some of us which we could get rid of it though; it's just not strong enough.
We should count failed "deprotection" attempts and limit the number that are permitted with any given key. Otherwise, an attacker might be able to successfully forge a record. See URL for a more thorough description of the problem and the analysis of different options.

because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer. <ins> 4.5.3. Section 5.5 of TLS TLS13 defines limits on the number of records that can be protected using the same keys.  These limits are specific to an AEAD algorithm, and apply equally to DTLS.  Implementations SHOULD NOT protect more records than allowed by the limit specified for the negotiated AEAD.  Implementations SHOULD initiate a key update before reaching this limit. TLS13 does not specify a limit for AEAD_AES_128_CCM, but the analysis in ccm-bounds shows that a limit of 2^23 packets can be used to obtain the same confidentiality protection as the limits specified in TLS. The usage limits defined in TLS 1.3 exist for protection against attacks on confidentiality and apply to successful applications of AEAD protection.  The integrity protections in authenticated encryption also depend on limiting the number of attempts to forge packets.  TLS achieves this by closing connections after any record fails an authentication check.  In comparison, DTLS ignores any packet that cannot be authenticated, allowing multiple forgery attempts. Implementations MUST count the number of received packets that fail authentication with each key.  If the number of packets that fail authentication exceed a limit that is specific to the AEAD in use, an implementation SHOULD immediately close the connection. Implementations SHOULD initiate a key update with update_requested before reaching this limit.  Once a key update has been initiated, the previous keys can be dropped when the limit is reached rather than closing the connection.  Applying a limit reduces the probability that an attacker is able to successfully forge a packet; see AEBounds and ROBUST. For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of records that fail authentication is 2^36. Note that the analysis in AEBounds supports a higher limit for the AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification recommends a lower limit.  For AEAD_AES_128_CCM, the limit on the number of records that fail authentication is 2^23.5; see ccm-bounds. The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_SHA256, does not have a limit on the number of records that fail authentication that both limits the probability of forgery by the same amount and does not expose implementations to the risk of denial of service; see ccm-short.  Therefore, TLS_AES_128_CCM_SHA256 MUST NOT used in DTLS without additional safeguards against forgery.  Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on an understanding of any additional forgery protections that are used. Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both confidentiality and integrity.  That is, limits MUST be specified for the number of packets that can be authenticated and for the number packets that can fail authentication.  Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions. </ins> 5. DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the


defines an algorithm for encrypting sequence numbers, see sne. Note that sequence number encryption is used for all encrypted DTLS 1.3 records irrespective of whether a CID is used or not.  DTLS 1.3 encrypts handshake messages much earlier than in previous DTLS versions.  Therefore, less information identifying the DTLS

LGTM.
DTLS and QUIC share a lot of characteristics when it comes to protection of records/packets, but the DTLS sequence number encryption covers marginally less than the header protection in QUIC. Notably, this doesn't include the epoch in DTLS, where QUIC protects its one-bit epoch value. This avoids one issue QUIC has with respect to overuse of keys under an attempted forgery attack, because the choice of key is always clear, but it does mean that the epoch can be used to improve correlation between activity on different network paths. I don't think that this needs to be fixed, but it should be noted in the security considerations.

defines an algorithm for encrypting sequence numbers, see sne. Note that sequence number encryption is used for all encrypted DTLS 1.3 records irrespective of whether a CID is used or not. <ins> Unlike the sequence number, the epoch is not encrypted.  This may improve correlation of packets from a single connection across different network paths. </ins> DTLS 1.3 encrypts handshake messages much earlier than in previous DTLS versions.  Therefore, less information identifying the DTLS


4. <del> The DTLS record layer is similar to that of TLS 1.3 unless noted otherwise.  The only change is the inclusion of an explicit epoch and sequence number in the record.  This sequence number allows the recipient to correctly verify the TLS MAC.  The DTLS record format is shown below: </del>  The content type of the record. Identical to the encrypted_record field in a TLS 1.3 record.  4.1. DTLS uses an explicit sequence number, rather than an implicit one, Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association.  4.2. Each DTLS record MUST fit within a single datagram.  In order to

NAME PTAL
Oops. Thanks.
Sorry, I forgot to mention that I plan to do a separate PR for shrinking DTLS ciphertext. I have part of it in my buffer, but got this up and had to move on to something else for a bit.
I'm happy to defer fixing KeyUpdate, which is basically non-functional as it is. This is fine on that basis.

4.  <ins> The DTLS record layer is similar to that of TLS 1.3.  There are two major changes: The DTLS record layer includes an explicit epoch and sequence number in the record.  This sequence number allows the recipient to correctly verify the TLS MAC. DTLS adds a short header format that can be used to reduce overhead once the handshake is complete. The basic DTLS record format is shown below: </ins> The content type of the record. Identical to the encrypted_record field in a TLS 1.3 record. <ins> As with previous versions of DTLS, mutliple DTLSCiphertext records can be included in the same underlying transport datagram. The short DTLS header format is: The short_epoch_and_sequence document contains the epoch and sequence packed into a 16 bit integer as follows: The first three bits are set to 001 in order to allow multiplexing between DTLS and VoIP protocols (STUN, RTP/RTCP, etc.)  RFC7983 and distinguish the short from long header formats. The fourth bit is the low order bit of the epoch value. The remaining bits contain the low order 12 bits of the sequence number. For deprotecion purposes, the nonce is computed using the full sequence number, which can be reconstructed as described in reconstructing. In this format, the length field is omitted and therefore the record consumes the entire rest of the datagram in the lower level transport.  It is not possible to have multiple DTLSShortCiphertext format records in the same datagram. DTLSShortCiphertext MUST only be used for data which is protected with one of the application_traffic_secrets, and not for either handshake or early data.  When using an application_traffic_secret for message protection, Implementations MAY use either DTLSCiphertext or DTLSShortCiphertext at their discretion. </ins> 4.1. DTLS uses an explicit sequence number, rather than an implicit one, Implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association. <ins> 4.1.1. Implementations can distinguish the two header formats by examining the first byte, which in the DTLSCiphertext header represents the content type.  The only valid values for the content type are alert(21), handshake(22), application_data(23), and ack(25), with application_data actually representing protected data with the true content type being encrypted.  If any of these values is present, then the record MUST be handled as DTLSCiphertext. If the first byte is any other other value, then receivers MUST check to see if the leading bits of the first byte are 001.  If so, they MUST process the record as DTLSShortCiphertext.  Otherwise, the record MUST be rejected as if it had failed deprotection. 4.1.2. When receiving a DTLSShortCiphertext message, the recipient does not have a full epoch or sequence number value and so there is some opportunity for ambiguity.  Because the full epoch and sequence number are used to compute the per-record nonce, failure to reconstruct these values leads to failure to deprotect the record, and so implementations MAY use a mechanism of their choice to determine the full values.  This section provides an algorithm which is comparatively simple and which implementations are RECOMMENDED to follow. If the epoch bit has the same parity as the current epoch, then implementations SHOULD reconstruct the sequence number by computing the full sequence number which is numerically closest to one plus the sequence number of the highest successfully deprotected record. If the epoch bit has a different parity from the current epoch, then the record is either from a previous epoch or from a future epoch. Implementations SHOULD use the epoch value which would produce a sequence number which is numerically closest to what would be reconstructed for that epoch, as determined by the algorithm in the paragraph above. [[OPEN ISSUE: Say something about how many outstanding packets? Difficulty here is that we have no ACKs to tell us what's outstanding.]] [[OPEN ISSUE: This isn't going to work well with multiple key updates.  There are a number of options here, including limiting to one outstanding update, or saying that you have to use long headers in that case.]] </ins> 4.2. Each DTLS record MUST fit within a single datagram.  In order to


client: The endpoint initiating the DTLS connection. <del> connection: A transport-layer connection between two endpoints. </del>  endpoint: Either the client or server of the connection. handshake: An initial negotiation between client and server that <del> establishes the parameters of their transactions. </del>  peer: An endpoint.  When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of sender: An endpoint that is transmitting records. <del> session: An association between a client and a server resulting from a handshake. </del> server: The endpoint which did not initiate the DTLS connection. CID: Connection ID the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. <del> The received record counter for a session MUST be initialized to zero when that session is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less powerful one than whether the record was deprotected. </del>  Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated <del> sequence number value received on the session.  Records that contain sequence numbers lower than the "left" edge of the window are </del>  rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described

This should make things correct. We might consider getting rid of the term connection or association entirely, but each is problematic: association is a historical term but we also use connection a lot anyway.
It's a shame that "association" is so firmly entrenched. I don't see "association" being used much anyway. Good that you have removed "session" though.

client: The endpoint initiating the DTLS connection.  <ins> association: Shared state between two endpoints established with a DTLS handshake. connection: Synonym for association. </ins> endpoint: Either the client or server of the connection. handshake: An initial negotiation between client and server that  <ins> establishes the parameters of the connection. </ins> peer: An endpoint.  When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of sender: An endpoint that is transmitting records.  server: The endpoint which did not initiate the DTLS connection. CID: Connection ID the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303.  <ins> The received record counter for an association MUST be initialized to zero when that association is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less powerful one than whether the record was deprotected. </ins> Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated  <ins> sequence number value received on the association.  Records that contain sequence numbers lower than the "left" edge of the window are </ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described


Using these reserved epoch values a receiver knows what cipher state has been used to encrypt and integrity protect a message. <del> Implementations that receive a payload with an epoch value for which no corresponding cipher state can be determined MUST generate a "unexpected_message" alert.  For example, if a client incorrectly uses epoch value 5 when sending early application data in a 0-RTT exchange.  A server will not be able to compute the appropriate keys and will therefore have to respond with an alert. </del>  Note that epoch values do not wrap.  If a DTLS implementation would need to wrap the epoch value, it MUST terminate the connection.

What was the motivation for this change?
The idea was to bring us in line with the normal handling for invalid records, which is to ignore them rather than send an alert and tear things down. DTLS associations are supposed to be robust against injected packets. I suspect that there is also some remnant of the previous state of affairs when just incrementing the epoch was all that was needed to generate new keys, as opposed to requiring KeyUpdate+ACK, though that's not directly related to making this change.
Flagging as consensus-needed.

Using these reserved epoch values a receiver knows what cipher state has been used to encrypt and integrity protect a message.  <ins> Implementations that receive a record with an epoch value for which no corresponding cipher state can be determined SHOULD handle it as a record which fails deprotection. </ins> Note that epoch values do not wrap.  If a DTLS implementation would need to wrap the epoch value, it MUST terminate the connection.


handshake and not dataflow, the effect on congestion should be minimal. <del> Implementations SHOULD retain the current timer value until a transmission without loss occurs, at which time 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. </del>  5.7.3.

This says to reset when you get a transmission without loss, but I actually think this is potentially too conservative and we should just reset on every "first" transmission.

handshake and not dataflow, the effect on congestion should be minimal.  <ins> Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted, at which time 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. </ins> 5.7.3.


as possible.  Endpoints MUST NOT send a RequestConnectionId message when an existing request is still unfulfilled; this implies that endpoints needs to request new CIDs well in advance.  An endpoint MAY <del> ignore requests, which it considers excessive (though they MUST be acknowledged as usual). </del>  Endpoints MUST NOT send either of these messages if they did not negotiate a CID.  If an implementation receives these messages when reserve the content type range 32-63 so that content types in this range are not allocated.  IANA is requested to allocate two values in the "TLS Handshake Type" registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for

Fix a deadlock identified by NAME This seems like it sets up a deadlock scenario. Consider peers A and B; A sends RequestConnectionId with num_cids=200 and B considers this request excessive, so ACKs it but sends no NewConnectionId in response. A is prohibited from sending another RequestConnection Id to indicate that it really needs new CIDs, since the requested 200 have not arrived yet; thus, B could end up not sending any NewConnectionIds even though A is essentially blocking on getting them. Unless "unfulfilled" is supposed to mean "not ACKed"?
NAME
Done.

as possible.  Endpoints MUST NOT send a RequestConnectionId message when an existing request is still unfulfilled; this implies that endpoints needs to request new CIDs well in advance.  An endpoint MAY  <ins> handle requests, which it considers excessive, by responding with a NewConnectionId message containing fewer than num_cid CIDs, including no CIDs at all.  Endpoints MAY handle an excessive number of RequestConnectionId messages by terminating the connection using a "too_many_cids_requested" (alert number 52) alert. </ins> Endpoints MUST NOT send either of these messages if they did not negotiate a CID.  If an implementation receives these messages when reserve the content type range 32-63 so that content types in this range are not allocated. <ins> IANA is requested to allocate "the too_many_cids_requested" alert in the "TLS Alerts" registry with value 52. </ins> IANA is requested to allocate two values in the "TLS Handshake Type" registry, defined in TLS13, for RequestConnectionId (TBD), and NewConnectionId (TBD), as defined in this document.  The value for


5.6. <del> DTLS messages are grouped into a series of message flights, according to the diagrams below. </del>  <del> Note: The application data sent by the client is not included in the timeout and retransmission calculation. </del>  5.7.

NAME I merged this. Any chance you want to send a PR or do you want me to?
I'm not in a great spot to make a PR at the moment; please go ahead.
I just fixed this in the main branch.
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed
Thanks, this addresses the issues I had raised for this section. (It's perhaps a little janky to have just a box with "Flight" for each one, but I don't have any better ideas, so we should probably roll with it!)

5.6.  <ins> DTLS handshake messages are grouped into a series of message flights. A flight starts with the handshake message transmission of one peer and ends with the expected response from the other peer.  Table tab- flights contains a complete list of message combinations that consitute flights. </ins>  <ins> Remarks: The HelloRetryRequest shown in (1) is an optional message sent by the server. The ACK message is sent by a client in response to a NewSessionTicket message from the server (as noted in (3)) or sent by a server in response to receipt of flight (2).  In those cases it represent a flight on its own. Below are several example message exchange illustrating the flight concept. </ins> 5.7.


6. The following is an example of a handshake with lost packets and <del> retransmissions. </del>  6.1.

Based on review from Ben: Section 6 Figure 11 seems to show that the initial ServerHello has messageseq=1, but §5.2 says that "[t]he first message each side transmits in each association always has messageseq = 0". Which one is it? (A change here would affect all the server's messages except the final ACK.)
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed

6. The following is an example of a handshake with lost packets and  <ins> retransmissions.  Note that the client sends an empty ACK message because it can only acknowledge Record 1 sent by the server once it has processed messages in Record 0 needed to establish epoch 2 keys, which are needed to encrypt to decrypt messages found in Record 1. ack-msg provides the necessary background details for this interaction. </ins> 6.1.


The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of <del> record 2 (containing the NewSessionTicket message) and if it is not </del>  sent the server will continue retransmission of the NewSessionTicket indefinitely until its transmission cap is reached.

Ben wrote: The use of the ACK for the second case is mandatory for the proper functioning of the protocol. For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of record 2 (containing the NewSessionTicket message) and if it is not The records in Figure 12 are not labeled (anymore?).
Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples" It's 0. I think this example may have had an HRR. Will fix. Filed under "need to fix examples" Filed under "need to fix examples" Filed under "need to fix examples"
NAME can you take these?
PRs for the example updates are URL URL URL
Fixed

The use of the ACK for the second case is mandatory for the proper functioning of the protocol.  For instance, the ACK message sent by the client in Figure 12, acknowledges receipt and processing of  <ins> record 4 (containing the NewSessionTicket message) and if it is not </ins> sent the server will continue retransmission of the NewSessionTicket indefinitely until its transmission cap is reached.


The C bit (0x10) is set if the Connection ID is present. The S bit (0x08) indicates the size of the sequence number.  0 <del> means an 8-bit sequence number, 1 means 16-bit. </del>  The L bit (0x04) is set if the length is present. level transport.  In this case it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram.  Omitting the length field MUST only be used for the last <del> record in a datagram. </del>  If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from

Andy Cunningham wrote Text would not hurt in the draft to explain this.
Chairs, please opine on whether this should get confirmed on the list.

The C bit (0x10) is set if the Connection ID is present. The S bit (0x08) indicates the size of the sequence number.  0  <ins> means an 8-bit sequence number, 1 means 16-bit.  Implementations MAY mix sequence numbers of different lengths on the same connection. </ins> The L bit (0x04) is set if the length is present. level transport.  In this case it is not possible to have multiple DTLSCiphertext format records without length fields in the same datagram.  Omitting the length field MUST only be used for the last  <ins> record in a datagram.  Implementations MAY mix records with and without length fields on the same connection. </ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from


The three high bits of the first byte of the DTLSCiphertext header are set to 001.  This ensures that the value will fit within the DTLS region when multiplexing is performed as described in <del> RFC7983. </del>  The C bit (0x10) is set if the Connection ID is present.

…
I don't.
It would also be good to add a note on how we tell the difference between DTLS 1.2 and 1.3. Version information is carried in various places and due to the use of the CID the multiplexing got more complex between 1.2 and 1.3.
This WFM

The three high bits of the first byte of the DTLSCiphertext header are set to 001.  This ensures that the value will fit within the DTLS region when multiplexing is performed as described in  <ins> RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only possible when connection IDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </ins> The C bit (0x10) is set if the Connection ID is present.


RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only <del> possible when connection IDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </del>  The C bit (0x10) is set if the Connection ID is present. to invalid records by terminating the connection. The security and privacy properties of the CID for DTLS 1.3 builds on <del> top of what is described in I-D.ietf-tls-dtls-connection-id.  There are, however, several improvements: </del>  The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with

In both versions of DTLS we have to do the extension negotiation because you have to agree on the CID values. In both versions we have to carry the CID in the record layer (if the CID is used). The way we incorporated the CID into the headers is different between the different versions. In DTLS 1.3 we have this variable length header and in DTLS 1.2 we don't. There are also privacy differences.
I'm inclined not to add anything here. If you feel strongly maybe you could provide a PR?
I think the privacy differences (and ability to change values over the lifetime of an association, e.g., when roaming) are probably worth mentioning. NAME do you plan to write some text? If not I can try to squeeze it in.
PR is available at
Fixed in . Closing.
LGTM

RFC7983.  It also ensures that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2 records is possible when they are carried on the same host/port quartet; such multiplexing is only  <ins> possible when CIDs I-D.ietf-tls-dtls-connection-id are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25). </ins> The C bit (0x10) is set if the Connection ID is present. to invalid records by terminating the connection. The security and privacy properties of the CID for DTLS 1.3 builds on  <ins> top of what is described for DTLS 1.2 in I-D.ietf-tls-dtls- connection-id.  There are, however, several differences: In both versions of DTLS extension negotiation is used to agree on the use of the CID feature and the CID values.  In both versions the CID is carried in the DTLS record header (if negotiated). However, the way the CID is included in the record header differs between the two versions. </ins> The use of the Post-Handshake message allows the client and the server to update their CIDs and those values are exchanged with


4.1. <del> Implementations can distinguish the two header formats by examining the first byte: </del>  If the first byte is alert(21), handshake(22), or ack(proposed, 26), the record MUST be interpreted as a DTLSPlaintext record. Otherwise, the record MUST be rejected as if it had failed deprotection, as described in handling-invalid-records.  4.2. DTLS uses an explicit or partly explicit sequence number, rather than

I have re-drawn the figure to take Ekr's comments into account. I hope the new figure is better.
LGTM

4.1.  <ins> DTLS 1.3 uses a variable length record format and hence the demultiplexing process is more complex since more header formats need to be distinguished.  Implementations can demultiplex DTLS 1.3 records by examining the first byte as follows: </ins> If the first byte is alert(21), handshake(22), or ack(proposed, 26), the record MUST be interpreted as a DTLSPlaintext record. Otherwise, the record MUST be rejected as if it had failed deprotection, as described in handling-invalid-records. <ins> demux shows this demultiplexing procedure graphically taking DTLS 1.3 and earlier versions of DTLS into account. </ins> 4.2. DTLS uses an explicit or partly explicit sequence number, rather than


Same as for TLS 1.3. <del> Same as for TLS 1.3. </del>  A DTLS 1.3-only client MUST set the legacy_cookie field to zero length.  If a DTLS 1.3 ClientHello is received with any other

It is not the same as TLS 1.3, as previously stated, because DTLS 1.3 does not support the compatibility mode.
It seems a natural consequence of not having compatibility mode, but is probably worth running by the list just to cover all bases.

Same as for TLS 1.3.  <ins> Versions of TLS and DTLS before version 1.3 supported a "session resumption" feature which has been merged with pre-shared keys in version 1.3.  A client which has a cached session ID set by a pre- DTLS 1.3 server SHOULD set this field to that value.  Otherwise, it MUST be set as a zero-length vector (i.e., a zero-valued single byte length field). </ins> A DTLS 1.3-only client MUST set the legacy_cookie field to zero length.  If a DTLS 1.3 ClientHello is received with any other


Each DTLS record contains a sequence number to provide replay protection.  Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 <del> of RFC4303. The received record counter for an association MUST be initialized to zero when that association is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number.  Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less </del>  powerful one than whether the record was deprotected. Duplicates are rejected through the use of a sliding receive window. receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated <del> sequence number value received on the association.  Records that contain sequence numbers lower than the "left" edge of the window are </del>  rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described

It gets reset each time the epoch does. Don't talk about values as being scoped only per association.

Each DTLS record contains a sequence number to provide replay protection.  Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3  <ins> of RFC4303.  Because each epoch resets the sequence number space, a separate sliding window is needed for each epoch. The received record counter for an epoch MUST be initialized to zero when that epoch is first used.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received in that epoch during the lifetime of the association.  This check SHOULD happen after deprotecting the record; otherwise the record discard might itself serve as a timing channel for the record number. Note that computing the full record number from the partial is still a potential timing channel for the record number, though a less </ins> powerful one than whether the record was deprotected. Duplicates are rejected through the use of a sliding receive window. receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated  <ins> sequence number value received in the epoch.  Records that contain sequence numbers lower than the "left" edge of the window are </ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described


are not the next expected message. During the handshake, ACKs only cover the current outstanding flight <del> (this is possible because DTLS is generally a lockstep protocol). Thus, an ACK from the server would not cover both the ClientHello and the client's Certificate.  Implementations can accomplish this by </del>  clearing their ACK list upon receiving the start of the next flight. After the handshake, ACKs SHOULD be sent once for each received and

Clarify that being scoped to the current flight goes hand in hand with the implicit ACK behavior for an entire flight.

are not the next expected message. During the handshake, ACKs only cover the current outstanding flight  <ins> (this is possible because DTLS is generally a lockstep protocol).  In particular, receiving a message from a handshake flight implicitly acknowledges all messages from the previous flight(s).  Accordingly, an ACK from the server would not cover both the ClientHello and the client's Certificate, because the ClientHello and client Certificate are in different flights.  Implementations can accomplish this by </ins> clearing their ACK list upon receiving the start of the next flight. After the handshake, ACKs SHOULD be sent once for each received and


Clients MUST be prepared to do a cookie exchange with every handshake. <del> DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some reachability test; no such test is defined in this specification.  Even with such a test, an active on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </del>  With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection.  The security and privacy properties of the CID for DTLS 1.3 builds on top of what is described for DTLS 1.2 in I-D.ietf-tls-dtls- connection-id.  There are, however, several differences:

Discuss the properties needed of cookies and some ancillary operational procedures, as well as mentioning that the DTLS record replay protection mechanism and 0-RTT replay protection mechanism play different roles and cannot substitute for each other.

Clients MUST be prepared to do a cookie exchange with every handshake.  <ins> Some key properties required of the cookie for the cookie-exchange mechanism to be functional are described in Section 3.3 of RFC2522: the cookie MUST depend on the specific parties (i.e., 5-tuple) it MUST NOT be possible for anyone other than the issuing entity to generate cookies that are accepted as valid by that entity. This typically entails the use of a keyed MAC and secret key. cookie generation and verification are triggered by unauthenticated parties, and as such their resource consumption needs to be restrained in order to avoid having the cookie- exchange mechanism itself serve as a DoS vector. When cookies are generated using a keyed MAC (such as HMAC with a cryptographic hash function), it should be possible to rotate the associated secret key, so that temporary compromise of the key does not permanently compromise the integrity of the cookie-exchange mechanism.  Though this secret is not as high-value as, e.g., a session-ticket-encryption key, rotating the cookie-generation key on a similar timescale would ensure that the key-rotation functionality is exercised regularly and thus in working order. The cookie exchange provides address validation during the initial handshake.  DTLS with connection IDs allow for endpoint addresses to change during the association; any such updated addresses are not covered by the cookie exchange during the handshake.  DTLS implementations MUST NOT update the address they send to in response to packets from a different address unless they first perform some reachability test; no such test is defined in this specification. Even with such a test, an active on-path adversary can also black- hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </ins> With the exception of order protection and non-replayability, the security guarantees for DTLS 1.3 are the same as TLS 1.3.  While TLS Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection. <ins> TLS 1.3 requires replay protection for 0-RTT data (or rather, for connections that use 0-RTT data; see Section 8 of TLS13).  DTLS provides an optional per-record replay-protection mechanism, since datagram protocols are inherently subject to message reordering and replay.  These two replay-protection mechanisms are orthogonal, and neither mechanism meets the requirements for the other. </ins> The security and privacy properties of the CID for DTLS 1.3 builds on top of what is described for DTLS 1.2 in I-D.ietf-tls-dtls- connection-id.  There are, however, several differences:


example if many instances of a DTLS time out early and retransmit too quickly on a congested link. <del> Unless implementations have extra information about the round trip time, implementations SHOULD use an initial timer value of 1000 ms and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 RFC6298 maximum).  Application specific profiles, MAY recommend shorter or longer timer values.  For instance: </del>  Profiles for specific deployment environments, such as in low- power, multi-hop mesh network as used in some Internet of Things

Change the default retransmission timer to 1s and allow people to do otherwise if they have side knowledge. Cap any given flight to 10 recordsDon't re-set the timer to the initial value but to 1.5 times the measured RTT. A bunch more clarity about the reliability algorithms and timers (including changing reset to re-arm)
Thanks for this document -- badly needed and easy to read. Thanks also to Bernard Adoba for his recent tsvart review. I support his comments. COMMENTS: Sec 2. It might be useful to introduce the term "epoch" in the glossary, for those who read this front to back. Sec 4.2.3: "The encrypted sequence number is computed by XORing the leading bytes of the Mask with the sequence number. Decryption is accomplished by the same process." The text is unclear if the XOR is applied to the expanded sequence number or merely the 1-2 octets on the wire. I presume it's the latter, but this should be clarified. Sec 4.2.3: It's implied here that the snkey rotates with the epoch. As this is different from QUIC, it's probably worth spelling out. Sec 5.1 is a bit vague about the amplification limit; why not at least RECOMMEND 3, as we've converged on this elsewhere? Sec 5.1. Reading between the lines, it's clear that the cookie can't be used as address verification across connections in the way that a NEWTOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead. Sec 7.2 "As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight." I think this should be s/entire flight/entire previous flight? Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments." This language appears inconsistent with Figure 12, where Record 1 has not been acknowledged but is also not retransmitted. It appears there is an implied handling of empty ACKs that isn't written down anywhere in Sec 7.2 Sec 9. Should there be any flow control limits on newconnectionid? Or should receivers be free to simply drop CIDs they can't handle? It might be good to specify. Finally, a really weird one. Reading this document and references to connection ID prompted to me to think how QUIC-LB could apply to DTLS. The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL
IMO this addresses my DISCUSS, though I'd like Lars's opinion as well. Although ack-induced retransmissions are not formally reducing the send rate, as ekr pointed out the partial ack in itself will usually clear some data, so the added complexity in further limiting the retransmission is probably too much.

example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  <ins> Unless implementations have deployment-specific and/or external information about the round trip time, implementations SHOULD use an initial timer value of 1000 ms and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 RFC6298 maximum).  Application specific profiles, MAY recommend shorter or longer timer values.  For instance: </ins> Profiles for specific deployment environments, such as in low- power, multi-hop mesh network as used in some Internet of Things


Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs <del> below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively </del>  If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in authentication that both limits the probability of forgery by the same amount and does not expose implementations to the risk of denial of service; see ccm-short.  Therefore, TLS_AES_128_CCM_8_SHA256 MUST <del> NOT used in DTLS without additional safeguards against forgery. </del>  Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on an understanding of any additional forgery protections that are used.

[ section 4.4 ] "respectively" -> "respectively." Could a DTLS implementation packetize to a min-MTU for an IP version and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. [ section 4.5.3 ] "MUST NOT used" -> "MUST NOT be used" [ section 5.8.4 ] "NOT have send" -> "NOT send", I think [ section 6 ] "which are needed to encrypt to decrypt"?
and avoid all pMTU issues? Such a strategy would probably be poor for IPv4 but might be acceptable for IPv6 communications. I'm reluctant to recommend this, given that we know one can run into situations where there is more overhead due to tunnels, etc.

Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs  <ins> below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively. </ins> If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in authentication that both limits the probability of forgery by the same amount and does not expose implementations to the risk of denial of service; see ccm-short.  Therefore, TLS_AES_128_CCM_8_SHA256 MUST  <ins> NOT be used in DTLS without additional safeguards against forgery. </ins> Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on an understanding of any additional forgery protections that are used.


for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message.  The reader is also assumed to be familiar with I-D.ietf-tls-dtls- connection-id as this document applies the CID functionality to DTLS 1.3. demux shows this demultiplexing procedure graphically taking DTLS 1.3 and earlier versions of DTLS into account.  4.2. DTLS uses an explicit or partly explicit sequence number, rather than DTLS messages MAY be fragmented into multiple DTLS records.  Each DTLS record MUST fit within a single datagram.  In order to avoid IP <del> 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.  For more information about PMTU issues see pmtu- issues. </del>  Multiple DTLS records MAY be placed in a single datagram.  Records are encoded consecutively.  The length field from DTLS records upper layer protocol of the error. The DTLS record layer SHOULD NOT interfere with upper layer protocols <del> performing PMTU discovery, whether via RFC1191 or RFC4821 mechanisms. In particular: </del>  Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the DF bit The cookie extension is defined in Section 4.2.2 of TLS13.  When sending the initial ClientHello, the client does not have a cookie yet.  In this case, the cookie extension is omitted and the <del> legacy_cookie field in the ClientHello message MUST be set to a zero length vector (i.e., a single zero byte length field). </del>  When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of In the first case the use of the ACK message is optional because the peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight <del> retransmission in previous versions of DTLS.  For instance in the flow shown in dtls-key-update if the client does not send the ACK message when it received record 1 indicating loss of record 0, the entire flight would be retransmitted.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is </del>  recommended. The use of the ACK for the second case is mandatory for the proper the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher <del> Suite Registry. </del>

Francesca says I am uncertain whether this document is the right place to place restrictions on IANA for this purpose beyond what has already been done elsewhere. Maybe there is a chance to do something in the TLS 1.3 update.
I added some text to the PR.
Since got merged, should this issue be closed now?
Thank you for this document. Please find some minor comments below. Francesca section 2. Conventions and Terminology FP: Please spell out that network byte order (most significant byte first) is used throughout the document. Once the client has transmitted the ClientHello message, it expects to see a HelloRetryRequest or a ServerHello from the server. However, if the server's message is lost, the client knows that either the ClientHello or the response from the server has been lost and retransmits. When the server receives the retransmission, it knows to retransmit. FP: It would be good to mention retransmission max times here. /+----------------+ /+-------+--------+ The value for the "DTLS-OK" column is "Y". IANA is requested to reserve the content type range 32-63 so that content types in this range are not allocated. FP: IANA is asked to reserve 32-63, but I could not see any explanation for that. I would like to see it justified in section 4.1 or in the respective IANA section. 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. FP: First time PMTU appears, please expand and add reference. performing PMTU discovery, whether via [RFC1191] or [RFC4821] mechanisms. In particular: FP: I think this is missing areference to RFC 8201 since IPv6 is mentioned below. Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both confidentiality and integrity. That is, limits MUST be specified for the number of packets that can be authenticated and for the number of packets that can fail authentication before a key update is required. Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions. FP: This seems important enough that it should be highlighted for the experts reviewing the registration. I see that URL has a number of notes, maybe that would be enough, or maybe add it (as an update?) to RFC 8447? zero length vector (i.e., a single zero byte length field). FP: I suggest using TLS 1.3 terminology of "zero-length vector (i.e., a zero-valued single byte length field)" flow shown in Figure 11 if the client does not send the ACK message FP: s/11/12
Addressed in
LGTM with some suggested nits

for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message. <ins> DTLS 1.3 uses network byte order (big-endian) format for encoding messages based on the encoding format defined in TLS13 and earlier (D)TLS specifications. </ins> The reader is also assumed to be familiar with I-D.ietf-tls-dtls- connection-id as this document applies the CID functionality to DTLS 1.3. demux shows this demultiplexing procedure graphically taking DTLS 1.3 and earlier versions of DTLS into account. <ins> Note: The optimized DTLS header format shown in cid_hdr, which does not carry the Content Type in the Unified Header format, requires a different demultilexing strategy compared to what was used in previous DTLS versions where the Content Type was conveyed in every record.  As described in demux, the first byte determines how an incoming DTLS record is demultiplexed.  The first 3 bits of the first byte distinguish a DTLS 1.3 encrypted record from record types used in previous DTLS versions and plaintext DTLS 1.3 record types. Hence, the range 32 (0b0010 0000) to 63 (0b0011 1111) needs to be excluded from future allocations by IANA to avoid demultiplexing problems; see iana-considerations. </ins> 4.2. DTLS uses an explicit or partly explicit sequence number, rather than DTLS messages MAY be fragmented into multiple DTLS records.  Each DTLS record MUST fit within a single datagram.  In order to avoid IP  <ins> fragmentation, clients of the DTLS record layer SHOULD <<<<<<< HEAD attempt to size records so that they fit within any PMTU estimates obtained from the record layer.  For more information about PMTU issues see pmtu-issues.  ======= attempt to size records so that they fit within any Path MTU (PMTU) estimates obtained from the record layer.  >>>>>>> hannestschofenig-patch-40 </ins> Multiple DTLS records MAY be placed in a single datagram.  Records are encoded consecutively.  The length field from DTLS records upper layer protocol of the error. The DTLS record layer SHOULD NOT interfere with upper layer protocols  <ins> performing PMTU discovery, whether via RFC1191 and RFC4821 for IPv4 or via RFC8201 for IPv6.  In particular: </ins> Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the DF bit The cookie extension is defined in Section 4.2.2 of TLS13.  When sending the initial ClientHello, the client does not have a cookie yet.  In this case, the cookie extension is omitted and the  <ins> legacy_cookie field in the ClientHello message MUST be set to a zero- length vector (i.e., a zero-valued single byte length field). </ins> When responding to a HelloRetryRequest, the client MUST create a new ClientHello message following the description in Section 4.1.2 of In the first case the use of the ACK message is optional because the peer will retransmit in any case and therefore the ACK just allows for selective retransmission, as opposed to the whole flight  <ins> retransmission in previous versions of DTLS.  When DTLS 1.3 is used in deployments with lossy networks, such as low-power, long range radio networks as well as low-power mesh networks, the use of ACKs is </ins> recommended. The use of the ACK for the second case is mandatory for the proper the "DTLS-OK" columns are "Y". IANA is requested to add this RFC as a reference to the TLS Cipher  <ins> Suite Registry along with the following Note: </ins>


second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest).  5.2. In order to support message loss, reordering, and message

NAME
The text is good for me.
LGTM, but we should confirm on the list.This definitely helps, thanks. It doesn't completely eliminate the possibility of QUIC-LB catastrophic failure, but it makes things way better.

second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). <ins> DTLS clients which do not want to receive a Connection ID SHOULD still offer the "connection_id" extension unless there is an application profile to the contrary.  This permits a server which wants to receive a CID to negotiate one. </ins> 5.2. In order to support message loss, reordering, and message


utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763. <del> TLS cannot be used directly in datagram environments for the following five reasons: </del>  TLS relies on an implicit sequence number on records.  If a record is not received, then the recipient will use the wrong sequence The TLS handshake is a lock-step cryptographic protocol.  Messages must be transmitted and received in a defined order; any other order is an error.  The DTLS handshake includes message sequence <del> numbers to enable reassembly in the correct order in case datagrams are lost or reordered. </del>  During the handshake, messages are implicitly acknowledged by other handshake messages.  Some handshake messages, such as the

== COMMENTS == -- Section 3 -- s/TLS cannot be used directly in datagram environments/TLS cannot be used directly over a datagram transport/ ? [Hannes] DTLS is also used over non-IP-based networks (e.g. LoRaWAN, NB IoT, Bluetooth Smart) and "datagram transport". What would be the right term to describe "environments" that include transport layer protocols like UDP as well as those non-IP-based networks? Bullet 2) s/to enable reassembly in the correct order/to enable reordering/ ? [Hannes] The complete sentence is: " The DTLS handshake includes message sequence numbers to enable reassembly in the correct order in case datagrams are lost or reordered. " I believe that saying sequence numbers enable reassembly in the correct order is correct. -- Section 3.1 -- Should there be a hint to a maximum retry count ? [Hannes] There will be a retry count in an implementation. Do we need to say that if we don't have a number to suggest? Not sure. -- Section 3.3 -- I understand the motivation (and no need to reply), but, sigh... implementing frag/reassembly above the transport layer... [Hannes] Seems to be common these days. Examples: CoAP, and QUIC
I don't think I found the PR to match up with the "pr-exists" label; could I get a pointer?
My bad. URL

utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763.  <ins> TLS cannot be used directly over datagram transports the following five reasons: </ins> TLS relies on an implicit sequence number on records.  If a record is not received, then the recipient will use the wrong sequence The TLS handshake is a lock-step cryptographic protocol.  Messages must be transmitted and received in a defined order; any other order is an error.  The DTLS handshake includes message sequence  <ins> numbers to enable fragmented message reassembly and in-order delivery in case datagrams are lost or reordered. </ins> During the handshake, messages are implicitly acknowledged by other handshake messages.  Some handshake messages, such as the


because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer.  4.5.3. Section 5.5 of TLS TLS13 defines limits on the number of records that

Zaheduzzaman Sarker wrote -> need to add text
I don't actually understand the ask here. Why would it matter?
I believe he wants us to note that when an invalid record is received and silently discarded then it does not impact timers in any way. It would be surprising if it did but do we want to add a sentence about that?
Since we have a dedicated section for "handling invalid records" that does allow for things other than silent discard, it makes sense to mention the lack of effect on timers. "[...] however, an error MAY be logged for diagnostic purposes. In no case does an invalid record affect pending retransmission timers."?
I'm not sure I agree, but I added something.

because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer. <ins> Note that because invalid records are rejected at a layer lower than the handshake state machine, they do not affect pending retransmission timers. </ins> 4.5.3. Section 5.5 of TLS TLS13 defines limits on the number of records that


The following is an example of a handshake with lost packets and retransmissions.  Note that the client sends an empty ACK message <del> because it can only acknowledge Record 1 sent by the server once it </del>  has processed messages in Record 0 needed to establish epoch 2 keys, <del> which are needed to encrypt or decrypt messages found in Record 1. </del>  ack-msg provides the necessary background details for this interaction.  Note: for simplicity we are not re-setting record numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,

The middle two commits should be looked at individually. Optional-ACK can be used (as in Figure 12) to short-circuit the retransmit timer in addition to selective acknowledgment.
(Looks like I still don't understand the kramdown reference behavior.)

The following is an example of a handshake with lost packets and retransmissions.  Note that the client sends an empty ACK message  <ins> because it can only acknowledge Record 2 sent by the server once it </ins> has processed messages in Record 0 needed to establish epoch 2 keys,  <ins> which are needed to encrypt or decrypt messages found in Record 2. </ins> ack-msg provides the necessary background details for this interaction.  Note: for simplicity we are not re-setting record numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,