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

[Benjamin Kaduk <[e-mail]>]

On Sat, May 04, 2019 at 08:40:30AM +0000, Konda, Tirumaleswar Reddy wrote:
> > -----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 don't really see Stephen getting convinced, in that linked discussion.
(Also, the added Appendix A in the linked diff is past the 50-page boundary
that github loads by default, and it's failing to load more, for me.)

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

This is good to have, but I think Stephen is still within his rights to ask
for text that explicitly considers what the scope of damage is when there
is a compromised DOTS client.

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

Okay.

-Ben