Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Achim Kraus <[e-mail]>]

Hi Martin,


> Nothing here depends on using a CID, except perhaps to the extent that the endpoint that observes the "migration" needs to be able to match incoming records with connection state.  If they need a CID for that, then this needs a CID.

If the threat is only weakly related to the use of a CID, would then the
discussion of that more general threats not require also a more general
scope than that of this DTLS CID RFC?

> 5. Victim believes that the connection has migrated and stops sending on the old path.
>
> If the new address is attacker controlled, the attacker is now on-path.  The attacker can stop forwarding and deny service at its discretion.

For a "service deny" no attacker is needed :-), UDP traffic may be lost,
DTLS traffic may be ignored, and overloaded peers may response out of
the expected time-frame.

Most of that is in my opinion the general risk using something as the
"public internet" with its grants and no-grants.

In all cases of a "service-deny", the peer was, and with CID, is still,
intended to try a reconnect strategy (what ever that means according the
destination ip-address.)

In my sum:
- without CID, much more (resumption) handshakes are needed in order to
communicate using DTLS.
- with CID, such (resumption) handshakes are still required, but much less.

Your attack adds some more handshakes, but it doesn't introduce
something new, nor do I see, that this will exceed the number of
handshakes without CID.

best regards
Achim Kraus