Dear Rebecca and Sandy, Authors,
On Fri, 13 Feb 2026 at 18:56, <[email protected]> wrote: > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] Because this document updates RFC 9147, please > review the errata reported for RFC 9147 > (https://www.rfc-editor.org/errata/rfc9147) > and let us know if you confirm our opinion that none of them > are relevant to the content of this document. > --> Confirmed. > 2) <!-- [rfced] Please note that the title of the document has been updated > as follows. > > Original: > Return Routability Check for DTLS 1.2 and DTLS 1.3 > > Current: > Return Routability Check for DTLS 1.2 and 1.3 > --> OK > 3) <!-- [rfced] Is this sentence in the abstract correct as is, or should > it include the word "subprotocol" (which is used in a similar sentence in > the Introduction)? > > Original: > This document specifies a return routability check for use in context > of the Connection ID (CID) construct for the Datagram Transport Layer > Security (DTLS) protocol versions 1.2 and 1.3. > > Current: > This document specifies a Return Routability Check (RRC) for use in > the context of the Connection ID (CID) construct for the Datagram > Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. > > Perhaps: > This document specifies a Return Routability Check (RRC) subprotocol for > use in the context of the Connection ID (CID) construct for the Datagram > Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. > --> Both Current and Perhaps are correct. Perhaps the "Perhaps" is slightly better. > 4) <!-- [rfced] Should "return routability check" here be updated to "basic > return routability check" in these instances in Section 5.2? > > Original: > * When a return_routability_check message of type path_drop was > received, the initiator MUST perform a return routability > check on the observed new address, as described in > Section 5.1. > ... > 5. If T expires the peer address binding is not updated. In this > case, the initiator MUST perform a return routability check on > the observed new address, as described in Section 5.1. > > Perhaps: > * When a return_routability_check message of type path_drop was > received, the initiator MUST perform a basic return routability > check on the observed new address, as described in > Section 5.1. > ... > 5. If T expires the peer address binding is not updated. In this > case, the initiator MUST perform a basic return routability check on > the observed new address, as described in Section 5.1. > --> OK > 5) <!-- [rfced] For clarity, may we update "cater for"? > > Original: > * The initiator MAY send multiple return_routability_check messages > of type path_challenge to cater for packet loss on the probed > path. > > ... > > Note that RRC does not cater for PMTU discovery on the reverse path. > > > Perhaps: > * The initiator MAY send multiple return_routability_check messages > of type path_challenge to account for packet loss on the probed > path. > > ... > > Note that RRC does not account for PMTU discovery on the reverse path. > --> OK > 6) <!-- [rfced] We see the following phrasing with the message types > defined in this document (i.e., path_challenge, path_response, and > path_drop). Please review and let us know if any updates are needed for > consistency. > > return_routability_check message of type path_response > return_routability_check message of type path_challenge > return_routability_check message of type path_drop > > path_challenge message > path_response message > path_drop message > > path_challenge > path_response > path_drop > > Some examples: > 3. The peer (i.e., the responder) cryptographically verifies the > received return_routability_check message of type path_challenge > and responds by echoing the cookie value in a > return_routability_check message of type path_response. > ... > Each path_challenge message MUST contain random data. > ... > * The responder MUST send the path_response or the path_drop to the > address from which the corresponding path_challenge was received. > ... > --> These are all correct and consistent with the surrounding context. > 7) <!-- [rfced] Please review "use padding using...up to". Would updating > as follows improve readability of this sentence? > > Original: > * The initiator MAY use padding using the record padding mechanism > available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the > sending direction) up to the anti-amplification limit to probe if > the path MTU (PMTU) for the new path is still acceptable. > > Perhaps: > * The initiator MAY use the record padding mechanism > available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the > sending direction) to add padding up to the anti-amplification limit > to probe if the Path MTU (PMTU) for the new path is still acceptable. > --> Your proposal is correct and reads much better. > 8) <!-- [rfced] FYI - We updated "1s" to "1 second" for clarity. > > Original: > If an implementation has no way to obtain information regarding the > RTT of the active path, T SHOULD be set to 1s. > > Perhaps: > If an implementation has no way to obtain information regarding the > RTT of the active path, T SHOULD be set to 1 second. > --> OK > 9) <!-- [rfced] How may we clarify this sentence, especially "increasing > capabilities" and the text starting with "partly following > terminology..."? > > Original: > Two classes of attackers are considered, off-path and on-path, with > increasing capabilities (see Figure 4) partly following terminology > introduced in QUIC (Section 21.1 of [RFC9000]): > > Perhaps: > This model includes two classes of attackers, off-path and on-path, with > various capabilities (see Figure 4). The following > descriptions of these attackers are based on those > introduced in QUIC (Section 21.1 of [RFC9000]): > --> Using "various" instead of "increasing" is not wrong, but drops some of the intended semantics. OK for "based on those" instead of "partly following terminology". > 10) <!-- [rfced] Please review the use of "(1)" in the sentences below. > Figure 5 does not include a "1". Should "1" be removed from these sentences > or added to Figure 5? Or does "(1)" in these sentences refer to Figure 6? > Let us know how to clarify. Also, should "timeout of (1)" be updated to > "timeout of the path_challenge message (1)"? > > Original: > Figure 5 illustrates the case where a receiver receives a packet with > a new source address. In order to determine that this path change > was not triggered by an off-path attacker, the receiver will send an > RRC message of type path_challenge (1) on the old path. > > <Figure 5> > > Case 1: The old path is dead (e.g., due to a NAT rebinding), which > leads to a timeout of (1). > > As shown in Figure 6, a path_challenge (2) needs to be sent on the > new path. If the sender replies with a path_response on the new path > (3), the switch to the new path is considered legitimate. > > <Figure 6> > --> Good catch, thanks! We should edit Figure 5 to include the message number and an arrow, like this: ~~~ aasvg new old path .----------. path | | .-----+ Receiver +-----. | | | | | '----------' | | 1 | | | | .----+------. v / Attacker? / | '------+----' | | | | | | | | .----------. | | | | | '-----+ Sender +-----' | | '----------' ~~~~ > 11) <!-- [rfced] Would it be helpful to update "path_challenge" here to > "path_challenge (1)"? > > Original: > The receiver sends a path_challenge on the old > path and the sender replies with a path_response (2) on the old path. > The interaction is shown in Figure 8. > > Perhaps: > As shown in Figure 8, the receiver sends a > path_challenge (1) on the old path, and the sender replies with a > path_response (2) on the old path. > --> Yes, please. > 12) <!-- [rfced] Font styling > > a) The terms enclosed in <tt> in this document are listed below. Please > review to ensure the usage of <tt> is correct and consistent. Let us know > if any updates are needed. Note that <tt> produces fixed-width font in the > HTML and PDF outputs but no changes in the TXT output. > > <tt>connection_id</tt> > <tt>extension_data</tt> > <tt>extension_type</tt> > <tt>msg_type</tt> > <tt>path_challenge</tt> > <tt>path_drop</tt> > <tt>path_response</tt> > <tt>return_routability_check</tt> > <tt>rrc</tt> > <tt>tls12_cid</tt> > > > b) The following sentence includes <em>, which produces underscores in the > TXT output and italics in the HTML and PDF outputs. Please review to ensure > that this is a correct use of <em>. > > Original: > To prevent this, RRC cookies > must be _freshly_ generated using a reliable source of entropy > [RFC4086]. > --> Both a) and b) look good. > 13) <!-- [rfced] Please review the "type" attribute of the sourcecode > element in Section 4, as "tls-msg" is not part of the current list of > preferred values > (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types). > > Perhaps "tls-presentation" would be acceptable? This was used for similar > sourcecode in RFCs 9420 and 9458. > > If the current list of preferred values for "type" does not contain an > applicable type, then feel free to suggest a new one. Also, it is > acceptable to leave the "type" attribute not set. > --> tls-presentation seems like the right one. We weren't aware of its existence - thanks! > 14) <!-- [rfced] Terminology > > a) We see both "Cookie" and "cookie" used in this document. Should these be > uniform? If so, please let us know which form is preferred. No, the current usage is correct. Perhaps, we should wrap the capital Cookie in <tt/> (since it's a protocol element). > b) We see the following forms used in the document? Please review and let > us know if any updates are needed for correctness and consistency. > > Return Routability Check message > RRC message > return_routability_check message "RRC message" and "Return Routability Check message" are equivalent. If you prefer, for consistency we could always use "Return Routability Check message". return_routability_check is an alias when we discuss protocol elements. > c) Is "CID-address binding" correct, or should this be updated to "CID > address binding" (no hyphen)? The binding is between a CID and an IP/UDP address, so I guess "CID-address binding" is the correct way to express that. > d) We see that "return routability check" and its acronym "RRC" are used > throughout the document. Would you like to expand the first instance and > then use the acronym in the remainder of the document? Or do you prefer the > current arrangement? > --> The current arrangement is OK. > 15) <!-- [rfced] FYI - We have added expansions for the following > abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please > review each expansion in the document carefully to ensure correctness. > > Constrained Application Protocol (CoAP) > cryptographically secure pseudorandom number generator (CSPRNG) > --> Thank you! > 16) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > --> On rereading it, nothing stood out. We hava couple of questions re: RFC8446bis and RFC8447bis references. We make normative references to RFC8446 and RFC8447. Their "bis" documents are: - draft-ietf-tls-rfc8447bis (PUB as RFC 9847) - draft-ietf-tls-rfc8446bis (currently in AUTH48, to become RFC 9846) These documents are in the same publication cluster (C430) as RRC, and respectively update and obsolete their counterparts. Two questions: 1. Should the references in RRC be updated (at least, RFC8447 to RFC9847)? 2. Should RRC wait for RFC-to-be 9846 to be published? cheers, thanks! Achim, Hannes, Thomas > Thank you. > > Rebecca VanRheenen and Sandy Ginoza > RFC Production Center -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
