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

[<[e-mail]>]

Hi Stephen, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[e-mail]]
> Envoyé : jeudi 14 mars 2019 17:40
> À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : Re: Secdir last call review of draft-ietf-dots-signal-channel-30
> 
> 
> Hiya,
> 
> Just on two bits below...
> 
> I'm happy to chat more but also fine that you and the ADs can
> sort this out according to however the ADs see this.
> 
> On 14/03/2019 16:17, [e-mail] wrote:
> 
> >> 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.
> 
> Yep, I get that. But the current alg that's described for
> cuid calculation has the effect of creating an identifier
> with the same lifetime as a key pair. Assuming keys are
> harder to change than cuids it seems better to encourage
> clients to not make such a tight linkage between cuid and
> keys, esp. if the client is on a CPE. (And it avoids the
> TLS1.2 snooping issue as noted.)
> 
> I'd encourage you to consider maybe saying some more about
> how clients can change cuid, but even if not, to provide
> a cuid calculation example that doesn't link only to the
> key pair.

[Med] The text already cites RFC 4122 as an alternate scheme. 

Will consider how to enhance the text. Thanks.

> 
> >> - 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!
> 
> Perhaps I wasn't clear. ISTM that all clients can get information
> about how an attack is being seen at other clients, isn't that
> right? 

[Med] No. A client can only get information that is bound to it. 

(The spec does talk about that IIRC.) The colluding client
> might or might not be under attack but non-compromised clients will
> presumably ask for the attack to be mitigated. So the colluding
> client could use this protocol to probe and see how well or badly
> the DDoS-mitigation infrastructure is handling an ongoing attack.
> I'm basically saying that that may be noteworthy as a security
> consideration.
> 
> Cheers,
> S.
> 
> 
> >
> > 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).
> >>
> >