Re: [T2TRG] [core] Disclosing Implementation Information: draft-bormann-t2trg-rel-impl-01.txt

Christian Amsüss <christian@amsuess.com> Mon, 30 March 2020 06:23 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7D43A0E6D for <t2trg@ietfa.amsl.com>; Sun, 29 Mar 2020 23:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level:
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[KHOP_HELO_FCRDNS=0.276, 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 T8TOFFjly5QB for <t2trg@ietfa.amsl.com>; Sun, 29 Mar 2020 23:23:45 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4219A3A0E59 for <t2trg@irtf.org>; Sun, 29 Mar 2020 23:23:44 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3FCCC40023; Mon, 30 Mar 2020 08:23:42 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 359296C; Mon, 30 Mar 2020 08:23:41 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c523:37b8:17ac:e8e3]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 02F5A121; Mon, 30 Mar 2020 08:23:41 +0200 (CEST)
Received: (nullmailer pid 1884464 invoked by uid 1000); Mon, 30 Mar 2020 06:23:28 -0000
Date: Mon, 30 Mar 2020 08:23:28 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Carsten Bormann <cabo@tzi.org>, Klaus Hartke <klaus.hartke=40ericsson.com@dmarc.ietf.org>
Cc: t2trg@irtf.org, "core@ietf.org WG" <core@ietf.org>
Message-ID: <20200330062328.GA1882848@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT"
Content-Disposition: inline
In-Reply-To: <HE1PR07MB4346BBD0DC88E28D1CAD1D4DE6CA0@HE1PR07MB4346.eurprd07.prod.outlook.com> <C1A0817E-8243-49A7-9CEA-BD38270C5028@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/BZOL6yTvWdVIlDZN-sXXHGjPh6M>
Subject: Re: [T2TRG] [core] Disclosing Implementation Information: draft-bormann-t2trg-rel-impl-01.txt
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2020 06:23:48 -0000

On Fri, Mar 27, 2020 at 05:13:19PM +0100, Carsten Bormann wrote:
> Comments (+1, -1, or actual text) would be welcome, both from T2TRG
> and from CoRE.  It seems the CoRE working group might want to consider
> working group adoption of this draft or a next version, at which time
> it would transition from the RG context to the WG.

+1 on making implementation information something that is common, and on
rel-impl as a starting point.

We're seeing millions of CoAP devices on the Internet now, and I'm
rather confident some of them do not implement all the amplification
mitigation RFC7252 says they should do. With implementation information,
reactions to large-scale attacks amplified through them can be made into
a productive "everyone still using version X of Y *please* update to X2,
which has been released two years ago already" rather than a blunt
"Don't use CoAP".

Servers written using aiocoap have been showing a link to the library
version by default[1] since version 0.4b1, and I've heard some positive
feedback from the RIOT community towards making this default as well.

> Would it make sense to standardize how to exactly express the
> information about the implementation and version? Being able to find
> that information seems useful -- but incomplete :-)

Structured information can be there in the payload using media types, as
Carsten pointed out.

I know some neat metadata format that can either embed such
representations, or just include them if they use the same metadata
format[2], but practically expect that the operators or tools that look
those up will manage to follow the link.

KR
c

[1]: https://aiocoap.readthedocs.io/en/latest/module/aiocoap.resource.html?highlight=wkc#aiocoap.resource.WKCResource
[2]: 
```
core: impl-info <https://example.com/product1/0.99b1> {
    base:representation h'a2....' { http:type "application/metadata+cbor" }
    # alternatively
    versioninfo:vendor "Example Ltd"
    versioninfo:product "ProductOne"
    versioninfo:semver "0.99b1"
}
```

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom