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 <m...@ounsworth.ca> 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 > thomas.foss...@linaro.org 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 > > > thomas.foss...@linaro.org 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 - mike@ounsworth.ca - 0x35BE13C2.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
