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

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 31 Jan 2020 16:54:57 -0800

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 <[email-masked]> 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