[TLS] John Scudder's Discuss on draft-ietf-tls-dtls13-41: (with DISCUSS and COMMENT)

[John Scudder via Datatracker <[e-mail]>]

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

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/



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


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