https://mailarchive.ietf.org/arch/msg/tls/a4kehk6vmKuqB40yJMfOKbPOv8w/

Comments

Section 1

• "selecting a security context of an incoming DTLS record"

  I think you mean "selecting a security context for processing an incoming DTLS record"

• I think that the text would read better if you swap the two following blocks of text:

  "A CID is an identifier carried in ... for DTLS 1.3."

  and

  "Without CID, if the ... and negotiated"

  hence introducing the concept of CID before using it.

• "Section 6 of [RFC9146] describes how ..."

  Aren’t such considerations applicable also to DTLS 1.3? If so, it’s worth mentioning.

• "This is done in order to provide more confidence to the receiving peer that the sending peer is reachable at the indicated address and port."

  I guess you mean: "the latest indicated address and port"

• "that a peer is still in possession of its address"

  Similar to the previous comment, this can be: "is still reachable to its last known address"

• "if RRC has been successfully negotiated"

  It should be: "if the use of RRC has been successfully negotiated", also consistent with the beginning of Section 3.

• That last paragraph uses both "peer" and "endpoint", apparently interchangeably. Is there any reason to not use only one of the two words? Earlier in the section, only "peer" is used.

  Later in the document, "endpoint" is also used. Maybe add a note in Section 2 about the equivalence of the two terms?

Section 4

• "Implementations MUST be able to parse and ignore messages with an unknown msg_type."

  Right, at the same time the intention should be that, if a peer uses RRC, then it MUST support all the three message types defined in this document. It's worth stating it explicitly.

Section 5

• "that has the source address of the enclosing UDP datagram different from the one currently associated"

  Couldn't (also) the source port number have changed? If so, I think you mean: "that has the source address and/or source port number of the enclosing UDP datagram different from what is currently associated"

• "the receiver SHOULD perform a return routability check as described in Section 7, unless an application layer specific address validation mechanism can be triggered instead."

  As an example of alternative mechanism that can be triggered, it's worth mentioning RFC 9175, which describes the exchange of a CoAP response and a follow-up CoAP request, both including a CoAP Echo option with value set by the server sending the response.

  Besides allowing the server to assert the freshness of the follow-up request, this exchange provides validation of the claimed address of the client sending the request.

Section 6.1

• "(e.g., a CoAP server returning an MTU's worth of data from a 20-bytes GET request)

  It's worth referring to RFC 7252 and to https://datatracker.ietf.org/doc/draft-irtf-t2trg-amplification-attacks/

Section 6.2

• In figure 5, the arrow for message 2 (path-drop) should not be bidirectional, but rather only from the sender to the receiver.

Sections 7.1 and 7.2

• s/The receiver creates/The receiver, i.e., the initiator creates

• s/The peer endpoint/The other peer, i.e., the responder,

Section 7.4

• I think that another requirement should be that the initiator MUST NOT act on more than one valid path_response or path_drop message for each path_challenge message that it has sent.

Section 10

• You will need to add a new subsection that provides expert review instructions, for the Designated Experts assigned to the new subregistry defined in Section 10.3.

Nits

Section 1

• s/i.e./i.e.,
• s/a variety reasons/a variety of reasons

Section 4

• s/path_response and/path_response, and
• s/a 8-byte/an 8-byte

Section 6

• s/Note that in general,/Note that, in general,
• s/verification due to/verification, due to
• s/Figure 2: Attackers capabilities/Figure 2: Attacker's capabilities

Section 6.1

• s/injecting and racing it/injecting, and racing it

Section 7

• s/concerns, the need/concerns, and the need

Section 7.2

• s/i.e./i.e.,

Section 8

• s/In the example/In the example of
• s/as well as the RRC/as well as for the use of the RRC
• s/been established the/been established, the
• s/interaction the IP/interaction, the IP

In my experience, using CID obsoletes a session resumption.

But if used, should rrc define, if the extension is considered to be repeated, to be changeable, or to be take from the initial handshake?

if a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID value, the receiver SHOULD perform a return routability check as described in {{path-validation}}.

For me the previously is misleading. My understanding was, that RFC9146 recommend to not update the association before passing the address check.

So, for me "currently" may be the better choice.

It is not possible for RRC to counter a man-in-the-middle attacker that is indistinguishable from a genuine network device. Such an attacker could, for example, drop, reorder or delay records at will. Man-in-the-middle attackers cannot craft DTLS records that would successfully pass verification due to the cryptographic protections applied by the DTLS record layer.

For me, "man-in-the-middle" is a synonym for "on-path".
If that text addresses the general "on-path" attacks in order to clarify, that RRC is no mitigation for these general "on-path-attacks", I think we should try to find an other text.

As idea, we may also refer to ideas to mitigate them, but explicitly exclude that from this draft.
e.g.:

• "reorder": don't use the record sequence number window, just drop all packets with no higher number (that drops then reordered packets).
• "delay records": maybe the first idea for an extension: execute a fresh RRC exchange and the next ip-packet must have a record sequence number higher as the one of the RRC message.

In difference to the on-path attack, where the original packet (with the original source address) simply may get dropped, and so never reaches the destination, the off-path attack is not able to drop that original packet. Though also this attack is based on a response to that "malicious source address", a implementation may use the "internal processing delay" and check, if the same packet with the original address arrives. If so, and if that address matches the previously associated address, then the implementation may chose to use the previously associated address.

An on-path attacker could make a copy of a packet, replace the source address with a spoofed one and forward it to the original destination. If the spoofed packet arrives before the original it will be regarded as a migration, while the original packet will be flagged as a duplicate and dropped.

