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

<> Mon, 15 April 2019 13:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73F921203A2; Mon, 15 Apr 2019 06:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Pfha5x7ptcU; Mon, 15 Apr 2019 06:16:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1F7D120390; Mon, 15 Apr 2019 06:16:37 -0700 (PDT)
Received: from (unknown [xx.xx.xx.5]) by (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 (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: <>
To: Stephen Farrell <>, "" <>
CC: "" <>, "" <>, "" <>
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: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [secdir] Secdir telechat review of draft-ietf-dots-signal-channel-31
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Apr 2019 13:16:44 -0000

Hi Stephen, all, 

Please see inline for the first item. 


> -----Message d'origine-----
> De : Stephen Farrell via Datatracker []
> Envoyé : lundi 15 avril 2019 14:21
> À :
> Cc :;;
> 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.