Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30
<mohamed.boucadair@orange.com> Fri, 15 March 2019 07:39 UTC
Return-Path: <mohamed.boucadair@orange.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 51E041311EC; Fri, 15 Mar 2019 00:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 XecqrQmYxhL0; Fri, 15 Mar 2019 00:39:26 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF6A12797C; Fri, 15 Mar 2019 00:39:25 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 44LHXD0996zCrqD; Fri, 15 Mar 2019 08:39:24 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 44LHXC5qlKzDq7S; Fri, 15 Mar 2019 08:39:23 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0439.000; Fri, 15 Mar 2019 08:39:23 +0100
From: mohamed.boucadair@orange.com
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.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: AQHU2oF5RsTGH2X350i3IMDpwuRCCqYMGWiwgAA0gEA=
Date: Fri, 15 Mar 2019 07:39:22 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA3E549@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790DBE16FFCC0A5B80C86B7EA440@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB2790DBE16FFCC0A5B80C86B7EA440@BYAPR16MB2790.namprd16.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/URGqda2dTzTJeWJujtNW-LBfov8>
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 07:39:28 -0000
Hi Tiru, Please see inline. Cheers, Med > -----Message d'origine----- > De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > Envoyé : vendredi 15 mars 2019 05:30 > À : BOUCADAIR Mohamed TGI/OLN; Stephen Farrell; secdir@ietf.org > Cc : draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org; > dots@ietf.org > Objet : RE: Secdir last call review of draft-ietf-dots-signal-channel-30 > > 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. [Med] I added this NEW text to clarify the comment from Stephen: OLD: Only single-valued 'cdid' are defined in this document. NEW: Only single-valued 'cdid' are defined in this document. That is, only the first server-domain DOTS gateway can insert a 'cdid' value. This specification does not allow multiple server-domain DOTS gateways, whenever involved in the path, to insert a 'cdid' value for each. Figure 8 needs to > be corrected, 'cuid' is missing in the Figure. [Med] Figure 8 is correct.
- [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