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

[Thomas Fossati <[e-mail]>]

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