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

[Benjamin Kaduk <[e-mail]>]

Hi Achim,

Sorry again for the delayed response.  (Inline.)

On Fri, Sep 18, 2020 at 09:59:55AM +0200, Achim Kraus wrote:
> 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.

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 ...

> 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?)

Thanks,

Ben