Subject: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls13-41: (with COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Thu, 25 Mar 2021 06:11:33 -0700

John Scudder has entered the following ballot position for
draft-ietf-tls-dtls13-41: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

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