> -----Original Message----- > From: mohamed.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx> > Sent: Friday, March 15, 2019 1:09 PM > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>; > Stephen Farrell <stephen.farrell@xxxxxxxxx>; secdir@xxxxxxxx > Cc: draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; dots@xxxxxxxx > Subject: RE: 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 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' Replace "only the first server-domain" with "only the first on-path server-domain" > value. This specification does not allow multiple server-domain > DOTS gateways, whenever involved in the path, to insert a 'cdid' > value for each. Looks good. > > Figure 8 needs to > > be corrected, 'cuid' is missing in the Figure. > > [Med] Figure 8 is correct. Yes. Cheers, -Tiru
