Hi all, Thanks for this document! I think it's good and well written.
Please see below some minor comments. Best, /Marco ==================== [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 On 2023-09-18 23:03, Sean Turner wrote:
This email starts the 2nd working group last call for "Return Routability Check for DTLS 1.2 and DTLS 1.3” I-D, located here: https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tls-dtls-rrc%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0debb4c78dbe430d7e1c08dbb88ad9d4%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638306678725310227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SvzuTSLXUepdgCRou2%2FSpKIEEseKkgeW2FtxK2USDmU%3D&reserved=0 The WG Last Call will end 3 October 2023 @ 2359 UTC. Please review the I-D and submit issues and pull requests via the GitHub repository that can be found at: https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Fdtls-rrc&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0debb4c78dbe430d7e1c08dbb88ad9d4%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638306678725310227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3oMiSlJbKPepw82mGmzWcCzevuMJcjmOotSu4c6k92c%3D&reserved=0 Alternatively, you can also send your comments to...@ietf.org. Thanks, Chris, Joe, & Sean _______________________________________________ TLS mailing list TLS@ietf.org https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C01%7Cmarco.tiloca%40ri.se%7C0debb4c78dbe430d7e1c08dbb88ad9d4%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638306678725310227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OIpfBDR8I10rXFa6xzI3X%2FhqfTw10S1EDQGs%2BzuCJeY%3D&reserved=0
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
