Hi Stephen, Please see inline. Cheers, Med > -----Message d'origine----- > De : Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] > Envoyé : jeudi 14 mars 2019 17:40 > À : BOUCADAIR Mohamed TGI/OLN; secdir@xxxxxxxx > Cc : draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > dots@xxxxxxxx > Objet : Re: Secdir last call review of draft-ietf-dots-signal-channel-30 > > > 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. [Med] The text already cites RFC 4122 as an alternate scheme. Will consider how to enhance the text. Thanks. > > >> - 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? [Med] No. A client can only get information that is bound to it. (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). > >> > >
