Hi Achim and Thomas, I should have numbered my comments for easier reference. Oh well.
I think the suggestions you make below would be sufficient, thanks. Since my comments are about clarity and not content, I leave it up to you; I won't block the document either way. In my personal opinion, it would make the document easier to read if you inlined at least a summary of the relevant definitions from [RFC9146], [RFC9000], [Sect. 6 of this document] into the intro. This is personal style, but I think that anything that's core to understanding the main points of a document should be inlined, rather than forcing the user to go fishing in a half-dozen other documents. I like the phrase "blah blah from [RFCxxxx], which is reproduced here for clarity". -Mike "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune. On Tuesday, June 10th, 2025 at 5:17 AM, Thomas Fossati <[email protected]> wrote: > Hi Mike, > > Thanks very much for the detailed review. > > On top of Achim's replay, see also a few other comments inline. > > On Mon, Jun 09, 2025 at 11:51:50AM +0100, Mike Ounsworth wrote: > > > [...] > > Naïve question (I am not a DTLS / routing expert). Does this spec > > introduce a new DDoS surface in the case that the new (preferred) path > > is longer, and therefore the connection will keep pausing to do this > > path-check? I expected to see somewhere a recommendation for a guard > > against that – only do this once per pair of paths, or something > > similar. > > > To trigger RRC you need to be able to send a "good" DTLS record, > otherwise, the receiver will drop it on the floor and continue as if > nothing happened. To do that, you either replay an old record and hope > the receiver doesn't have anti-replay on (at least in some form -- see > §6 of RFC9146), or you are racing a copy of an outstanding record over a > shorter/faster path. It is not possible to make the receiver start > doing RRC work otherwise, i.e., cheaply enough to introduce more DDoS > surface. > > > I would like to see the Introduction add a paragraph about > > mandatory-to-implement and interop implications of this draft; give a > > sense of whether this is a mandatory-to-implement extension to DTLS, > > or optional, and whether one side of the connection can perform this > > successfully even if the other end does not support it. I think the > > text I’m looking for is: “This specification defines a RECOMMENDED > > mechanism for DTLS 1.2 and 1.3. DTLS 1.2 and 1.3 implementations > > SHOULD implement this and include it in all DTLS ClientHellos, but > > note that no security value is obtained unless both parties support > > it”, but I’ll leave it to the experts to frame the correct wording. > > > OK, makes sense. Would something like the following work? > > A client offering the connection_id extension SHOULD also offer the > rrc extension, unless the application using DTLS has its own address > validation mechanism. > > > Intro needs more description of what the vulnerability is, and which > > party is gaining protection against which type of adversary by > > implementing this. You have this nicely and in great detail in Section > > 6, but I would pull a short summary up to the Intro. After reading > > section 6, I see that you are solving two problems: > > amplification-to-a-victim, and path-hijacking. You have some good > > sentences in Section 6 that you could pull up into a short summary of > > the issue and fix. > > > The intro defers to §6 of RFC9146 for providing the context and problem > description, and to §6 of RFCTHIS "to gain a detailed understanding of > the attacker model". IMHO we are good. > > > Nit: Section 4: “Future extensions to the Return Routability Check > > sub-protocol may define new message types.” … should that be a > > normative “MAY”? > > > I don't think tehre is anything normative in that sentecne. > > > Section 6: It would be nice if you synced up with the terminology for > > type of attack / attacker as defined in Section 3 of RFC3552. What you > > have is close to S. 3.2 of RFC3552; probably just needs a reference > > and a sentence “We extend the definitions of “on-path” and “off-path” > > attackers as given in [RFC3552] to more precisely fit the specifics > > addressed by this specification”. Could / should also site definitions > > in RFC 4949. > > > We could add: > > This definition differs from that of Section 3.5 of RFC3552 in that > an off-path attacker is able to observe packets. > > However, we already reference RFC9000, which makes the exact same point. > > Alternatively, to avoid repetition, we could refine the reference to > RFC9000 (adding §21.1). > > WDYT? > > > Section 6.1.1: “When receiving a packet with a known CID and a spoofed > > source address, an RRC-capable endpoint will…” Technically, the > > endpoint doesn’t know for a fact that it’s spoofed, right? I assume > > that the whole point of defining a challenge-response sub-protocol > > here is to distinguish the legitimate path-changes from attacks, > > right? I would say instead “When receiving a packet with a known CID > > and a source address that does not match, the RRC-capable endpoints > > will begin by assuming that it is spoofed and verify by …” > > > §6.1.1 needs to be read in the context established by §6.1 which > describes the amplification attack. In such context, the sender is > assumed to be the attacker that spoofs the source address to trick the > receiver. > > If that creates confusion, we could say instead: > > When receiving a packet with a known CID that has a source address > different from the one currently associated with the DTLS connection, > [...] > > It's slightly more clumsy but still readable. > > > Section 6: “The attack is more reliable if relatively few packets are > > sent or if packet loss coincides with the attempted attack.” I’m a > > little confused about the grammar of this sentence. I could see this > > meaning one of several things: That the attack is harder if the victim > > channel has some naturally-occuring (unrelated) packet loss that the > > attacker has no control over, but happens to coincide with the attack. > > That the attacker needs to induce packet loss in order to perform the > > attack, and this is easier if it’s an otherwise noise-free channel. > > That the off-path that the attacker is trying to migrate to should be > > noise-free. Either way, making this sentence more precise would help > > > The sentence says that the attacker has an easier life if: > 1. the application layer exchange is somewhat sparse, which can help > avoid dealing with the connection moving back to the legit path, > 2. packet loss on the legit path occurs simultaneously as the attacker > is executing the race, therefore increasing the chances of the attacker > winning the race. > > > Grammar: “In order to determine whether this path change was not > > triggered by an off-path attacker” In English, you don’t use the > > “whether … not” construction. I would suggest either: “... determine > > whether this path change was triggered by …” or “... determine that > > this path change was not triggered by …” > > > I like the second suggestion, thanks! > > > Joke: Figure 5 looks like what happens when I try to change my tax > > address with the government; and this triggers all sorts of paper mail > > to all my registered addresses. > > > :-) > > > You use language like “attacker trying to place itself on path”. Would > > it be more evocative to say “hijack the path”? Your described attack > > here seems to agree with the definition of “Hijack Attack” given in > > RFC 4949. > > > Maybe, but I am not sure. The attack as a whole is a combination of > active and passive wiretapping (in 4949 terms) whereas "hijack attack" > is defined as "A form of active wiretapping". So the match doesn't seem > perfect. > > > “If the path via the attacker is reliably faster than the old path > > despite multiple attempts to use that old path, it is not possible to > > distinguish between an attack and an improvement in routing.” This is > > funny. I am picturing a Wired.com article titled “Actor X hijacks the > > entire internet by providing faster, more reliable service”. Right. > > Hard to really call that an attack. > > > :-) > > > Section 7 intro: I feel like this needs some tie-back to the > > negotiation done during the ClientHello / ServerHello step. > > > We point to here in the forward direction (from §4): > > The RRC sub-protocol consists of three message types: path_challenge, > path_response and path_drop that are used for path validation and > selection as described in Section 7. > > I beelive this should be sufficient. > > > Like, the entirety of Section 7 only happens if this session > > negotiated to use RRC, right? > > > Yes > > > Section 7.2 / 7.3 is literally the first time in the document that the > > terms “Basic” / “Enhanced” appear. You at least need to introduce this > > at the top of section 7. > > > What about: > > It then initiates the return routability check. This document > describes two kinds of checks: basic (Section 7.2) and enhanced > (Section 7.1). The choice of one or the other depends on whether > the off-path attacker scenario described in Section 6.2 is to be > considered. > > > Basic vs Enhanced something that needs to be negotiated? > > Are these interop-equivalent and therefore implementer’s > > choice? … some introduction needed. > > > I believe these specific points are already discussed in §7. > > cheers, thanks! > t
publickey - [email protected] - 0x35BE13C2.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
