The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
draft-ietf-tls-dtls13-43

[Ballot comment]
Thank you for the work put into this document. I am afraid that I only had a quick review (lack of time).

Special thanks to Sean Turner for its shepherd review containing many details about the consensus building.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3 --
s/TLS cannot be used directly in datagram environments/TLS cannot be used directly over a datagram transport/ ?

Bullet 2) s/to enable reassembly in the correct order/to enable reordering/ ?

-- Section 3.1 --
Should there be a hint to a maximum retry count ?

-- Section 3.3 --
I understand the motivation (and no need to reply), but, sigh... implementing frag/reassembly above the transport layer...

[Ballot comment]
Thanks for the quick response and update, I've cleared my discuss.

--

Thanks for the well-written document. In particular I thought it was helpful that you noted important divergences from DTLS 1.2 in line and not just at the end.

COMMENTS:

Section 3.1:

I found the explanatory text to be confusing. You start with a figure illustrating a lost HelloRetryRequest. Then you tell me the server maintains a rexmit timer:

  The server also maintains a retransmission timer and retransmits when
  that timer expires.

But then you immediately tell me that it actually doesn’t:

  Note that timeout and retransmission do not apply to the
  HelloRetryRequest since this would require creating state on the
  server.  The HelloRetryRequest is designed to be small enough that it
  will not itself be fragmented, thus avoiding concerns about
  interleaving multiple HelloRetryRequests.

I presume that if I added some more words to this, your intent is that the server maintains a retransmission timer *for messages other than HelloRetryRequest*. As written, it gave me some whiplash.

Section 4.2.1:

  In general,
  implementations SHOULD discard records from earlier epochs, but if
  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.

It seems to me as though “if packet loss causes noticeable problems” is saying either too much, or not enough. Not enough: problems for whom? Noticeable by whom? How is this determined? Do you really mean I’m supposed to work this out dynamically as the text sort-of implies? Too much: if you’re not going to answer the foregoing, maybe don’t taunt me, and omit the clause entirely? Or, possibly a less vague rewrite could be in the nature of “if providing service to an application that is especially sensitive to packet loss”.


NITS:

Section 2:

“The reader is also as to be familiar” s/as/assumed/

Section 11:

  Although the cookie must allow the server to produce the right
  handshake transcript, they

“It” not “they” (agreement in number)

and

  DTLS with connection IDs allow for endpoint addresses to
  change during the association;

“allows” not “allow” (agreement in number)

[Ballot comment]
Section 5.8.2, paragraph 1, comment:
> 5.8.2.  Timer Values

I agree with Martin Duke's DISCUSS position (also on 5.8.3).

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

"Abstract", paragraph 1, nit:
> Abstract

The draft header indicates that this document obsoletes RFC6347, but the
abstract doesn't seem to mention this, which it should.

