Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus <[e-mail]>]

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