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

Benjamin Kaduk <kaduk@mit.edu> Wed, 14 July 2021 17:32 UTC

Return-Path: <kaduk@mit.edu>
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 080EC3A0919; Wed, 14 Jul 2021 10:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 SoghFCrqlYbN; Wed, 14 Jul 2021 10:32:36 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943E33A091C; Wed, 14 Jul 2021 10:32:35 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16EHWOZw025502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jul 2021 13:32:31 -0400
Date: Wed, 14 Jul 2021 10:32:23 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: draft-ietf-core-sid@ietf.org, The IESG <iesg@ietf.org>, core-chairs@ietf.org, core@ietf.org
Message-ID: <20210714173223.GD74365@kduck.mit.edu>
References: <162621573715.1426.3300364400283622807@ietfa.amsl.com> <219605.1626281575@dooku>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <219605.1626281575@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/JS0uD9aUNwim_fwhBpGnZut9kns>
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 17:32:38 -0000

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

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