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

Benjamin Kaduk <kaduk@mit.edu> Fri, 03 May 2019 17:14 UTC

Return-Path: <kaduk@mit.edu>
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 ADAFC12028E; Fri, 3 May 2019 10:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 xRuivy7FQxmt; Fri, 3 May 2019 10:14:20 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 97F101202B1; Fri, 3 May 2019 10:14:16 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x43HE7ZD003228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 May 2019 13:14:09 -0400
Date: Fri, 3 May 2019 12:14:07 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: secdir@ietf.org, draft-ietf-dots-signal-channel.all@ietf.org, ietf@ietf.org, dots@ietf.org
Message-ID: <20190503171406.GO59871@kduck.mit.edu>
References: <155533088202.10777.9128855796755282458@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <155533088202.10777.9128855796755282458@ietfa.amsl.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/sNheS_8kZDy8XAV-Id1aAnyhwCw>
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: Fri, 03 May 2019 17:14:22 -0000

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

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

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

Thanks for the re-review and follow-up discussion!

-Ben