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

Please see inline 

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Thursday, March 14, 2019 9:47 PM
> To: Stephen Farrell <stephen.farrell@cs.tcd.ie>; secdir@ietf.org
> Cc: draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org; dots@ietf.org
> 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@ietf.org] Envoyé
> > : jeudi 14 mars 2019 16:34 À : secdir@ietf.org Cc :
> > draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org;
> > dots@ietf.org 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@ietf.org
> https://www.ietf.org/mailman/listinfo/dots