Hi Stephen, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Stephen Farrell via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : jeudi 14 mars 2019 16:34 > À : secdir@xxxxxxxx > Cc : draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > dots@xxxxxxxx > Objet : Secdir last call review of draft-ietf-dots-signal-channel-30 > > Reviewer: Stephen Farrell > Review result: Has Issues > > > 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. > > nits: > > - (Not really a nit, but probably too much to ask, so...) > The protocol here seems very complex. Has anyone > tried to prove anything about the state machine, e.g. > that's it's safe in some senses? It'd be fair to say that > that is a good task to do after the initial RFC is > published in this case, I guess. OTOH, could be some of > the theorem-proving tools used in the development of > TLS1.3 could be useful here. (And those tools usually > do turn up some issues worth fixing - I'd bet a beer they > would in this case:-) [Med] The specification was edited following an incremental approach in which new pieces are validated through at least two interoperable implementations. We hope that more feedback will be received after the initial RFC. > > - p18: "Only single-valued 'cdid' are defined in this > document." That confused me given the text 3 paras > before about multiple cdid values. Maybe clarifying that > some could be useful? [Med] What is meant here is the case where multiple GWs are involved in the path; each inserts a cdid value. Will clarify the text. > > - p77 has a few lowercase "should" and "must" statements. > Not sure if that's on purpose or by accident. [Med] I confirm it was on purpose. These are not new requirements (see Section 7.2). > > - p90: Is the mention of TCP-AO there for real? I'd be > happy it it were but if it's merely aspirational and you > don't think it'll be used, it'd be better to not pretend > it might get used. > [Med] We are providing an example of how the issue can be solved. That is fine, IMO. > - 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! 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). >
