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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 13 Jul 2021 15:35:37 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-sid-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-sid/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

(2) Per §7.4.2, YANG SID range registries with public ranges MUST
include a reference to the ".sid" file for such ranges, but the
IANA-managed YANG SID range registry established by §7.5 does not, in
and of itself, make such a provision.  This function seems to be served
by the "IETF YANG SIG Registry" created by §7.6, so we may just need to
point to the one registry from the other in order to remain internally
consistent.

(3) There may be another inconsistency to look into; Section 7.6.2 says
that:

   *  If another ".sid" file has already allocated SIDs for this YANG
      module (e.g. for older or newer versions of the YANG module), the
      YANG items are assigned the same SIDs as in the other ".sid" file.

But we are supposed to allocate a new SID for a YANG item if its
semantics change in a revision of the YANG module.  Perhaps it's just
the "for older or newer versions of the YANG module" phrase that needs
tweaking?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The yangdoctors review mentioned the structure extension from RFC 8791,
and the authors (understandably) expressed reluctance to make such a
large change at this stage in the process.  I'll note that the DOTS WG
has recently completed work on a "bis" of RFC 8782, with primary aim of
replacing yang-data with structures and minimal other changes.  (A
yangdoctors review of a related document was sufficiently insistent that
structures are the right way to do this that the WG was convinced to put
in the effort.)

The yangdoctors review also asked why sid-file/module-name is optional,
which was tagged for follow-up.  I have the same question and am
interested in the outcome of the discussion amongst the authors.

If SIDs are supposed to be globally unique identifiers, the reference in
the YANG module to "namespace" identifiers for individual allocations is
puzzling to me.  The presence of a namespace would typically allow for
identifier reuse across namespaces (e.g., using the same SID integer value
for an identity and a data node within the same module).  I see how the
current list structure makes it easy to have a single flat list of all
identifier/sid mappings, but if the SIDs truly are globally unique, then
the "namespace" should not be a list key, and might be less confusingly
described as just indicating the type for which the SID is used.  (It
would also be possible to have separate lists for module SIDs, identity
SIDs, etc., but it's not clear that doing so is actually the right
approach.)

Section 1

   [...] If the
   meaning of an item changes, for example as a result from a non-
   backward compatible update of the YANG module, a new SID SHOULD be
   assigned to it.  A new SID MUST always be assigned if the new meaning
   of the item is going to be referenced using a SID.

That predicate seems in general unknowable ("you can't prove a
negative", etc.), so it's tempting to just require that if the old
semantics had a SID that the new semantics get one as well.

Section 4

If the scope of a sid-file-version-identifier resets when the module
revision is bumped, it seems highly unlikely that we'll need 64 bits of
identifier for it.

Section 5, 7.3

It's not entirely clear that we need to mention the
content-type/content-format in this document, as we only indicate use of
the JSON encoding for the .sid file and the use of SIDs in the
application/yang-data+cbor; id=sid case seems adequately described by
the existing treatment in draft-ietf-core-yang-cbor.

Section 7.4.1

I appreciate that the "mega-range" allocations are sized for the
appropriate SI prefix :)

   The information associated to the Organization name should not be
   publicly visible in the registry, but should be available.  This
   information includes contact email and phone number and change
   controller email and phone number.

Available to whom?

Section 7.5.2

   The size of the SID range allocated for a YANG module is recommended
   to be a multiple of 50 and to be at least 33% above the current
   number of YANG items.  This headroom allows assignment within the
   same range of new YANG items introduced by subsequent revisions.  The
   maximum SID range size is 1000.  A larger size may be requested by
   the authors if this recommendation is considered insufficient.  [...]

If there's a maximum size for a range, then asking for a larger one is
pointless.  Please reword to indicate the actual intent (maybe
s/maximum/typical expected/ or similar).

   In case a SID range is required before publishing the RFC due to
   implementations needing stable SID values, early allocation as
   defined in [BCP100] can be employed.  As specified in Section 4.6 of
   [RFC8126], RFCs and by extension documents that are expected to
   become an RFC fulfill the requirement for "Specification Required"
   stated in Section 2 of [BCP100], which allows for the early
   allocation process to be employed.

While the first bit of this is all true, the registry here doesn't use
the "Specification Required" policy for any range, and early allocations
are available for the "RFC Required" range.  So we should probably tweak
or remove the second sentence.

Section 7.6.3

   Early Allocations are made with a one-year period, after which they
   are expired.  [BCP100] indicates that at most one renewal may be
   made.  For the SID allocation a far more lenient stance is desired.

   1.  An extension of a referencing documents Early Allocation should
       update any referenced Early Allocations to expire no sooner than
       the referencing document.

   2.  The [BCP100] mechanism allows the IESG to provide a second
       renewal, and such an event may prompt some thought about how the
       collection of documents are being processed.

The first point is rather curious, since it can have no normative force
(this is not a BCP that would override BCP 100) and is merely a
continnation of how a more lenient stance is desired.  It's rather odd
to see it written in this way.  The second point seems to be the only
really useful part, and in practice this IESG approval of second (and
more!) renewals has become rather common, to the extent where a revision
of BCP 100 has been discussed to change the discussion of extensions for
early renewals.

   This is driven by the very generous size of the SID space and the
   often complex and deep dependencies of YANG modules.  Often a core
   module with many dependencies will undergo extensive review, delaying
   the publication of other documents.

Having many *dependencies* and taking a while shouldn't delay
publication of anything else; however, having many other modules
dependent on a core module would be likely to do so.

Appendix A

IIRC the mismatch between "[email-masked]" and the toplevel
"module-revision" of "2020-02-05" was noted by an earlier reviewer, but
I'll mention it here just in case I do not remember correctly.

NITS

Section 1

   SIDs are assigned permanently, items introduced by a new revision of
   a YANG module are added to the list of SIDs already assigned.  If the

comma splice

Section 5

        Each .sid file contains the mapping between the different
        string identifiers defined by a YANG module and a
        corresponding numeric value called YANG SID.";

singular/plural mismatch "numeric value called YANG SID"/"string
identifiers"

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jul 2021 12:52:55 -0400

Benjamin Kaduk via Datatracker <[email-masked]> 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

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Jul 2021 10:32:23 -0700

> 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

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

> when the YANG module is first provided. In practice, we need it for interop

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

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

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

>    authoritative sources.  IANA is the authoritative source for IETF managed

This looks really good, thanks.

>    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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jul 2021 15:32:41 -0400

{again, not an author of this document}

    > (Also an interesting question, but probably not something that needs to be

Someone has to document some interaction with IANA.
I guess draft-ietf-anima-constrained-voucher, close to WGLC, will show us
whether we got things right or not :-)
{insert curse about living in interesting times}

...

    > authority might be acceptable, so we might want to think about this some

I'm just trying to say: if you trusted IANA for the .yang, then trust them
for .sid.  If your source of truth was IEEE, then get the .sid from them too.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Jul 2021 21:28:56 -0700

> {again, not an author of this document}

(thanks for the reminder!)

> for .sid.  If your source of truth was IEEE, then get the .sid from them too.

And I'm saying that doing that is clearly safe and a defensible course of
action.  There may also be other safe courses of action, though, so I don't
want to commit us to "need to use the same source for YANG modules and SID
files" without having it be a considered decision.

-Ben