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

[Mike Ounsworth <[e-mail]>]

I have marked the SecDir review "Ready".



-Mike
"Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.


On Wednesday, June 11th, 2025 at 10:17 AM, Mike Ounsworth <[e-mail]> wrote:

> Hi Thomas,
> 

> I did a quick skim. Changes look good to me.
> 

> 

> -Mike
> "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.
> 

> 

> 

> 

> On Wednesday, June 11th, 2025 at 2:35 AM, Thomas Fossati [e-mail] wrote:
> 

> > Hi Mike,
> > 

> > We have implemented the changes we discussed and agreed on, and
> > published -15 [1].
> > 

> > Thanks for your help!
> > 

> > cheers, t
> > 

> > [1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-dtls-rrc-14&url2=draft-ietf-tls-dtls-rrc-15
> > 

> > On Tue, Jun 10, 2025 at 04:01:31PM +0100, Mike Ounsworth wrote:
> > 

> > > 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