Last Call Review of draft-ietf-dots-signal-channel-30
review-ietf-dots-signal-channel-30-secdir-lc-farrell-2019-03-14-00

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).