Hi Tiru, Please see inline. Cheers, Med > -----Message d'origine----- > De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@xxxxxxxxxx] > Envoyé : vendredi 15 mars 2019 05:30 > À : BOUCADAIR Mohamed TGI/OLN; Stephen Farrell; secdir@xxxxxxxx > Cc : draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > dots@xxxxxxxx > Objet : RE: Secdir last call review of draft-ietf-dots-signal-channel-30 > > 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. [Med] I added this NEW text to clarify the comment from Stephen: OLD: Only single-valued 'cdid' are defined in this document. NEW: Only single-valued 'cdid' are defined in this document. That is, only the first server-domain DOTS gateway can insert a 'cdid' value. This specification does not allow multiple server-domain DOTS gateways, whenever involved in the path, to insert a 'cdid' value for each. Figure 8 needs to > be corrected, 'cuid' is missing in the Figure. [Med] Figure 8 is correct.
