[TLS] Francesca Palombini's Yes on draft-ietf-tls-dtls13-41: (with COMMENT)

[Francesca Palombini via Datatracker <[e-mail]>]

Francesca Palombini has entered the following ballot position for
draft-ietf-tls-dtls13-41: Yes

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

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