Section 15.1, paragraph 12, nit:
>    [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
>              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
>              .
>
>    [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
>              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
>              .

These are the same.

Section 15.2, paragraph 4, nit:
>    [DEPRECATE]
>              Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and
>              TLSv1.1", Work in Progress, Internet-Draft, draft-ietf-
>              tls-oldversions-deprecate-12, 21 January 2021,
>                              oldversions-deprecate-12.txt>.

Outdated reference: draft-ietf-tls-oldversions-deprecate has been published as
RFC 8996

Section 4.2.1, paragraph 2, nit:
-    packet loss causes noticeable problems implementations MAY choose to
+    packet loss causes noticeable problems, implementations MAY choose to
+                                          +

Section 5.7, paragraph 2, nit:
-    contains a complete list of message combinations that consitute
+    contains a complete list of message combinations that constitute
+                                                              +

[Ballot discuss]
Section 4.5.2:

  Implementations which choose to generate an alert instead, MUST
  generate error alerts to avoid attacks where the attacker repeatedly
  probes the implementation to see how it responds to various types of
  error.  Note that if DTLS is run over UDP, then any implementation

I just don’t understand this, despite having hopped over to RFC 8446 Sections 6 and 6.2. Is the intention that “error alert” implies closure of the association? That doesn’t seem to be exactly what 8446 says — it says the receiver of the alert closes the connection, but it doesn’t mandate this for the sender (except in the case of “fatal alert” messages, where “fatal” seems like the exception that proves the rule).

It may be that “everyone knows” an error alert is the same as termination, but it’s not obvious in the plain English of the text I reviewed. Or maybe I’m barking up the wrong tree and this isn't what the text quoted above is even driving at.

[Ballot comment]
Thanks for the well-written document. In particular I thought it was helpful that you noted important divergences from DTLS 1.2 in line and not just at the end.

COMMENTS:

Section 3.1:

I found the explanatory text to be confusing. You start with a figure illustrating a lost HelloRetryRequest. Then you tell me the server maintains a rexmit timer:

  The server also maintains a retransmission timer and retransmits when
  that timer expires.

But then you immediately tell me that it actually doesn’t:

  Note that timeout and retransmission do not apply to the
  HelloRetryRequest since this would require creating state on the
  server.  The HelloRetryRequest is designed to be small enough that it
  will not itself be fragmented, thus avoiding concerns about
  interleaving multiple HelloRetryRequests.

I presume that if I added some more words to this, your intent is that the server maintains a retransmission timer *for messages other than HelloRetryRequest*. As written, it gave me some whiplash.

Section 4.2.1:

  In general,
  implementations SHOULD discard records from earlier epochs, but if
  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.

It seems to me as though “if packet loss causes noticeable problems” is saying either too much, or not enough. Not enough: problems for whom? Noticeable by whom? How is this determined? Do you really mean I’m supposed to work this out dynamically as the text sort-of implies? Too much: if you’re not going to answer the foregoing, maybe don’t taunt me, and omit the clause entirely? Or, possibly a less vague rewrite could be in the nature of “if providing service to an application that is especially sensitive to packet loss”.


NITS:

Section 2:

“The reader is also as to be familiar” s/as/assumed/

Section 11:

  Although the cookie must allow the server to produce the right
  handshake transcript, they

“It” not “they” (agreement in number)

and

  DTLS with connection IDs allow for endpoint addresses to
  change during the association;

“allows” not “allow” (agreement in number)

[Ballot discuss]
In Sec 5.8.2, it is a significant change from DTLS 1.2 that the initial timeout is dropping from 1 sec to 100ms, and this is worthy of some discussion. This violation of RFC8961 ought to be explored further. For a client first flight of one packet, it seems unobjectionable. However, I'm less comfortable with a potentially large server first flight, or a client second flight, likely leading to a large spurious retransmission. With large flights, not only is a short timeout more dangerous, but you are more likely to get an ACK in the event of some loss that allows you to shortcut the timer anyway (i.e. the cost of long timeout is smaller)

Relatedly, in section 5.8.3 there is no specific recommendation for a maximum flight size at all. I would think that applications SHOULD have no more than 10 datagrams outstanding unless it has some OOB evidence of available bandwidth on the channel, in keeping with de facto transport best practice.

Finally, I am somewhat concerned that the lack of any window reduction might perform poorly in constrained environments. Granted, doubling the timeout will reduce the rate, but when retransmission is ack-driven there is essentially no reduction of sending rate in response to loss.

I want to emphasize that I am not looking to fully recreate TCP here; some bounds on this behavior would likely be satisfactory.

Here is an example of something that I think would be workable. It is meant to be a starting point for discussion. I've asked for some input from the experts in this area who may feel differently.
- In general, the initial timeout is 100ms.
- The timeout backoff is not reset after successful delivery. This allows the "discovery" in bullet 1 to be safely applied to larger flights.
- For a first flight of > 2 packets, the sender MUST either (a) set the initial timeout to 1 second OR (b) retransmit no more than 2 packets after timeout.
- flights SHOULD be limited to 10 packets
- on timeout or ack-indicated retransmission, no more than half (minimum one) of the flight should be retransmitted

The theory here is that it's responsive to RTTs > 100ms, but small flights can be more aggressive, and large flows are likely to have ack-driven retransmission.

[Ballot comment]
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 sn_key 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 NEW_TOKEN 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 new_connection_id? 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: https://github.com/quicwg/load-balancers/pull/106/files. 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 connection_id 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 connection_id in HelloRetryRequest even if the client didn't offer it. Thoughts?

NITS:
5.2 s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer.

5.7 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.

[Ballot comment]
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."

It is unclear to me from reading this 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 a bit clearer.

Sec 4.2.3: It's implied here that the sn_key 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 NEW_TOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead.

Sec 5.8.2 While the RTO guidance here is inconsistent with RFC8961, the authors have provided largely sufficient justification for doing so, IMIO

NITS:
5.2 s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer.

5.7 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.

[Ballot comment]
Thank you for this document. Please find some minor comments below.

Francesca

1. -----

section 2.  Conventions and Terminology

FP: Please spell out that network byte order (most significant byte first) is used throughout the document.

2. -----

  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.

3. -----

                |                |  /+----------------+\
                | 31 < OCT < 64 -+--> |DTLS Ciphertext |
                |                |    |(header bits    |
                |      else      |    | start with 001)|
                |      |        |  /+-------+--------+\




  26.  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.

4. -----

  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.

5. -----

  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.

6. -----

  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 https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 has a number of notes, maybe that would be enough, or maybe add it (as an update?) to RFC 8447?

7. -----

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)"

8. -----

  flow shown in Figure 11 if the client does not send the ACK message

FP: s/11/12

[Ballot comment]
[ 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"?

[Ballot comment]
This was very well written document. Thanks for this.

Minor observations below-

* Section 3.1 :
  - 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.

is this supposed to mean when the timer expires the client knows either the ClientHello or the response from the server has been lost? the current text does not imply that - the server's message is lost is an interpretation of timer expired event.

  -  The server also maintains a retransmission timer and retransmits when that timer expires.

The way it is written following the previous paragraph, almost made me feel that the server is also maintaining a timer for the client hello. It would be nicer if some text explains the usage of timers at the server to break the continuous read from previous paragraph.

* Section 3.3: I would add a reference to section 4.4.

* Section 4.5.2: I assume the silent discard of invalid records will not impact the timers, is that a valid assumption? if yes, then it would be good if this is clarified in the text.

* Section 5.8.1:

    Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer

This is repeated twice in the section, is there any reason for that?

[Ballot comment]
Hi,

Thanks for this well written document.

A couple of minor suggestions:

1) Although it is clear from the metadata, it might be helpful if the introduction also stated that it obsoletes DTLS 1.2.

2) This document is a set of deltas against TLS 1.3.  Given that it talks about the DTLS 1.1/1.2 documents being deltas in the introduction, I would have also included that information for this document in the introduction rather than in the Terminology and Considerations section.  Initially, having read the introduction I had assumed that it was not going to be deltas.

Regards,
Rob

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-dtls13-41. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the TLS ContentType registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

a single, new ContentType is to be registered as follows:

Value: 26
Description: ack
DTLS-OK: Y
Reference: [ RFC-to-be ]

Second, also in the TLS ContentType registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

values in the range 32-63 inclusive are to be marked Reserved as defined in RFC 8126 and the reference set to [ RFC-to-be ].

Third, in the TLS Alerts registry also on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

a single, new Alert is to be registered as follows:

Value: 52
Description: the too_many_cids_requested
DTLS-OK:
Reference: [ RFC-to-be ]
Comment:

IANA Question --> what should be the entry for DTLS-OK be for this registration?

Fourth, in the TLS Handshake Type registry also on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

two, new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: RequestConnectionId
DTLS-OK: Y
Reference: [ RFC-to-be ]
Comment:

Value: [ TBD-at-Registration ]
Description: NewConnectionId
DTLS-OK: Y
Reference: [ RFC-to-be ]
Comment:

Fifth, in the TLS Cipher Suite registry also on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

[ RFC-to-be ] will be added as a reference to the TLS Cipher Suite registry.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-22):

From: The IESG
To: IETF-Announce
CC: Sean Turner , draft-ietf-tls-dtls13@ietf.org, kaduk@mit.edu, sean@sn3rd.com, tls-chairs@ietf.org, tls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Datagram Transport Layer Security (DTLS) Protocol Version 1.3) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'The Datagram Transport Layer Security
(DTLS) Protocol Version 1.3'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies Version 1.3 of the Datagram Transport Layer
  Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
  to communicate over the Internet in a way that is designed to prevent
  eavesdropping, tampering, and message forgery.

  The DTLS 1.3 protocol is intentionally based on the Transport Layer
  Security (TLS) 1.3 protocol and provides equivalent security
  guarantees with the exception of order protection/non-replayability.
  Datagram semantics of the underlying transport are preserved by the
  DTLS protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8439: ChaCha20 and Poly1305 for IETF Protocols (Informational - IRTF Stream)

