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

[Achim Kraus <[e-mail]>]

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