[Cbor] Mitigating a squatted code point (CBOR Tag 42)

Carsten Bormann <cabo@tzi.org> Wed, 14 August 2019 14:19 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 54FAB12083C; Wed, 14 Aug 2019 07:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AdexJuhJzQUU; Wed, 14 Aug 2019 07:19:36 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8893712084D; Wed, 14 Aug 2019 07:19:36 -0700 (PDT)
Received: from [] (p548DCCB9.dip0.t-ipconnect.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 467sCp4v5lzytk; Wed, 14 Aug 2019 16:19:34 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
Date: Wed, 14 Aug 2019 16:19:34 +0200
Cc: iana-prot-param-comment@iana.org, yot@ietf.org
X-Mao-Original-Outgoing-Id: 587485172.70258-645da2994bcbab30c4d1cd301c67a08e
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE33BDCF-DC17-4DD6-A3F6-F963749F42CA@tzi.org>
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/07l6p6tza_WcpYVFxCST9TwNDiY>
Subject: [Cbor] Mitigating a squatted code point (CBOR Tag 42)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2019 14:19:40 -0000

Recently, for yang-cbor, Tag number 42 was allocated.

Unexpectedly, this got the attention of the IPLD/IPFS people:

It looks like they had been squatting on Tag number 42 for a while and were caught by surprise that this now was allocated.

Normally, we don’t encourage squatting, so the usual answer would be “your own fault”.
However, in this case, a mitigation seems easy:

* Move YANG Schema Item iDentifier (sid) from 42 to 47.
* Get a reasonable specification out if the IPLD/IPFS people that we can use for registering their tag 42 (see the above github issue for 80 % of this, which just needs to be stitched together properly).

IPLD/IPFS would have a hard time fixing their tag number, as that is embedded in Merkle trees already out there.  This makes it more likely we would see dual use of Tag 42 both for YANG SID numbers and for IPLD CID byte strings.  I think we should avoid this if it is cheap for us to do this.  The YANG-CBOR people tell us that right now the damage from going from 42 to 47 would be very limited.

I’d like to discuss this at the CBOR Virtual Interim in 40 minutes — both the specific case, and what we could be doing to make further occurrences of this less likely.

Grüße, Carsten