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

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)

While I did review the document, I'm mostly relying on the SecADs and authors for the deep security review.

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?

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

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,
>               <https://www.rfc-editor.org/info/rfc8446>.
>
>    [TLS13]    Rescorla, E., "The Transport Layer Security (TLS) Protocol
>               Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
>               <https://www.rfc-editor.org/info/rfc8446>.

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,
>               <http://www.ietf.org/internet-drafts/draft-ietf-tls-
>               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
+                                                              +

Thanks for addressing my DISCUSS, and to Gorry Fairhurst and Mark Allman for their advice on this issue.

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