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. 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:-) - 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? - p77 has a few lowercase "should" and "must" statements. Not sure if that's on purpose or by accident. - 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. - 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? 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).
