Telechat Review of draft-ietf-dots-signal-channel-31
review-ietf-dots-signal-channel-31-secdir-telechat-farrell-2019-04-15-00
| Request | Review of | draft-ietf-dots-signal-channel |
|---|---|---|
| Requested rev. | no specific revision (document currently at 41) | |
| Type | Telechat Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2019-04-30 | |
| Requested | 2019-04-03 | |
| Authors | Tirumaleswar Reddy.K, Mohamed Boucadair, Prashanth Patil, Andrew Mortensen, Nik Teague | |
| Draft last updated | 2019-04-15 | |
| Completed reviews |
Tsvart Last Call review of -31 by Yoshifumi Nishida
(diff)
Secdir Last Call review of -30 by Stephen Farrell (diff) Genart Last Call review of -30 by Ines Robles (diff) Opsdir Last Call review of -31 by Menachem Dodge (diff) Secdir Telechat review of -31 by Stephen Farrell (diff) |
|
| Assignment | Reviewer | Stephen Farrell |
| State | Completed | |
| Review | review-ietf-dots-signal-channel-31-secdir-telechat-farrell-2019-04-15 | |
| Reviewed rev. | 31 (document currently at 41) | |
| Review result | Has Issues | |
| Review completed: | 2019-04-15 |
Review
review-ietf-dots-signal-channel-31-secdir-telechat-farrell-2019-04-15
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.