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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 07 May 2019 07:30 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEE31201EE; Tue, 7 May 2019 00:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZThqxwGe2gZ; Tue, 7 May 2019 00:30:43 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123AE120228; Tue, 7 May 2019 00:30:41 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1557213838; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=LZxQKFfR22kU2j4BEnE6hBDFQiJX9o54eisVRe QIW/c=; b=IJi1T9YLxLbMeaFTkPHgZd5FcRj29KunAHe1xHwM Ef11W2X63/HzN7KE62FcDUFFzsdIUb2MWkvzSspPMpMM5vL/+e +0rvKJlfmJXYCcYEAEeNhhE6UuLwv/At8rlKDzPFQgBvTdUNMo 72AxbuDArenAGJI+CcMJff/rHXOpdoE=
Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5288_0fb3_186ceb79_bfc7_48b4_aef9_763a9779f040; Tue, 07 May 2019 01:23:57 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 May 2019 01:30:13 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 7 May 2019 01:30:13 -0600
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 May 2019 01:30:12 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2502.namprd16.prod.outlook.com (20.177.224.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.15; Tue, 7 May 2019 07:30:11 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379%2]) with mapi id 15.20.1856.012; Tue, 7 May 2019 07:30:11 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "dots@ietf.org" <dots@ietf.org>, "draft-ietf-dots-signal-channel.all@ietf.org" <draft-ietf-dots-signal-channel.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31
Thread-Index: AQHU84Xn3S97Pb+WW0CNvO8JFIRGL6ZZwC+AgAD4aJCAA6L0gIABAsoQ
Date: Tue, 07 May 2019 07:30:11 +0000
Message-ID: <BYAPR16MB2790B9B7B9A4C8FCB4219796EA310@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <20190503171406.GO59871@kduck.mit.edu> <BYAPR16MB2790F46BC224F33C5240FEF2EA360@BYAPR16MB2790.namprd16.prod.outlook.com> <20190506153513.GD19509@kduck.mit.edu>
In-Reply-To: <20190506153513.GD19509@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6aaafb9c-213b-4943-d7d3-08d6d2bdd6c0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2502;
x-ms-traffictypediagnostic: BYAPR16MB2502:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR16MB2502ECE257827D98194681D1EA310@BYAPR16MB2502.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0030839EEE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(396003)(376002)(136003)(189003)(32952001)(13464003)(199004)(74316002)(3846002)(6116002)(80792005)(9686003)(6306002)(55016002)(316002)(54906003)(14454004)(256004)(71190400001)(73956011)(71200400001)(66446008)(7736002)(66946007)(25786009)(76116006)(66476007)(66556008)(64756008)(478600001)(966005)(11346002)(2906002)(6506007)(81156014)(86362001)(8936002)(81166006)(53546011)(8676002)(6916009)(5660300002)(486006)(68736007)(102836004)(33656002)(2171002)(305945005)(6246003)(66066001)(52536014)(186003)(53936002)(6436002)(99286004)(4326008)(14444005)(5024004)(446003)(26005)(72206003)(7696005)(476003)(76176011)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2502; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Zvm7O4OPHyHhV6a52JQR/4xf5XLzBi9Kd+X3G7rjZphC0uCyTXtM4gv9n5HKMkttk73pez8fRpNKUgK91WZmNN29xLgmcPG91fDFnutno5520keyaLpdJA3wlZMra8I6x1dzcuvhHb+AQM+wUMqxUiJXzEsVKchsPw+vInResEcoOWAF7orLB5XSZP13xBkzwW4QvmfbLkm+Ep4aqzvlhTaqGTlYi0Bs1og5IYk8yOnilEilPqU0O14y//shyLJ5ctpUZsobFYrm4DHw49sOv+VHkmFe8G/DG3N8O4PVauV9s+2UEPy8ZwWyLqPd1/QckvXYp9zM21kxIuXN2bnK3b5sIpjphyYLtm+fnC1lYck6XVEXrMBwUkQm+iS0AnJE6opooLy0hMA8JmIrHArkr1i+bjGnrlExrR2RhlFpJ54=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6aaafb9c-213b-4943-d7d3-08d6d2bdd6c0
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 07:30:11.1496 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2502
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6540> : inlines <7074> : streams <1820811> : uri <2841470>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/PUu68N4u2c-kVSgb6cYW8ox9lzo>
Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2019 07:30:52 -0000

Hi Ben,

Please see inline

> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: Monday, May 6, 2019 9:05 PM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>; dots@ietf.org; draft-ietf-
> dots-signal-channel.all@ietf.org; ietf@ietf.org; secdir@ietf.org
> 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@ietf.org> On Behalf Of Benjamin Kaduk
> > > Sent: Friday, May 3, 2019 10:44 PM
> > > To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
> > > Cc: dots@ietf.org; draft-ietf-dots-signal-channel.all@ietf.org;
> > > ietf@ietf.org; secdir@ietf.org
> > > 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/maste
> > 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:

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