Re: [core] comments on CORECONF drafts in WGLC

Ivaylo Petrov <ivaylo@ackl.io> Sun, 12 April 2020 17:21 UTC

Return-Path: <ivaylo@ackl.io>
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 51BAD3A108A for <core@ietfa.amsl.com>; Sun, 12 Apr 2020 10:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com
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 RQIwoS0VYnE9 for <core@ietfa.amsl.com>; Sun, 12 Apr 2020 10:21:05 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC6D3A1085 for <core@ietf.org>; Sun, 12 Apr 2020 10:21:04 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id s8so7999929wrt.7 for <core@ietf.org>; Sun, 12 Apr 2020 10:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f3xHPj0Ayr/x8AeUSlibYCgfv27mfh44B5hmyA/iAvA=; b=z3s9veJVdsaaIoGcmHI/jVkRoujx6lZE0tay5alGpmw1ZwJSAGqdS0vD9NHK1rpVUQ tzjI/oRavmgNxE+mZTO8QTpujUVVfUC+DQVTmNcIpA3MBDuvTnWBK1EubcMODh72UAfM CRyG35a6DvWnSxbeW5GIsHfb0uz8g8zxWh6N0/Ou9KKK2RoFUYYhaINU/QQAJEB67pUM yAa34XNaCrNcuFKby64fzw1oAQAtqUhG7KiBwsONb3EA00L4k945mcr3JTK0iJQSF8xY cbpmbYHm5WAtH7ShMtE3MRC+NEI/aoMtW9DpzPjlYUFTnJUm9AjvmQK35IKxVMQgkhgx 7hFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f3xHPj0Ayr/x8AeUSlibYCgfv27mfh44B5hmyA/iAvA=; b=Ea5i2R3Qg41GlT0n+bQGVS6DX+WgLbrgip087a4+FGpEW9yJd5OuVQNEhYga4AN0cw DYZkyyObZZPgtnTtG/ETFYO65u8FgrR62X1F3o1Z+RcJYAXdDqmjOii5tBa2G5lw/tMw juXA6vSqmxqgZh52LbB6eQ+n2Ffbv94y9HXUp/VlAFF+nmgRMSpAks8jZ1TLf+cTpCaY V7A/IdrIeXLV3nj9mejw+ZXjpKLBA3WFL4gr1thBO2WjhVqHnwiOL0X/62HodwJFqhdG 04jv5xvTHD5qOQClTyi98rdXRkV6uyjoz5we8wPwP5mG88EfTjrJX6zYchkGZG0faSnd wbzg==
X-Gm-Message-State: AGi0PuZCdL1Ot75Fn87uC/einkEsG0ltmETUD9wisABchAhOw4Y28GVM EuCOGfaPh+uWjUHgpx6CDhA/zIcK/dEh+bItwPIhj/20t90=
X-Google-Smtp-Source: APiQypLRhJ860RDvyiTss7q0yrSgtBLlH6gIJa1pFPKb7WdOfIX7OF56eANztyeip9p9dio216j+P7JV3Y2eklrF2uA=
X-Received: by 2002:adf:c188:: with SMTP id x8mr14135839wre.136.1586712063004; Sun, 12 Apr 2020 10:21:03 -0700 (PDT)
MIME-Version: 1.0
References: <26233.1585585343@localhost>
In-Reply-To: <26233.1585585343@localhost>
From: Ivaylo Petrov <ivaylo@ackl.io>
Date: Sun, 12 Apr 2020 19:20:37 +0200
Message-ID: <CAJFkdRw8dZoz_DWCcBd7DFNSOMMJ7kgpevVDJ0+uzKqqoc4M6w@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: core <core@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e064cf05a31b30a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/D7f2tw-VncaU4mFNiqmEZZ57Gkk>
Subject: Re: [core] comments on CORECONF drafts in WGLC
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: Sun, 12 Apr 2020 17:21:08 -0000

Hello Michael,