# Summary

Sean Turner is the DS.
Ben Kaduk is the AD.

This document defines the DTLS 1.3 protocol, which is intentionally based on the Transport Layer Security (TLS) 1.3 protocol.  DTLS 1.3 provides equivalent as with TLS 1.3 security guarantees with the exception of order protection/non-replayability.

The document is intended for standards track.  This is the appropriate track for a deployed protocol obsoleting its previous version (RFC 6347).


# Review and Consensus

This draft has been discussed at length on the mailing list and at numerous IETF meetings.  As DTLS is based on TLS, much of the discussion already occurred before work began in earnest.  The  DTLS-specific issues, e.g., adding the ACK content type, KeyUpdate mechanism, and DTLS key separation, were discussed both on the mailing list and the at IETF meetings.  There is broad consensus to publish this document.

The draft has been through 3 WGLCs in 11.2018, 10.2019, and 04.2020. The 1st WGLC uncovered only minor editorial changes. A 2nd WGLC was issued to ensure the Connection ID-related changes that were adopted in parallel with draft-ietf-tls-dtls-connection-id; draft-ietf-tls-dtls-connection-id also has WG consensus. As the draft was awaiting AD review, additional GH-PRs were submitted. A 3rd WGLC was issued to ensure those changes had consensus.  The latest version includes agreed text to ban connection IDs, AEAD limits (based on QUIPS workshop findings), state machine duplication for post-handshake messages, and ACK message-related changes. Note that the AEAD limits included are based on discussions from the QUIC mailing list.

Do not be alarmed by the long interval between the 1st and 2nd WGLC. The WG purposely built a 6-month long pause into the process to allow for security reviewers as well as implementer review.

No directorate reviews done to date, and there is no real need for any kind of special directorate reviews.

I have no specific concerns about this draft as almost all of the blood letting occurred during TLS 1.3.


# Intellectual Property

I confirmed with each author that to their direct, personal knowledge of any IPR related to this draft has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

IANA considerations are correct.  The is one content type defined and two handshake types.  For these types of registrations IANA needs two things: a name and a DTLS-OK column value.  The registrations in this draft include both.

DOWNREF:
- Please call out a DOWNREF to RFC 8439 (ChaCha20 and Poly1305 for IETF Protocols) !!!

IDNits complains about obsoleted informational references.  Please ignore these nits as these references are intentional; they provide historical references to the earliest version of the protocol.

# Summary

Sean Turner is the DS.
Ben Kaduk is the AD.

This document defines the DTLS 1.3 protocol, which is intentionally based on the Transport Layer Security (TLS) 1.3 protocol.  DTLS 1.3 provides equivalent as with TLS 1.3 security guarantees with the exception of order protection/non-replayability.

The document is intended for standards track.  This is the appropriate track for a deployed protocol obsoleting its previous version (RFC 6347).


# Review and Consensus

