Hi Mike, thanks for the thorough review and suggestions! On Mon, 23 Jun 2025 at 18:03, Mike Bishop via Datatracker <[email protected]> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The RFC 9000 reference is currently informative, used to support the > definition > of the term "anti-amplification limit" in Section 2. However, conformance with > this limit is normatively required in Section 6. Please rephrase Section 2 to > include the full definition in this document that is required to understand > the > normative requirement; RFC 9000 can optionally be retained as an informative > reference to a parallel usage, as done in Section 5. (Alternatively, you > could > make the RFC 9000 reference normative, but I don't think that's necessary.)
Sorry, I am unclear about what you mean by "rephras[ing] Section 2 to include the full definition in this document that is required to understand the normative requirement." In §2, we say that we "reuse the definition of anti-amplification limit from [RFC9000] to mean three times the amount of data received from an unvalidated address. This includes all DTLS records originating from that source address, excluding discarded ones." What is missing that would prevent understanding the requirement in §6, where we say that "the receiver [...] MUST stop sending any buffered application data, or limit the data sent to the unvalidated address to the anti-amplification limit"? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 5.2.1 should describe in more detail that the case where "it is not > possible to distinguish between an attack and an improvement in routing" will > look different from the viewpoint of Sender and Receiver. Because the attacker > is duplicating the Sender's packets from the old address to the new address, > the Sender would see the RRC message as a re-validation for the current path > and would generate a path-response, believing it is doing what Figure 6 > illustrates. However, the attacker will forward this path-response to the > Receiver; if it wins the race (or can cause packet loss on the old path), the > Receiver will see the path-response message arrive from the new address, not > the old. True, but is that essential to the comprehension? Anyway, if you really think it's important to make it explicit, we'll try to add a paragraph to capture the essence. > The behavior as defined in Section 6.2 addresses this by preventing a switch > on > receipt of a path_response without regard to the path on which it actually > arrived. However, if the attacker is able to elicit a response of type > path_drop to a given path_challenge, for example by injecting a modified copy > of the path_challenge, that can be used to spoof dropping the challenged older > path. This may need an additional branch in 6.2 step 3, prohibiting any > response if the path where the message was received has never been a preferred > path. Nice. However, wouldn't §6.4 (Path Response/Drop Requirements) be a better place? We could add a bullet point with: "If the `path_challenge` was received on a path that has never been a preferred path, the responder MUST NOT send a `path_response` or `path_drop`." > In 10.1, consider advising that implementations log when responses to a single > path_challenge are received, as this could also be suggestive of an attempt at > the above attack. Right, will do. > In 11.2, why is this extension not Recommended for implementations to support? > That would seem to say that it either "has not been through the IETF consensus > process, has limited applicability, or is intended only for specific use > cases." While the applicability is limited to DTLS, that is already > communicated by the DTLS-Only column. The reasoning for Recommended=N is that RRC falls into the "limited applicability" bucket, and, therefore, it is not "generally recommended for implementations to support." (Note that connection_id has the same marking (i.e., DTLS-only=Y, and Recommended=N), with identical reasoning.) I have no strong opinions on this matter, but both the working group and the designated expert were happy with the current arrangements. > In 11.3, please fully specify the name of the requested registry. Also, why is > a DTLS-Only column needed in a registry which contains messages within a > sub-protocol which only exists in DTLS? That's because other path_X messages can be defined in the future that also apply to TLS. > [...] > (Obviously retain it if there is future work > to support RRC outside of DTLS which will share this registry.) Yes (see above) > === NITS FOLLOW === > > - Section 3.1, "application layer specific" => "application-specific" or > "application-layer" should be sufficient > > - Figure 7, '*' appears in the key but nowhere in the figure. I assume this is > copied from other similar figures which use it, but it can be omitted here. > > - Section 7, "our" => "this" > > - Section 11.1, "entry to" => "entry in"; remove comma after "registry" All nits applied, thank you! cheers, t _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
