> -----Original Message----- > From: Benjamin Kaduk <kaduk@xxxxxxx> > Sent: Tuesday, May 7, 2019 10:55 PM > To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> > Cc: Stephen Farrell <stephen.farrell@xxxxxxxxx>; dots@xxxxxxxx; draft-ietf- > dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; secdir@xxxxxxxx > 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 <kaduk@xxxxxxx> > > > Sent: Monday, May 6, 2019 9:05 PM > > > To: Konda, Tirumaleswar Reddy > <TirumaleswarReddy_Konda@xxxxxxxxxx> > > > Cc: Stephen Farrell <stephen.farrell@xxxxxxxxx>; dots@xxxxxxxx; > > > draft-ietf- dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; > > > secdir@xxxxxxxx > > > 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 <dots-bounces@xxxxxxxx> On Behalf Of Benjamin Kaduk > > > > > Sent: Friday, May 3, 2019 10:44 PM > > > > > To: Stephen Farrell <stephen.farrell@xxxxxxxxx> > > > > > Cc: dots@xxxxxxxx; draft-ietf-dots-signal-channel.all@xxxxxxxx; > > > > > ietf@xxxxxxxx; secdir@xxxxxxxx > > > > > 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
