Inline with [MB] ________________________________ From: Thomas Fossati <[email protected]> Sent: Tuesday, June 24, 2025 9:59 AM To: Mike Bishop <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Mike Bishop's Discuss on draft-ietf-tls-dtls-rrc-17: (with DISCUSS and COMMENT)
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"? [MB] If that's a full definition, then rephrasing it to be clear the reference doesn't contain additional necessary detail should be sufficient. Something like: CURRENT: This document reuses the definition of "anti-amplification limit" from [RFC9000<https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-17.html#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. CONSIDER: The "anti-amplification limit" means three times the amount of data received from an unvalidated address. The received data includes all DTLS records originating from that source address, excluding discarded ones. This follows the pattern of [RFC9000<https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-17.html#RFC9000>], applying a similar concept to DTLS. However, in that case, you might consider simply putting the definition at the place it's normatively used. Note that RFC9000 doesn't define the term in its Terms and Definitions section, but directly in Section 8, Address Validation: The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit. (I also note that "excluding discarded ones" is stricter than RFC9000's usage, where any datagram received counts even if it's not usable, IIRC.) > ---------------------------------------------------------------------- > 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. [MB] I think it leads into why the restriction on generating path_drop is needed. Your call on how much detail to explain around it. COMMENTs are non-blocking, no different from input during Last Call. > 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`." [MB] That would be fine as well. If you do that, perhaps in 6.2 change "not preferred" to "no longer preferred" as a hint that it needs to have been preferred in the past? > 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. [MB] Was intended to say that log when multiple responses to a single challenge are received. > 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. [MB] That's fine; I was surprised, but will defer to the WG. I would think both are generally expected of a DTLS implementation. > 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) [MB] That's fine, then; perhaps worth a mention that RRC for non-DTLS will/could be defined as future work. Does such a draft exist yet, out of curiosity? I didn't find it in a cursory search. > === 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]
