Hi Marco, Thanks very much for the thorough review. Really appreciate it.
Your comments are tracked at https://github.com/tlswg/dtls-rrc/issues/62 Cheers, thank you! On Tue, 3 Oct 2023 at 15:50, Marco Tiloca <marco.tiloca=40ri...@dmarc.ietf.org> wrote: > > 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 tls@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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
