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