Please see inline > -----Original Message----- > From: Dots <dots-bounces@xxxxxxxx> On Behalf Of > mohamed.boucadair@xxxxxxxxxx > Sent: Thursday, March 14, 2019 9:47 PM > To: Stephen Farrell <stephen.farrell@xxxxxxxxx>; secdir@xxxxxxxx > Cc: draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; dots@xxxxxxxx > Subject: Re: [Dots] Secdir last call review of draft-ietf-dots-signal-channel-30 > > This email originated from outside of the organization. Do not click links or > open attachments unless you recognize the sender and know the content is > safe. > > Hi Stephen, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Stephen Farrell via Datatracker [mailto:noreply@xxxxxxxx] Envoyé > > : jeudi 14 mars 2019 16:34 À : secdir@xxxxxxxx Cc : > > draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > > dots@xxxxxxxx Objet : Secdir last call review of > > draft-ietf-dots-signal-channel-30 > > > > Reviewer: Stephen Farrell > > Review result: Has Issues > > > > > > 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. > > [Med] cuid is used for avoidance detection but also as a stable key to > identify resources at the server side. Any change of the cuid will lead to a > failure in accessing the resources. > Furthermore, this identifier is used to "glue" the signal and data channels. > > The spec does not forbid the clients to change its cuid, but to do so, the > client will need to manage state migration. > > > > > 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:-) > > [Med] The specification was edited following an incremental approach in > which new pieces are validated through at least two interoperable > implementations. We hope that more feedback will be received after the > initial RFC. > > > > > - 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? > > [Med] What is meant here is the case where multiple GWs are involved in > the path; each inserts a cdid value. 'cdid' is only inserted by the server-domain DOTS gateway. Figure 8 needs to be corrected, 'cuid' is missing in the Figure. Cheers, -Tiru > > Will clarify the text. > > > > > - p77 has a few lowercase "should" and "must" statements. > > Not sure if that's on purpose or by accident. > > [Med] I confirm it was on purpose. These are not new requirements (see > Section 7.2). > > > > > - 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. > > > > [Med] We are providing an example of how the issue can be solved. That is > fine, IMO. > > > - 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? > > [Med] The client will only see the reports for attacks it detected and signaled. > That bad actor won't signal the attack in the first place! > > 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). > > > > _______________________________________________ > Dots mailing list > Dots@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dots
