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

Christian Hopps <chopps@chopps.org> Fri, 03 May 2019 17:48 UTC

Return-Path: <chopps@chopps.org>
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 F411D120077; Fri, 3 May 2019 10:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 R0vs1qZ-Qb5m; Fri, 3 May 2019 10:48:48 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DDEB0120020; Fri, 3 May 2019 10:48:47 -0700 (PDT)
Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0C3E16019B; Fri, 3 May 2019 13:48:46 -0400 (EDT)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <F31D9718-4D27-4400-A99E-A2BF8E1BF636@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_52A404BE-FDA3-4D8A-86E4-A072146EB09C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Fri, 3 May 2019 13:48:45 -0400
In-Reply-To: <155499058804.22746.2191211977799773380.idtracker@ietfa.amsl.com>
Cc: Christian Hopps <chopps@chopps.org>, The IESG <iesg@ietf.org>, netmod-chairs@ietf.org, joelja@gmail.com, draft-ietf-netmod-module-tags@ietf.org, netmod@ietf.org
To: Benjamin Kaduk <kaduk@mit.edu>
References: <155499058804.22746.2191211977799773380.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/66CS6xn6AsvW4inA-xplPYP1C_k>
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: Fri, 03 May 2019 17:48:50 -0000


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

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

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

Chris.



> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>