Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sat, 01 February 2020 00:55 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40C512002E; Fri, 31 Jan 2020 16:55:05 -0800 (PST)
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 YKCo8Ohys1gK; Fri, 31 Jan 2020 16:55:03 -0800 (PST)
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 B871E120013; Fri, 31 Jan 2020 16:55:03 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0110swHR008427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jan 2020 19:55:00 -0500
Date: Fri, 31 Jan 2020 16:54:57 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christian Hopps <chopps@chopps.org>
Cc: The IESG <iesg@ietf.org>, netmod-chairs@ietf.org, joelja@gmail.com, draft-ietf-netmod-module-tags@ietf.org, netmod@ietf.org
Message-ID: <20200201005457.GB91553@kduck.mit.edu>
References: <155499058804.22746.2191211977799773380.idtracker@ietfa.amsl.com> <F31D9718-4D27-4400-A99E-A2BF8E1BF636@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F31D9718-4D27-4400-A99E-A2BF8E1BF636@chopps.org>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OYoIg4OWeVETrF-zTR1n0VRf1Yk>
Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2020 00:55:06 -0000

Sorry for letting this sit so long; I must have missed it somewhere (and
thanks Alissa for the reminder!)

On Fri, May 03, 2019 at 01:48:45PM -0400, Christian Hopps wrote:
> 
> 
> > On Apr 11, 2019, at 9:49 AM, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > I think this document does introduce new security considerations,
> > specifically the ability for one user to remove ("mask") tags from being
> > visible to other users.  A malicious user could interfere with the
> > operations of other users/entities, especially in the case mentioned in
> > an example where multiple semi-independent clients use tags to indicate
> > modules to avoid that may be broken.
> 
> So here was the thinking on this, since this document doesn't define any actions or behaviors based on tags (or the lack of them) it's hard to talk about what the security considerations would be. However, it is expected that to be useful users (or future specifications) *will* define behaviors based on tag use. The security section does talk about this case:
> 
> "
>    Users of the tag-meta data may define various actions to be taken
>    based on the tag meta-data.  These actions and their definitions are
>    outside the scope of this document.  Users will need to consider the
>    security implications of any actions they choose to define.
> "
> 
> Which I believe covered this. For example, if an RFC were to define a behavior based on the tag presence then it would need to talk about the security concerns with that behavior.

In some sense it covers this, but my Discuss is more about the
somewhat-subtle point involving somewhat "long-range" interactions that it
doesn't seem reasonable to expect people specifying tags to think about
without help.

> If this doesn't adequately cover your concern though, do you have a bit of suggested text we could add?

I'd suggest to add another clause at the end of the paragraph you quoted:
", including the potential for a tag to get 'masked away' by another user."

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> 
> > 
> > Section 2
> > 
> > Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better
> > than "standard prefix".
> > 
> > Section 2.4
> > 
> > Similarly, "future registration" or "future use" seem to be better fits
> > for the intended sentiment.
> > 
> > Section 3.2
> > 
> > I may be misreading, but this seems to be encouraging implementations to
> > add new ietf:-prefixed tags that are not necessarily registered or
> > specified in IETF-consensus documents.
> > 
> > Section 7.2
> > 
> >   This registry allocates prefixes that have the standard prefix
> >   "ietf:".  [...]
> > 
> > The registry name just talks about "tags"; are we really allocating
> > *prefix*es?
> > 
> 
> Fixed these, thanks.

Thanks!

-Ben