Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Benjamin Kaduk via Datatracker <[e-mail]> wrote:
    > (1) I think there is a new security consideration with this work that
    > is important to document clearly -- not only do we define a new type of
    > identifier, but we define a file format and other mechanisms for
    > disseminating that information.  An entity that's processing
    > application/yang-data+cbor; id=sid information needs to ensure that the
    > .sid files (or other source of SID information) it uses for such
    > processing came from a trustworthy authority (or at least the same
    > source as the data file).  It would be possible for malicious
    > manipulation of .sid file contents to cause a message recipient to
    > mis-interpret the received message without any indication of such
    > tampering.

You are right.
While I guess it is conceptually correct to think that someone will create
some universal CORECONF recipient that can process .sid files and do
something real, I think that such a situation is probably not sane.

We also don't sign YANG files, except that, they are embedded in RFCs, which
are now signed.

(I don't think we have resolved the question of how/if/when we provide the sid
file to IANA when part of another RFC. In theory, IANA creates the sid file
when the YANG module is first provided. In practice, we need it for interop
work prior to WGLC)

We are using sid files for draft-ietf-anima-constrained-voucher, and we have
at least five implementations that we will test next week.
I don't think that any of us did anything other than transcribe the SID files
into a #define/enum or equivalent.
Now, we are working on YANG-at-rest rather than RPC.

Even if we got to the point where we could more sensibly pull .sid files into
our source code in more automated fashion, there is still the question of
semantics of what we are doing.

I suppose that we could ask IANA to JOSE sign the SID files.
If this is really something that we think we should do, then let's have a
discussion with IANA about doing that, and then write a new document.

So, let me propose this text:

OLD:
6.  Security Considerations

   This document defines a new type of identifier used to encode data
   models defined in YANG [RFC7950].  As such, this identifier does not
   contribute to any new security issues in addition of those identified
   for the specific protocols or contexts for which it is used.

NEW:
6.  Security Considerations

   This document defines a new type of identifier used to encode data
   models defined in YANG [RFC7950].  This new identifier maps semantic
   contents to integers, and if the source of this mapping is not trusted,
   then new security might be occur if an attacker can control the mapping.

   At the time of writing, it is expected that the SID files will be
   processed by a software developer, within a software development
   environment.  Developers are advised to only import SID files from
   authoritative sources.  IANA is the authoritative source for IETF managed
   YANG modules.

   Conceptually, SID files could be processed by unconstrained target
   systems such as network management systems.  Such systems need to take
   extra care to make sure that they are only processing SID files from the
   same authoritative source as the YANG modules that they are using.



--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-