For me this looks more like the off-path case.
On-path attacker may just replace the original package and only forward the spoofed one.

An on-path attacker could replace the source address with a spoofed one and forward it to the destination. Assuming an "amplified response packet" this may be misused for a (D)Dos attack.

In the path validation algorithm (both base and enhanced) we say "[...] or the address confirmation fails [...]", but we don't say precisely what we mean by that.

If it refers to failure in validating the received Cookie value, than there's a potential out-of-sync with the requirement: "[...] the initiator MUST silently discard any invalid path_response it receives."

If not, we should say what we mean by "address confirmation failure."

Should the return routability check use separate sequence numbers and replay windows?

What the title says.

We say:

"The initiator MUST silently discard any invalid path_response it receives."

we should say instead:

"The initiator MUST silently discard any invalid path_response or path_drop it receives."

9147 (DTLS 1.3) should be added to the update list, I think.

For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.

We don't currently discuss any privacy implication associated with CID reuse. We should at least:

1. document how to ensure a new CID is used during path validation in 1.3
2. flag that 1.2 has no way to work around linkability because CID have the same lifetime as the session

The current RRC version describes, what to do, if a "single" "address change" event occurs.

I see two more:

• a cid record with a next "new address" for that context arrives while RRC for that context is in progress
• a cid record with a "new address" for an other context arrives while RRC for that address is already in progress (for an different context)

Should we extend to cover such cases "explicit" as well?

Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature.

I think the discussion around interplay between RRC and CID should go in a separate (sub)section.

In settings where there is external information about the RTT of the active path, implementations SHOULD use T = 3xRTT.

If an implementation has no way to obtain information regarding the RTT of the active path, a value of 1s SHOULD be used.

In this second paragraph, does this mean T=1s or RTT=1s ?

After the WGLC deadline, we received a review from Yaron with some editorial suggestions:

• General: I'm not clear about the threat model. (Update: this is clarified in Sec. 6, so I would suggest to refer to it when we present the problem in the Introduction - also see my later comment on Sec. 6.2).
• Sec. 4: the use of the word "protocol" is not very rigorous. The "protocol" is DTLS (or the DTLS record protocol?), and we essentially define a sub-protocol within it.
• Sec. 6.2 goes into details of the protocol which have not been described yet. Maybe all of Sec. 6 can be broken into two parts. A short introductory section that defines the attacker types and the attacks at a high level, and goes early in the document; and another section that shows how these attacks are addressed by the protocol, much later in the document.

We probably need to create a new IANA registry for RRC message types.

The registry should be initialised with the 3 message types we define in the draft.

the receiver SHOULD perform a return routability check as described

When discussing that in RFC9146, my consideration was, that a "similar mechanism" maybe used also on the next layer. With that, I would consider

the receiver SHOULD perform a return routability check as described ... or perform an equivalent check by means of one of the next layers.

$subject

At the top of the "Attacker model" section we say: "RRC is not designed to counter on-path attackers."

What we should say instead is "RRC is not designed to counter man-in-the-middle attackers."

We do take care of on-path attackers, via the challenge/response exchange, and we should say that.

We want to limit the application data sent to a reasonable threshold while we run the RRC.

Martin Duke's ballot comment on draft-ietf-dtls-connection-id referenced the procedures of https://datatracker.ietf.org/doc/html/rfc9000#section-9.3.3 (which operates in essentially the same security model as DTLS) including the use of a path challenge for both old and new paths.
We may want to have some similar discussion in this document.

struct {
    rrc_msg_type msg_type;
    select (return_routability_check.msg_type) {
        case path_challenge: Cookie;
        case path_response:  Cookie;
        case path_drop:      Cookie;
    };
} return_routability_check;

What are the considerations about that select? For me it looks like all "cases" are the same? Do I oversee something?

struct {
    rrc_msg_type msg_type;
    Cookie cookie;
} return_routability_check;

I've implemented a first experimental implementation for interoperability tests (Eclipse/Californium - feature/rrc branch).

For instructions, please see README - branch feature/rrc

Happy testing.

Should the heartbeat message be re-used instead of the proposed new message exchange?

• What section in RFC 6347 and 9147 is updated? If there’s no behavior changed do we need that header?

• How about we add a note in the registry that it’s only applicable to DTLS 1.2 and 1.3

We plug straight into Section 6.5 of CID. So should this document update RFC9146?

A better name could be path_drop or path_discard -- one doesn't "delete" a path.

Section 5 title "Off-path packet forwarding" should be "Attack model" instead?

Also, is this the right position? ISTM this should go after we discuss the base challenge/response mechanics.

There is also a missing premise, I think: "RRC is not designed to counter on-path attackers. These can never be distinguished from, for example, a genuine network device. However, RRC can resist off-path attackers when enhanced path validation ({{enhanced}}) is used."

We probably need to tell implementers why/when they should choose the basic algorithm vs the enhanced. For example, avoid enhanced if:

• you need to minimise implementation complexity
• you have privacy concerns -- i.e., to avoid providing a clear correlation signal
• off-path attackers are not in your threat model and/or you want to reduce the time it takes to switch path

This is important and so the example should show it.

We'd like to use TLS Flags to negotiate RRC.

At the moment, the document seems to be defined for (D)TLS 1.3 only, but the reason why the same scheme would not be applicable to 1.2 are not fully clear.

For now (-01), optimistically, we are using it in a version agnostic fashion, hoping that eventually that will be the case.

Achim has opened an issue on the TLS flags repo. This issue is for tracking on the RRC side.