This draft has been discussed at length on the mailing list and at numerous IETF meetings.  As DTLS is based on TLS, much of the discussion already occurred before work began in earnest.  The  DTLS-specific issues, e.g., adding the ACK content type, KeyUpdate mechanism, and DTLS key separation, were discussed both on the mailing list and the at IETF meetings.  There is broad consensus to publish this document.

The draft has been through 3 WGLCs in 11.2018, 10.2019, and 04.2020. The 1st WGLC uncovered only minor editorial changes. A 2nd WGLC was issued to ensure the Connection ID-related changes that were adopted in parallel with draft-ietf-tls-dtls-connection-id; draft-ietf-tls-dtls-connection-id also has WG consensus. As the draft was awaiting AD review, additional GH-PRs were submitted. A 3rd WGLC was issued to ensure those changes had consensus.  The latest version includes agreed text to ban connection IDs, AEAD limits (based on QUIPS workshop findings), state machine duplication for post-handshake messages, and ACK message-related changes. Note that the AEAD limits included are based on discussions from the QUIC mailing list.

Do not be alarmed by the long interval between the 1st and 2nd WGLC. The WG purposely built a 6-month long pause into the process to allow for security reviewers as well as implementer review.

No directorate reviews done to date, and there is no real need for any kind of special directorate reviews.

I have no specific concerns about this draft as almost all of the blood letting occurred during TLS 1.3.


# Intellectual Property

I confirmed with each author that to their direct, personal knowledge of any IPR related to this draft has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

IANA considerations are correct.  The is one content type defined and two handshake types.  For these types of registrations IANA needs two things: a name and a DTLS-OK column value.  The registrations in this draft include both.

DOWNREF:
- Please call out a DOWNREF to RFC 8439 (ChaCha20 and Poly1305 for IETF Protocols) !!!

IDNits complains about obsoleted informational references.  Please ignore these nits as these references are intentional; they provide historical references to the earliest version of the protocol.

# Summary

Sean Turner is the DS.
Ben Kaduk is the AD.

This document defines the DTLS 1.3 protocol, which is intentionally based on the Transport Layer Security (TLS) 1.3 protocol.  DTLS 1.3 provides equivalent as with TLS 1.3 security guarantees with the exception of order protection/non-replayability.

The document is intended for standards track.  This is the appropriate track for a deployed protocol obsoleting its previous version (RFC 6347).


# Review and Consensus

This draft has been discussed at length on the mailing list and at numerous IETF meetings.  As DTLS is based on TLS, much of the discussion already occurred before work began in earnest.  The  DTLS-specific issues, e.g., adding the ACK content type, KeyUpdate mechanism, and DTLS key separation, were discussed both on the mailing list and the at IETF meetings.  There is broad consensus to publish this document.

The draft has been through 3 WGLCs in 11.2018, 10.2019, and 04.2020. The 1st WGLC uncovered only minor editorial changes. A 2nd WGLC was issued to ensure the Connection ID-related changes that were adopted in parallel with draft-ietf-tls-dtls-connection-id; draft-ietf-tls-dtls-connection-id also has WG consensus. As the draft was awaiting AD review, additional GH-PRs were submitted. A 3rd WGLC was issued to ensure those changes had consensus.  The latest version includes agreed text to ban connection IDs, AEAD limits (based on QUIPS workshop findings), state machine duplication for post-handshake messages, and ACK message-related changes.

Do not be alarmed by the long interval between the 1st and 2nd WGLC. The WG purposely built a 6-month long pause into the process to allow for security reviewers as well as implementer review.

No directorate reviews done to date, and there is no real need for any kind of special directorate reviews.

I have no specific concerns about this draft as almost all of the blood letting occurred during TLS 1.3.


# Intellectual Property

I confirmed with each author that to their direct, personal knowledge of any IPR related to this draft has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

IANA considerations are correct.  The is one content type defined and two handshake types.  For these types of registrations IANA needs two things: a name and a DTLS-OK column value.  The registrations in this draft include both.

