[TLS] Re: draft-ietf-tls-dtls-rrc-14 ietf last call Secdir review

[Mike Ounsworth <[e-mail]>]

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 <[e-mail]> 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