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

[Benjamin Kaduk <[e-mail]>]

On Wed, Jul 14, 2021 at 12:52:55PM -0400, Michael Richardson wrote:
> 
> 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.

I don't expect it to be the common case, right -- people will just hardcode
in their software the SIDs they care about.  But they do still have to get
the SID information from somewhere (as you note in your proposed text
below)...

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

... and "obtained from IANA over https" seems like it would qualify as use
of a trusted authority for both .sid files and YANG modules, under most
threat models.

> (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)

(Also an interesting question, but probably not something that needs to be
enshrined in the RFC.)

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

Sure, I'm not proposing to hold up this document until there's a new
technical solution, but rather to document the topic.

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

"new security might be occur" doesn't make much sense to me, but "new
security risks might occur" would.

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

This looks really good, thanks.

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

This topic also seems worth covering, so thanks for including it.
It's not entirely clear to me that it's a security requirement to use the
exact same source for YANG module and SID files or some other trustworthy
authority might be acceptable, so we might want to think about this some
more.

Thanks again,

Ben