Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30
"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 15 March 2019 04: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 02D721311B9; Thu, 14 Mar 2019 21:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 yb2x6QsZkviN; Thu, 14 Mar 2019 21:30:24 -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 9221F1287C2; Thu, 14 Mar 2019 21:30:23 -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=1552624009; 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: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-forefront-prvs:x-forefront-antispam-report: received-spf:authentication-results: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=GECLkYsbxZnEPdjQfZZFYoEOBWz7GgNUOBRtv2 a6Vuc=; b=JHjtUPv2C08drjoHRTRWKgnsevB8N53hGwioqDTc 86dEePTkVL5PuvzW6kAN2RAx1qILTmaL7CXSaPUTEJYDP3gkgg 2cDwkoiu5kSYWwDyDVkE7yC7Du+Qo22bH1vByC1lRIJv8GYty6 5STPAphBEf2hGb960wtwiPo+V3oOki8=
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 4fb3_4565_5cc339cc_a699_4e22_bf9c_1d641836ee56; Thu, 14 Mar 2019 22:26:49 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 Mar 2019 22:30:09 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 14 Mar 2019 22:30:09 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 Mar 2019 22:30:08 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2968.namprd16.prod.outlook.com (20.178.235.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Fri, 15 Mar 2019 04:30:07 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1709.011; Fri, 15 Mar 2019 04:30:07 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-dots-signal-channel.all@ietf.org" <draft-ietf-dots-signal-channel.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30
Thread-Index: AQHU2oF5bx6+d1T5QkC+CtJqzs0JZ6YMGWiw
Date: Fri, 15 Mar 2019 04:30:07 +0000
Message-ID: <BYAPR16MB2790DBE16FFCC0A5B80C86B7EA440@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1b477aee-341e-44d3-58e1-08d6a8fee784
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2968;
x-ms-traffictypediagnostic: BYAPR16MB2968:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR16MB29688E6BE0022A9751223DF9EA440@BYAPR16MB2968.namprd16.prod.outlook.com>
x-forefront-prvs: 09778E995A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(39860400002)(366004)(346002)(32952001)(199004)(13464003)(189003)(71190400001)(110136005)(71200400001)(54906003)(97736004)(229853002)(476003)(966005)(186003)(478600001)(68736007)(52536014)(6246003)(9686003)(8936002)(6506007)(72206003)(4326008)(7736002)(74316002)(305945005)(6306002)(81156014)(80792005)(81166006)(53546011)(446003)(8676002)(11346002)(5660300002)(7696005)(5024004)(105586002)(33656002)(3846002)(102836004)(86362001)(256004)(6116002)(14444005)(316002)(66066001)(486006)(6346003)(2906002)(26005)(2501003)(25786009)(14454004)(76176011)(55016002)(53936002)(99286004)(106356001)(6436002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2968; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: AuThYxsKoZLy0koF2nfX5kZVWq+KKw4IX3SS+rWkOELuKhbBfupWNCHGK155gt/dNqS9tNnHS0RvjP6MGvwScB1YsipBapFUJ6CyMM+1D8OMAsGF5TG8jWiQWy6VeEqV2HATDCPTtrP8fXjHIKr+v2RY9JliCu1WrG3Cbd+ss9ar/uZ0kygGxm4teTfJykZ+dqrAZoAbx3CmzRcgxFIfMzG3pGMMZXnAVWmSkICxHBM8CH+EjiynwiBPZV7nkRZD2xJLZYlSW7crJXNtWlD+o4sJx7BmJM5aPL47mG/KxVw+xBq0hBxgz1OXEyHUbLEZl1cSUYYG+nPAwyrq8/TPDoatvGlySTpHl7pmusT9KD3u5JDYvSdfAlZsCY5sqo5CnZ4Z8mY+W9r4wxD/9tuIGvSGzlVylZeLdoV37g/wQWE=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b477aee-341e-44d3-58e1-08d6a8fee784
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 04:30:07.7352 (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: BYAPR16MB2968
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 <6503> : inlines <7034> : streams <1815743> : uri <2813012>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/CP38lybo5_Nqr-pRubVBNwnBuY8>
Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30
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: Fri, 15 Mar 2019 04:30:27 -0000
Please see inline > -----Original Message----- > From: Dots <dots-bounces@ietf.org> On Behalf Of > mohamed.boucadair@orange.com > Sent: Thursday, March 14, 2019 9:47 PM > To: Stephen Farrell <stephen.farrell@cs.tcd.ie>; secdir@ietf.org > Cc: draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org; dots@ietf.org > Subject: Re: [Dots] Secdir last call review of draft-ietf-dots-signal-channel-30 > > 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. > > Hi Stephen, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Stephen Farrell via Datatracker [mailto:noreply@ietf.org] Envoyé > > : jeudi 14 mars 2019 16:34 À : secdir@ietf.org Cc : > > draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org; > > dots@ietf.org Objet : Secdir last call review of > > draft-ietf-dots-signal-channel-30 > > > > Reviewer: Stephen Farrell > > Review result: Has Issues > > > > > > I think there's one issue with this draft that'd be well worth > > discussion and/or fixing: > > > > - p12: Why does the cuid need to be so static? I would have thought > > that an identifier that can change more often than a key pair would > > have been 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 much more easily changed. That could also > > mitigate the possible TLS1.2 client-cert snooping issue mentioned on > > p90. > > [Med] cuid is used for avoidance detection but also as a stable key to > identify resources at the server side. Any change of the cuid will lead to a > failure in accessing the resources. > Furthermore, this identifier is used to "glue" the signal and data channels. > > The spec does not forbid the clients to change its cuid, but to do so, the > client will need to manage state migration. > > > > > nits: > > > > - (Not really a nit, but probably too much to ask, so...) The protocol > > here seems very complex. Has anyone tried to prove anything about the > > state machine, e.g. > > that's it's safe in some senses? It'd be fair to say that that is a > > good task to do after the initial RFC is published in this case, I > > guess. OTOH, could be some of the theorem-proving tools used in the > > development of > > TLS1.3 could be useful here. (And those tools usually do turn up some > > issues worth fixing - I'd bet a beer they would in this case:-) > > [Med] The specification was edited following an incremental approach in > which new pieces are validated through at least two interoperable > implementations. We hope that more feedback will be received after the > initial RFC. > > > > > - p18: "Only single-valued 'cdid' are defined in this document." That > > confused me given the text 3 paras before about multiple cdid values. > > Maybe clarifying that some could be useful? > > [Med] What is meant here is the case where multiple GWs are involved in > the path; each inserts a cdid value. 'cdid' is only inserted by the server-domain DOTS gateway. Figure 8 needs to be corrected, 'cuid' is missing in the Figure. Cheers, -Tiru > > Will clarify the text. > > > > > - p77 has a few lowercase "should" and "must" statements. > > Not sure if that's on purpose or by accident. > > [Med] I confirm it was on purpose. These are not new requirements (see > Section 7.2). > > > > > - p90: Is the mention of TCP-AO there for real? I'd be happy it it > > were but if it's merely aspirational and you don't think it'll be > > used, it'd be better to not pretend it might get used. > > > > [Med] We are providing an example of how the issue can be solved. That is > fine, IMO. > > > - Couldn't a bad actor in control of an authorised DOTS client > > colluding with the controller of a DDoS attack use this to probe the > > system to see how their attack is going and change the attack to be > > more effective? > > [Med] The client will only see the reports for attacks it detected and signaled. > That bad actor won't signal the attack in the first place! > > I don't > > think any protocol change could help there, but perhaps you could give > > some guidance to implementers to try catch such cases (e.g., if the > > probing DOTS client's local n/w doesn't actually appear to be under > > attack). > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots
- [secdir] Secdir last call review of draft-ietf-do… Stephen Farrell via Datatracker
- Re: [secdir] Secdir last call review of draft-iet… mohamed.boucadair
- Re: [secdir] Secdir last call review of draft-iet… Stephen Farrell
- Re: [secdir] Secdir last call review of draft-iet… Konda, Tirumaleswar Reddy
- Re: [secdir] Secdir last call review of draft-iet… mohamed.boucadair
- Re: [secdir] Secdir last call review of draft-iet… mohamed.boucadair
- Re: [secdir] Secdir last call review of draft-iet… Konda, Tirumaleswar Reddy
- Re: [secdir] Secdir last call review of draft-iet… Stephen Farrell
- Re: [secdir] Secdir last call review of draft-iet… mohamed.boucadair
- Re: [secdir] Secdir last call review of draft-iet… Konda, Tirumaleswar Reddy
- Re: [secdir] Secdir last call review of draft-iet… mohamed.boucadair
- Re: [secdir] Secdir last call review of draft-iet… Michael Richardson
- Re: [secdir] Secdir last call review of draft-iet… Konda, Tirumaleswar Reddy
- Re: [secdir] Secdir last call review of draft-iet… mohamed.boucadair