Re: [Dots] Secdir last call review of draft-ietf-dots-signal-channel-30

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, March 15, 2019 1:09 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> Stephen Farrell <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]]
> > Envoyé : vendredi 15 mars 2019 05:30
> > À : BOUCADAIR Mohamed TGI/OLN; Stephen Farrell; [e-mail] Cc :
> > [e-mail]; [e-mail];
> > [e-mail] Objet : RE: Secdir last call review of
> > draft-ietf-dots-signal-channel-30
> >
> > Please see inline
> >
> > > -----Original Message-----
> > > From: Dots <[e-mail]> On Behalf Of
> > > [e-mail]
> > > Sent: Thursday, March 14, 2019 9:47 PM
> > > To: Stephen Farrell <[e-mail]>; [e-mail]
> > > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > > 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:[e-mail]]
> > > > Envoyé
> > > > : jeudi 14 mars 2019 16:34 À : [e-mail] Cc :
> > > > [e-mail]; [e-mail];
> > > > [e-mail] 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