Hi Ben,
Let me add:
- If the scenario uses "dynamic 5-tuples, with CID or without" and
"static 5-tuples without CID",
- then an attack, with the spoofed 5-tuple (out of that static-5-tuple"
pool) and CID (described in
https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the
communication to such a static-5-tuple without CID.
Yes, I think this is the disruption I was pondering.
Even then, that "static-5-tuple" peers must be anyway aware, that
sometimes new handshakes are required. So that scenario may also depend
more on the volume of such attacks, than just on the pure possibility.
It does seem like a pretty rare/difficult attack, unlikely to be worth the
trouble. But perhaps it is still worht documenting as a property of the
protocol ...
The point from my side was, that anyway, with or without that attack,
even clients with static-5-tuples must take care of their "encryption
association". If the client expects responses but didn't get them, then
a new handshake may be required. So, I'm not sure, if explicitly mention
that, really changes the game.
In my experience, such "static-5-tuples" are rare and I would guess,
they will benefit from different handling also for other reasons.
Therefore I would just spend them an separate endpoint to separate their
traffic.
... especially when we can give this recommendation as a workaround.
(Actually, is it generally a good idea to try to steer CID-ful and CID-less
traffic to different endpoints?)
If it's possible to use different endpoints, I think so.
best regards
Achim Kraus
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
