> On Apr 11, 2019, at 9:49 AM, Benjamin Kaduk via Datatracker > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
