Hi Stephen, all, Please see inline for the first item. Cheers, Med > -----Message d'origine----- > De : Stephen Farrell via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : lundi 15 avril 2019 14:21 > À : secdir@xxxxxxxx > Cc : draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > dots@xxxxxxxx > Objet : Secdir telechat review of draft-ietf-dots-signal-channel-31 > > Reviewer: Stephen Farrell > Review result: Has Issues > > 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 [Med] This is a feature not a bug. This scheme is particularly useful to recover state, for example, upon reboot or crash of a DOTS client. > 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. > >
