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

[<[e-mail]>]

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'
      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.