Hiya, Just on two bits below... I'm happy to chat more but also fine that you and the ADs can sort this out according to however the ADs see this. On 14/03/2019 16:17, mohamed.boucadair@xxxxxxxxxx wrote: >> I think there's one issue with this draft that'd be well worth >> discussion and/or fixing: >> >> - p12: Why does the cuid need to be so static? I would have thought >> that an identifier that can change more often than a key pair would >> have been better, esp if this could be used in a CPE. (Creating a >> new long-lived identifier for a CPE seems like a bad plan if it's >> not really needed.) For example, one could use both the SPKI and a >> timestamp as input for a recommended way to generate a cuid and >> that should be as unique, but much more easily changed. That could >> also mitigate the possible TLS1.2 client-cert snooping issue >> mentioned on p90. > > [Med] cuid is used for avoidance detection but also as a stable key > to identify resources at the server side. Any change of the cuid will > lead to a failure in accessing the resources. Furthermore, this > identifier is used to "glue" the signal and data channels. > > The spec does not forbid the clients to change its cuid, but to do > so, the client will need to manage state migration. Yep, I get that. But the current alg that's described for cuid calculation has the effect of creating an identifier with the same lifetime as a key pair. Assuming keys are harder to change than cuids it seems better to encourage clients to not make such a tight linkage between cuid and keys, esp. if the client is on a CPE. (And it avoids the TLS1.2 snooping issue as noted.) I'd encourage you to consider maybe saying some more about how clients can change cuid, but even if not, to provide a cuid calculation example that doesn't link only to the key pair. >> - Couldn't a bad actor in control of an authorised DOTS client >> colluding with the controller of a DDoS attack use this to probe >> the system to see how their attack is going and change the attack >> to be more effective? > > [Med] The client will only see the reports for attacks it detected > and signaled. That bad actor won't signal the attack in the first > place! Perhaps I wasn't clear. ISTM that all clients can get information about how an attack is being seen at other clients, isn't that right? (The spec does talk about that IIRC.) The colluding client might or might not be under attack but non-compromised clients will presumably ask for the attack to be mitigated. So the colluding client could use this protocol to probe and see how well or badly the DDoS-mitigation infrastructure is handling an ongoing attack. I'm basically saying that that may be noteworthy as a security consideration. Cheers, S. > > I don't >> think any protocol change could help there, but perhaps you could >> give some guidance to implementers to try catch such cases (e.g., >> if the probing DOTS client's local n/w doesn't actually appear to >> be under attack). >> >
Attachment:
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
