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

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

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Tuesday, May 7, 2019 10:55 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>
> Cc: Stephen Farrell <[e-mail]>; [e-mail]; draft-ietf-
> [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 Tue, May 07, 2019 at 07:30:11AM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > Hi Ben,
> >
> > Please see inline
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <[e-mail]>
> > > Sent: Monday, May 6, 2019 9:05 PM
> > > To: Konda, Tirumaleswar Reddy
> <[e-mail]>
> > > Cc: Stephen Farrell <[e-mail]>; [e-mail];
> > > draft-ietf- [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 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/m
> > > > aste
> > > > r/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-
> > > > sign
> > > > al-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.)
> >
> > Appendix A.  CUID Generation
> >
> >    The document recommends the use of SPKI to generate the 'cuid'.  This
> >    design choice is motivated by the following reasons:
> >
> >    o  SPKI is globally unique.
> >
> >    o  It is deterministic.
> >
> >    o  It allows to avoid extra cycles that may be induced by 'cuid'
> >       collision.
> >
> >    o  DOTS clients do not need to store the 'cuid' in a persistent
> >       storage.
> >
> >    o  It allows to detect compromised DOTS clients that do not adhere to
> >       the 'cuid' generation algorithm.
> >
> > >
> > > >
> > > > >
> > > > > > - 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.
> >
> > Okay, I propose to add the following lines:
> 
> Thanks, I think this is helpful (and hopefully Stephen can confirm)...
> 
> > A compromised DOTS client can collude with a DDoS attacker to send
> > mitigation request for a target resource, gets the the mitigation
> > efficacy from the DOTS server, and conveys the mitigation efficacy to
> > the DDoS attacker to possibly change the DDoS attack strategy. This
> > attack can be prevented by monitoring and auditing DOTS clients to
> > detect misbehavior and to deter misuse, and by authorizing the DOTS
> > client to request mitigation for
> 
> ... but perhaps "by only authorizing" would be more clear.

Sure, will update.

-Tiru

> 
> -Ben
> 
> > specific target resources (e.g. An application server is authorized to
> > request mitigation for its IP addresses but an DDoS mitigator can
> > request mitigation for any target resource in the network). Further,
> > DOTS clients are typically co-located on network security services
> > (e.g. DDoS mitigator, firewall etc.) and a compromised security
> > service potentially can do lot more damage to the network.
> >
> > >
> > > > 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.
> >
> > Thanks, will update draft.
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > -Ben