Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31

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

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of Benjamin Kaduk
> Sent: Friday, May 3, 2019 10:44 PM
> To: Stephen Farrell <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31
> 
> 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.
> 
> On Mon, Apr 15, 2019 at 05:21:22AM -0700, Stephen Farrell via Datatracker
> wrote:
> > Reviewer: Stephen Farrell
> > Review result: Has Issues
> >
> > I took a look at the changes between -30 and -31 and at the mail
> > following my earlier review of -30.
> >
> > To explain the "has issues" status for this review: Generally, I think
> > this is probably ok, but I (still) have the concerns listed below that
> > the ADs might wanna think about. The authors already responded on each
> > of these points, and made some corresponding changes, so I guess they
> > reckon these are non-issues. (Which is of course fine - even if I
> > don't quite agree, I'm often wrong:-)
> >
> > - p13: The cuid still seems to me to be too static (there's a SHOULD
> > saying to tie it to the client certificate public key or an
> > equivalent).  I still think recommending a way to generate an
> > identifier that isn't tied to a key pair would be 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 without mapping 1:1 to possibly long-lived key pairs. (-31
> > does say some more about how to change cuid, but still has the same
> > SHOULD/RECOMMENDED way to generate cuid values.)
> 
> IIUC, if there are no gateways involved, anything that sees a cuid is also
> seeing the device's client certificate, so to a large extent the use as a long-
> lived identifier is pretty similar.  Server-domain gateways are supposedly just
> for the convenience of the operator and considered equally trusted to the
> actual server, so I think this would only come into play when a client-side
> gateway is in use.  (I don't know how common that will
> be.)

As per the discussion with Stephen https://mailarchive.ietf.org/arch/msg/dots/H5JG69FJruwN7pM3j92L8wwtn-s, we have added "Appendix A. CUID Generation" and updated section 10 (please see the diff at 
https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-signal-channel-31.pdf) 

> 
> > - I wondered if a bad actor in control of an authorised DOTS client
> > colluding with the controller of a DDoS attack could use this protocol
> > to probe the network to see how their attack is going and change the
> > attack to be more effective.  In mail, the authors stated that this
> > isn't possible, and added text saying that to -31. That may be true,
> > but I'm not sure (given the complexity of the protocol).
> 
> I don't think anyone responded on this yet, so I'd like to get the sense of the
> authors.
> 
> My personal take is that the status updates are only for the efficacy of
> mitigations requested by this client, so (in this scenario) while you can tell
> how much of your attack is being blocked, you may not be able to learn how
> much is making through and adapt to increase the amount making it through.
> I suppose if you didn't know how big of a cannon you have, this could provide
> a way to get some metrics, but at the cost of rendering the ongoing attack
> ineffective, and probably revealing the compromised nature of the DOTS
> client.

This comment was discussed and resolved by adding the following lines:
A DOTS client is entitled to access only to resources it creates.  In	
particular, a DOTS client cannot retrieve data related to mitigation	
requests created by other DOTS clients of the same DOTS client	
domain.

Further, the draft points to DOTS security considerations discussed in DOTS requirements draft which says the following:

   To detect compromised DOTS agents, DOTS operators should carefully
   monitor and audit DOTS agents to detect misbehavior and to deter
   misuse, while employing current secure network communications best
   practices to reduce attack surface.

> 
> > A nit:
> >
> > - p91: The mention of TCP-AO seems to require suspension of disbelief
> > (given the lack of deployment of TCP-AO).  If we don't think it'll be
> > used, it'd be better to not pretend it might get used.
> 
> The authors should respond to this as well.

We can update the use of TCP-AO as follows:

Although not widely adopted, if TCP-AO is used, then any bogus packets injected by an attacker will be rejected by the
TCP-AO integrity check and therefore will never reach the TLS layer.

Cheers,
-Tiru

> 
> Thanks for the re-review and follow-up discussion!
> 
> -Ben
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots