Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc

[Marco Tiloca <[e-mail]>]

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 [e-mail].
>
> Thanks,
> Chris, Joe, & Sean
> _______________________________________________
> TLS mailing list
> [e-mail]
> 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: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se