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

<mohamed.boucadair@orange.com> Mon, 15 April 2019 13:16 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 73F921203A2; Mon, 15 Apr 2019 06:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7Pfha5x7ptcU; Mon, 15 Apr 2019 06:16:38 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F7D120390; Mon, 15 Apr 2019 06:16:37 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 44jTY03n6pzFpbq; Mon, 15 Apr 2019 15:16:36 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 44jTY02F93zCqlN; Mon, 15 Apr 2019 15:16:36 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 15 Apr 2019 15:16:36 +0200
From: <mohamed.boucadair@orange.com>
To: 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 telechat review of draft-ietf-dots-signal-channel-31
Thread-Index: AQHU84W+t2C1NhRJPEGTSxi4oDGffqY9MHkg
Date: Mon, 15 Apr 2019 13:16:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155533088202.10777.9128855796755282458@ietfa.amsl.com>
In-Reply-To: <155533088202.10777.9128855796755282458@ietfa.amsl.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.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/aUx8Cf9sGdRDbxTJiPztk3MQgPc>
Subject: Re: [secdir] 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: Mon, 15 Apr 2019 13:16:44 -0000

Hi Stephen, all, 

Please see inline for the first item. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell via Datatracker [mailto:noreply@ietf.org]
> Envoyé : lundi 15 avril 2019 14:21
> À : secdir@ietf.org
> Cc : draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org;
> dots@ietf.org
> Objet : Secdir telechat review of draft-ietf-dots-signal-channel-31
> 
> 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

[Med] This is a feature not a bug. This scheme is particularly useful to recover state, for example, upon reboot or crash of a DOTS client. 

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