DOWNREF:
- Please call out a DOWNREF to RFC 8439 (ChaCha20 and Poly1305 for IETF Protocols) !!!

IDNits complains about obsoleted informational references.  Please ignore these nits as these references are intentional; they provide historical references to the earliest version of the protocol.

This WGLC is to confirm the changes from -34 to -37. Two 2119-language changes were introduced in -35 and these changes need to be confirmed on-list.

# Summary

Sean Turner is the Shepherd.
Ben Kaduk is the Area Director.

This document defines the DTLS 1.3 protocol, which is intentionally based on the Transport Layer Security (TLS) 1.3 protocol.  DTLS 1.3 provides equivalent as with TLS 1.3 security guarantees with the exception of order protection/non-replayability.

The document is intended for standards track.  This is the appropriate track for a deployed protocol obsoleting its previous version (RFC 6347).


# Review and Consensus

I would characterize the consensus as solid.

This draft has been discussed at length on the mailing list and at numerous IETF meetings.  As DTLS is based on TLS, much of the discussion already occurred before work began in earnest.  The  DTLS-specific issues, e.g., adding the ACK content type, KeyUpdate mechanism, and DTLS key separation, were discussed both on the mailing list and the at IETF meetings.  There is broad consensus to publish this document.

Please note that we purposely built a 6-month long pause into the process to allow for security reviewers as well as implementater review.

No directorate reviews done to date, and there is no real need for any kind of special directorate reviews.

I have no specific concerns about this draft as all of the blood letting occurred during TLS 1.3.


# Intellectual Property

I confirmed with each author that to their direct, personal knowledge of any IPR related to this draft has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

*** IANA Considerations will be correct once the DTLS-OK column PR is incorporated.

IANA considerations are correct.  The is one content type defined and two handshake types.  For these types of registrations IANA needs two things, a name (possibly a suggest value) and a DTLS-OK column value.  The registrations in this draft include both.

DOWNREF:
- Please call out a DOWNREF to RFC 8439 (ChaCha20 and Poly1305 for IETF Protocols)

IDNits complains about obsoleted informational references.  Please ignore these nits as these references are intentional; they provide historical references to the earliest version of the protocol.

# Summary

Sean Turner is the Shepherd.
Ben Kaduk is the Area Director.

This document defines the DTLS 1.3 protocol, which is intentionally based on the Transport Layer Security (TLS) 1.3 protocol.  DTLS 1.3 provides equivalent as with TLS 1.3 security guarantees with the exception of order protection/non-replayability.

The document is intended for standards track.  This is the appropriate track for a deployed protocol obsoleting its previous version (RFC 6347).


# Review and Consensus

I would characterize the consensus as solid.

This draft has been discussed at length on the mailing list and at numerous IETF meetings.  As DTLS is based on TLS, much of the discussion already occurred before work began in earnest.  The  DTLS-specific issues, e.g., adding the ACK content type, KeyUpdate mechanism, and DTLS key separation, were discussed both on the mailing list and the at IETF meetings.  There is broad consensus to publish this document.

Please note that we purposely built a 6-month long pause into the process to allow for security reviewers as well as implementater review.

No directorate reviews done to date, and there is no real need for any kind of special directorate reviews.

I have no specific concerns about this draft as all of the blood letting occurred during TLS 1.3.


# Intellectual Property

I confirmed with each author that to their direct, personal knowledge of any IPR related to this draft has already been disclosed, in conformance with BCPs 78 and 79.

# Other Points

*** IANA Considerations will be correct once the DTLS-OK column PR is incorporated.

IANA considerations are correct.  The is one content type defined and two handshake types.  For these types of registrations IANA needs two things, a name (possibly a suggest value) and a DTLS-OK column value.  The registrations in this draft include both.

DOWNREF:
- Please call out a DOWNREF to RFC 8439 (ChaCha20 and Poly1305 for IETF Protocols)

IDNits complains about obsoleted informational references.  Please ignore these nits as these references are intentional; they provide historical references to the earliest version of the protocol.