Telechat Review of draft-ietf-dots-signal-channel-31
review-ietf-dots-signal-channel-31-secdir-telechat-farrell-2019-04-15-00

I took a look at the changes between -30 and -31 and at the mail
following my earlier review of -30.

To explain the "has issues" status for this review: Generally, I
think this is probably ok, but I (still) have the concerns listed
below that the ADs might wanna think about. The authors already
responded on each of these points, and made some corresponding
changes, so I guess they reckon these are non-issues. (Which is of
course fine - even if I don't quite agree, I'm often wrong:-)

- p13: The cuid still seems to me to be too static (there's a
SHOULD saying to tie it to the client certificate public key
or an equivalent).  I still think recommending a way to generate
an identifier that isn't tied to a key pair would be 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 without mapping 1:1 to possibly long-lived key
pairs. (-31 does say some more about how to change cuid, but still
has the same SHOULD/RECOMMENDED way to generate cuid values.)

- I wondered if a bad actor in control of an authorised DOTS
client colluding with the controller of a DDoS attack could use
this protocol to probe the network to see how their attack is
going and change the attack to be more effective.  In mail, the
authors stated that this isn't possible, and added text saying
that to -31. That may be true, but I'm not sure (given the
complexity of the protocol).

A nit:

- p91: The mention of TCP-AO seems to require suspension of
disbelief (given the lack of deployment of TCP-AO).  If we don't
think it'll be used, it'd be better to not pretend it might get
used.