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

Benjamin Kaduk <kaduk@mit.edu> Mon, 06 May 2019 15:35 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 DFECA12006D; Mon, 6 May 2019 08:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 1mBQIvQ-DzP7; Mon, 6 May 2019 08:35:21 -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 1E32D120047; Mon, 6 May 2019 08:35:20 -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 x46FZDTI011431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 May 2019 11:35:15 -0400
Date: Mon, 6 May 2019 10:35:13 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "dots@ietf.org" <dots@ietf.org>, "draft-ietf-dots-signal-channel.all@ietf.org" <draft-ietf-dots-signal-channel.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Message-ID: <20190506153513.GD19509@kduck.mit.edu>
References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <20190503171406.GO59871@kduck.mit.edu> <BYAPR16MB2790F46BC224F33C5240FEF2EA360@BYAPR16MB2790.namprd16.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BYAPR16MB2790F46BC224F33C5240FEF2EA360@BYAPR16MB2790.namprd16.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/nt5LobfW6nFfgbl5OFyLzxOo6eQ>
Subject: Re: [secdir] [Dots] 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, 06 May 2019 15:35:24 -0000

On Sat, May 04, 2019 at 08:40:30AM +0000, Konda, Tirumaleswar Reddy wrote:
> > -----Original Message-----
> > From: Dots <dots-bounces@ietf.org>; On Behalf Of Benjamin Kaduk
> > Sent: Friday, May 3, 2019 10:44 PM
> > To: Stephen Farrell <stephen.farrell@cs.tcd.ie>;
> > Cc: dots@ietf.org; draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org;
> > secdir@ietf.org
> > Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31
> > 
> > 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.
> > 
> > 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.)
> 
> As per the discussion with Stephen https://mailarchive.ietf.org/arch/msg/dots/H5JG69FJruwN7pM3j92L8wwtn-s, we have added "Appendix A. CUID Generation" and updated section 10 (please see the diff at 
> https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-signal-channel-31.pdf) 

I don't really see Stephen getting convinced, in that linked discussion.
(Also, the added Appendix A in the linked diff is past the 50-page boundary
that github loads by default, and it's failing to load more, for me.)

> 
> > 
> > > - 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.
> 
> This comment was discussed and resolved by adding the following lines:
> A DOTS client is entitled to access only to resources it creates.  In	
> particular, a DOTS client cannot retrieve data related to mitigation	
> requests created by other DOTS clients of the same DOTS client	
> domain.

This is good to have, but I think Stephen is still within his rights to ask
for text that explicitly considers what the scope of damage is when there
is a compromised DOTS client.

> Further, the draft points to DOTS security considerations discussed in DOTS requirements draft which says the following:
> 
>    To detect compromised DOTS agents, DOTS operators should carefully
>    monitor and audit DOTS agents to detect misbehavior and to deter
>    misuse, while employing current secure network communications best
>    practices to reduce attack surface.
> 
> > 
> > > 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.
> 
> We can update the use of TCP-AO as follows:
> 
> Although not widely adopted, if TCP-AO is used, then any bogus packets injected by an attacker will be rejected by the
> TCP-AO integrity check and therefore will never reach the TLS layer.

Okay.

-Ben