Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31

[<[e-mail]>]

Hi Stephen, all, 

Please see inline for the first item. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell via Datatracker [mailto:[e-mail]]
> Envoyé : lundi 15 avril 2019 14:21
> À : [e-mail]
> Cc : [e-mail]; [e-mail];
> [e-mail]
> 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.
> 
>