Marco Tiloca's WGLC comments

[thomas-fossati]

https://mailarchive.ietf.org/arch/msg/tls/a4kehk6vmKuqB40yJMfOKbPOv8w/

---

Comments

Section 1

• "selecting a security context of an incoming DTLS record"

  I think you mean "selecting a security context for processing an incoming DTLS record"

• I think that the text would read better if you swap the two following blocks of text:

  "A CID is an identifier carried in ... for DTLS 1.3."

  and

  "Without CID, if the ... and negotiated"

  hence introducing the concept of CID before using it.

• "Section 6 of [RFC9146] describes how ..."

  Aren’t such considerations applicable also to DTLS 1.3? If so, it’s worth mentioning.

• "This is done in order to provide more confidence to the receiving peer that the sending peer is reachable at the indicated address and port."

  I guess you mean: "the latest indicated address and port"

• "that a peer is still in possession of its address"

  Similar to the previous comment, this can be: "is still reachable to its last known address"

• "if RRC has been successfully negotiated"

  It should be: "if the use of RRC has been successfully negotiated", also consistent with the beginning of Section 3.

• That last paragraph uses both "peer" and "endpoint", apparently interchangeably. Is there any reason to not use only one of the two words? Earlier in the section, only "peer" is used.

  Later in the document, "endpoint" is also used. Maybe add a note in Section 2 about the equivalence of the two terms?

Section 4

• "Implementations MUST be able to parse and ignore messages with an unknown msg_type."

  Right, at the same time the intention should be that, if a peer uses RRC, then it MUST support all the three message types defined in this document. It's worth stating it explicitly.

Section 5

• "that has the source address of the enclosing UDP datagram different from the one currently associated"

  Couldn't (also) the source port number have changed? If so, I think you mean: "that has the source address and/or source port number of the enclosing UDP datagram different from what is currently associated"

• "the receiver SHOULD perform a return routability check as described in Section 7, unless an application layer specific address validation mechanism can be triggered instead."

  As an example of alternative mechanism that can be triggered, it's worth mentioning RFC 9175, which describes the exchange of a CoAP response and a follow-up CoAP request, both including a CoAP Echo option with value set by the server sending the response.

  Besides allowing the server to assert the freshness of the follow-up request, this exchange provides validation of the claimed address of the client sending the request.

Section 6.1

• "(e.g., a CoAP server returning an MTU's worth of data from a 20-bytes GET request)

  It's worth referring to RFC 7252 and to https://datatracker.ietf.org/doc/draft-irtf-t2trg-amplification-attacks/

Section 6.2

• In figure 5, the arrow for message 2 (path-drop) should not be bidirectional, but rather only from the sender to the receiver.

Sections 7.1 and 7.2

• s/The receiver creates/The receiver, i.e., the initiator creates

• s/The peer endpoint/The other peer, i.e., the responder,

Section 7.4

• I think that another requirement should be that the initiator MUST NOT act on more than one valid path_response or path_drop message for each path_challenge message that it has sent.

Section 10

• You will need to add a new subsection that provides expert review instructions, for the Designated Experts assigned to the new subregistry defined in Section 10.3.

Nits

Section 1

• s/i.e./i.e.,
• s/a variety reasons/a variety of reasons

Section 4

• s/path_response and/path_response, and
• s/a 8-byte/an 8-byte

Section 6

• s/Note that in general,/Note that, in general,
• s/verification due to/verification, due to
• s/Figure 2: Attackers capabilities/Figure 2: Attacker's capabilities

Section 6.1

• s/injecting and racing it/injecting, and racing it

Section 7

• s/concerns, the need/concerns, and the need

Section 7.2

• s/i.e./i.e.,

Section 8

• s/In the example/In the example of
• s/as well as the RRC/as well as for the use of the RRC
• s/been established the/been established, the
• s/interaction the IP/interaction, the IP

[thomas-fossati]

CC: Marco

[thomas-fossati]

Addressed in #63

Marco confirmed on the list that he was OK with the proposed changes: https://mailarchive.ietf.org/arch/msg/tls/uimyEYq0dOGFmWCuUPbbX3ZgTp8/