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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 14 July 2021 16:53 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0135E3A1F63; Wed, 14 Jul 2021 09:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.459
X-Spam-Level:
X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtZktxEqCEHK; Wed, 14 Jul 2021 09:53:11 -0700 (PDT)
Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DB83A24D4; Wed, 14 Jul 2021 09:53:00 -0700 (PDT)
Received: from dooku.sandelman.ca (cpef81d0f835a73-cmf81d0f835a70.sdns.net.rogers.com [174.116.10.168]) by relay.sandelman.ca (Postfix) with ESMTPS id 1BFDF1F479; Wed, 14 Jul 2021 16:52:58 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id D8C691A0484; Wed, 14 Jul 2021 12:52:55 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-core-sid@ietf.org
cc: "The IESG" <iesg@ietf.org>, core-chairs@ietf.org, core@ietf.org
In-reply-to: <162621573715.1426.3300364400283622807@ietfa.amsl.com>
References: <162621573715.1426.3300364400283622807@ietfa.amsl.com>
Comments: In-reply-to Benjamin Kaduk via Datatracker <noreply@ietf.org> message dated "Tue, 13 Jul 2021 15:35:37 -0700."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 14 Jul 2021 12:52:55 -0400
Message-ID: <219605.1626281575@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/-Zw5n_DeW57CvV2EJl36c5soblY>
Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jul 2021 16:53:15 -0000

Benjamin Kaduk via Datatracker <noreply@ietf.org> 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-