Document: draft-ietf-tls-dtls-rrc Title: Return Routability Check for DTLS 1.2 and DTLS 1.3 Reviewer: Mike Ounsworth Review result: Has Nits
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Has Nits; the document could be published as-is, but I include suggestions to enhance readability of the security implications of the document. 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. 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. 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. Nit: Section 4: “Future extensions to the Return Routability Check sub-protocol may define new message types.” … should that be a normative “MAY”? 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. 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 …” 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 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 …” 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. “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. Like, the entirety of Section 7 only happens if this session negotiated to use RRC, right? 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. Basic vs Enhanced something that needs to be negotiated? Are these interop-equivalent and therefore implementer’s choice? … some introduction needed. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
