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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 08 May 2019 07:03 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 0B767120153; Wed, 8 May 2019 00:03:54 -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 tQnqIpz8CX3H; Wed, 8 May 2019 00:03:51 -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 D927912014A; Wed, 8 May 2019 00:03:50 -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=1557298619; 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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=n +kokaEkr4m+Zmy3QIQaboG97BTTf46Qx8p1FKH1lT I=; b=JvT2CoS3QQF2Bi72tl/PhF3fiTYR5GhFd6U8oEefhw6x +rjWU1vQXV+Nt1rF3eEsa7jMEwpw9a0djjXY83W54bPPvpVxd+ FXshVYh698m8Lp+KUYDzdWRyYCxYysRx2kbX9GykCOC6GOW4lb VUHxZ7IhBl9Vlv+pj5ZTxA72NmQ=
Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1780_2ad3_69fd744c_7f98_47dc_8631_2be26bba1ccf; Wed, 08 May 2019 00:56:58 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 May 2019 01:03:19 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 8 May 2019 01:03:20 -0600
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 May 2019 01:03:19 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2422.namprd16.prod.outlook.com (20.177.225.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Wed, 8 May 2019 07:03:17 +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; Wed, 8 May 2019 07:03:17 +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+AgAD4aJCAA6L0gIABAsoQgACuQwCAAORcEA==
Date: Wed, 8 May 2019 07:03:17 +0000
Message-ID: <BYAPR16MB279018B516162E41C200B972EA320@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> <BYAPR16MB2790B9B7B9A4C8FCB4219796EA310@BYAPR16MB2790.namprd16.prod.outlook.com> <20190507172509.GK19509@kduck.mit.edu>
In-Reply-To: <20190507172509.GK19509@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: 21536357-b223-472a-7f5c-08d6d3833f65
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2422;
x-ms-traffictypediagnostic: BYAPR16MB2422:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR16MB242228471EC409A0CBC0F0A9EA320@BYAPR16MB2422.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(366004)(396003)(39860400002)(32952001)(13464003)(189003)(199004)(11346002)(478600001)(316002)(446003)(14444005)(54906003)(5660300002)(99286004)(256004)(72206003)(86362001)(74316002)(476003)(6116002)(52536014)(33656002)(4326008)(3846002)(305945005)(7736002)(14454004)(229853002)(486006)(6436002)(966005)(7696005)(76116006)(68736007)(26005)(8936002)(9686003)(73956011)(66946007)(102836004)(66066001)(6306002)(55016002)(64756008)(66476007)(66556008)(81166006)(66446008)(81156014)(8676002)(80792005)(5024004)(186003)(76176011)(2906002)(25786009)(71200400001)(6506007)(6916009)(71190400001)(53546011)(2171002)(53936002)(6246003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2422; 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: JE3cYvTUuZr6wLHkLSdW3Qc+LPSu3SAJDT0t3cnniq/tL6k/C8bcYgClz6jGy09fcY7qwlzkEuGvMmfQ8InFzpkWPm5KMCfFwY50gLAYMOPKvL2M9B6IMhVZ+9oIEIcBPQkk/vGcSQJ2ezAJgWrm/Zhi15NYDbRo1VE41YCDrGHyfFz06xcl0e7kMVvAy37oKwfNqSIzJa+KTWjtsNPRAUXFJTOpDss2Dm+u7qbJpmR4o8bQxuvgKzR+yQ7F7cvoi+kzeQzBXAZyrQfac/qPsf+aiJ3Cf7XLk901QNnGzw3SuDc7SO/CEOf2WWhWmW3qFCq9Eopgd3Hg+xfI1FZb0e3xWYp2vonEvvgsVL6yQjNJryceb7OpP6K4lJ3ReN2GYl0FNt0ZS30IqM4ygjw8EfEwplxzO7ftZ5sxLLx9ZRs=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 21536357-b223-472a-7f5c-08d6d3833f65
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 07:03:17.5455 (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: BYAPR16MB2422
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6541> : inlines <7074> : streams <1820905> : uri <2841857>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/PTGcSwnUwn3bIPQfpD1JOk3U4bA>
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: Wed, 08 May 2019 07:03:54 -0000

> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>;
> Sent: Tuesday, May 7, 2019 10:55 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 Tue, May 07, 2019 at 07:30:11AM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > 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/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