Diffs look good; I'm fine to clear the DISCUSS once a draft has those changes.
I do still encourage you to explicitly name the registry you're requesting IANA create in 11.3. Thanks, Mike ________________________________ From: Thomas Fossati <[email protected]> Sent: Wednesday, June 25, 2025 3:56 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, See some replies inline below, and the diff here [1] [1] https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-dtls-rrc&url_2=https://tlswg.github.io/dtls-rrc/mike/draft-ietf-tls-dtls-rrc.txt Cheers & thank you! On Tue, 24 Jun 2025 at 21:59, Mike Bishop <[email protected]> wrote: > > 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] 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], applying a similar concept to DTLS. Looks great, thanks! > 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. It would be perfect if that were the only instance of the term being used, but since 'anti-amplification limit' is also used elsewhere (twice in §6.3), I think it's better to factor it out. > (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? OK > > 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. Yes, that's how I understood your comment. In the editor's copy, it looks like this: "It is also advisable to log instances where multiple responses to a single `path_challenge` are received, as this could suggest an off-path attack attempt." > > 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. I'd think that too, but I am obviously biased ;-) > > 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. OK > Does such a draft exist yet, out of curiosity? I didn't find it in a cursory > search. Not to my knowledge. > > > === 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]
