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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