Thank you for the review and the comments! Please find my answers below
prefixed by [IP]. You can find the resulting diffs at the following link
[1].

Best regards,
Ivaylo

[1]:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-comi.txt&url2=https://core-wg.github.io/comi/draft-ietf-core-comi.txt

On Mon, Mar 30, 2020 at 6:22 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Hi, I have read:
>
> — draft-ietf-core-yang-cbor-12
> — draft-ietf-core-sid-11
>
> I have implementation experience, and I've used these in other protocols,
> and
> I strongly agree that they are ready for publication!
>

[IP]: Thank you for your reviews and helping us get them to that state!

I read the COMI document some time ago, and I thought the approach was
> fine.  I do not have any implementation experience, so I have no attempted
> to
> understand the document at that level of detail.
> I would have liked to use COMI directly as part of
> ietf-6tisch-minimal-security's
> CoJP, but we would up creating a bespoke CBOR encoding, which is
> unfortunate.
>
> I suggest that the COMI document include the word "CORECONF" in it's title.
>   -> "CoAP Management Interface (CORECONF)"
> as I think that it is the starting document that leadds to the other three
> documents.  This will make it easier to find in rfc-index.txt.
>

[IP]: That sounds indeed a good way to go forward. Unless someone objects,
I am going to apply this change with the next revision.

>
> The security considerations, and authorization for this system is
> underspecified.  This was ultimately was killed SNMPv2, and led to a
> multi-decade long failure of SNMPv3.
> I suspect that this part will have a difficult time with security ADs.
>

[IP]: I tried to improve this section to some extent. Please let me know if
you have other ideas. Text contribution is always welcomed as well.

I think that a stronger link to ACE, is in order, and an introspective
> interface (using COMI!) into the authorization mechanism would help.
> This could be new work, and I suspect that there are many in t2trg and out
> in
> industry groups like OCF and CHIP that would like to have such a thing, but
> it is a non-trivial amount of work.
>

[IP]: I added an informational link to ACE, which for me seems as one of
the ways authorization can be handled in COMI. Is this what you have in
mind?


> I read draft-ietf-core-yang-library-01 when it was adopted.
> I have *no* expertise on the YANG in this document, and I have no expertise
> building network management systems that would need to this level of
> introspection.
>
> As I understand it, this module provides a constrained version of
> ietf-yang-library, the purpose of both is to describe which modules a
> device
> supports.
>
> I have no experience with introspection of devices like this, even doing
> SNMPv2 going back decades: it either worked or it didn't, usually it
> didn't,
> and one just guessed what the device supported, or read the manual.
>
> I understand the goals here, but I'm not certain, particularly in a
> constrained *network* that there is value in doing this.  I think that I'd
> rather get this information from a URL provided in an RFC8520 (MUD).
> I don't object to it though.
>

[IP]: Thank you for your thoughts on that one! I believe Michel Veillette
would best reply to the pros and cons of using URL in a MUD file vs this
document, but it seems to me that they would still address slightly
different use cases and probably there is value in having both supported.

I wonder if queries against this module could be answered with static
> content generated at compile time, and therefore from "ROM"?
>

[IP]: I would imagine so.

I disagree with the Security Considerations, that knowing the list of
> modules helps the attacker to the extent that it is important to provide
> specific read controls on it.  Attackers already have a copy of the ROM ;-)
> I would say that the entire COMI interface needs authorized read access,
> and
> this module no more than any other module.
>

[IP]: I believe the idea here is that the attacker doesn't necessarily know
which ROM the device is using. Having an easy way to discover that and from
there all the possible vulnerabilities of that device is what we want to
avoid. Otherwise I agree that the entire CoMI interface needs authorized
read access.


> I think that there might be future opportunities to link some of this work
> to
> the SUIT work, to the CoSWID work, and maybe to the RATS work.
>

[IP]: I strongly agree with this, but from all the different IoT security
options, I am currently not sure which ones would be best suited for CoMI
in different situations. Do you have ideas for concrete drafts and use
cases?

--
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>