Hi Ben,
Am 16.09.20 um 08:31 schrieb Achim Kraus:
Hi Ben,
If I did't get it, it may be easier to discus this as issue in the
github repo.
I think you got it; I am just failing to remember where the "MUST anyway
use new handshakes" requirement comes in from. And I guess that also
raises the question of what the expected behavior is when a server
expects
CID-ful traffic on a given 5-tuple and receives an (unencrypted)
ClientHello on that 5-tuple.
"when a server expects CID-ful traffic on a given 5-tuple"
I'm not sure, why that should happen. If CID is used, the server should
not expect a given 5-tuple (at least not longer than a few seconds).
If a new CLIENT_HELLO arrives, it's first challenge it with a
HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple
of a previous CID message" is hit, then just mark/remove the 5-tuple of
that CID association. That mainly means, you will not be able to reach
the CID peer with that 5-tuple. That's anyway extremely common to lose
the ip-route to such CID peers, otherwise CID would not be required.
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.
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.
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.
best regards
Achim
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
