[COSE] Why you shouldn't have your crypto designed by a CEO

Carsten Bormann <cabo@tzi.org> Fri, 07 January 2022 15:05 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BC63A080E for <cose@ietfa.amsl.com>; Fri, 7 Jan 2022 07:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 b0U07iw7hHO8 for <cose@ietfa.amsl.com>; Fri, 7 Jan 2022 07:05:02 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24C33A0815 for <cose@ietf.org>; Fri, 7 Jan 2022 07:03:31 -0800 (PST)
Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JVmgj26gCzDCf1; Fri, 7 Jan 2022 16:03:29 +0100 (CET)
From: Carsten Bormann <cabo@tzi.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mao-Original-Outgoing-Id: 663260608.8980711-f0fa9094193eb7e53d3fa34960c6e3dd
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Fri, 07 Jan 2022 16:03:28 +0100
Message-Id: <DC93BD3D-E0F6-464E-8E66-B341205DBC80@tzi.org>
To: cose <cose@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/8ywbcUy-YQZUh0JF4W5Tto1dCvg>
Subject: [COSE] Why you shouldn't have your crypto designed by a CEO
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2022 15:05:07 -0000

In the IETF we focus on making building blocks, which are then used to create products and deployments.

Personally, I generally focus on creating quality building blocks and try to ignore whether those ultimately lead to design wins or not.

But I can’t help seeing a whole little industry creep up that is interested in creating alternative building blocks that appear to be of interest to the creators so they can attain control over them and perform rent seeking from that control.

This is, of course, an old game in standardization, but it is reaching new heights in the area of standards for signing things.

Under the guise of writing tutorials about this subject field, IETF building blocks are disparaged and the “new” wares are peddled instead.  Within the bubbles created by this, it may seem the IETF standards are done with and the “alternatives” can be presented as the way to go.

Marketing is a necessary component of technology development, but it should not be built out of hatchet jobs and, er, alternative facts.

For those looking for an example, try exhibit [1].  After a brief tutorial (which is always welcome), various approaches are discussed.  JOSE (with JWS and JWT) is correctly presented as the “elephant in the room”, but then immediately disqualified because of the single misfeature that JOSE stores the algorithm identifier with the signature.  The author mentions RFC 8725, but either hasn’t read it or doesn’t want to mention that this immediately deflates his only(!) argument against JOSE.

Note that exhibit [1] is from August 2021, but doesn’t even mention COSE.  Probably because COSE is a convincing successor to JOSE in the space he is targeting, with implementations out there that have taken lessons from early JOSE implementations.
Instead, the piece presents [2] as evidence that “PASETO is progressing toward an IETF standard”, but then quickly deflects any potential response that it isn’t, by saying "it is important to note that [IETF] acceptance does not really matter from a security perspective" ([2] itself says the same thing in other words as well).  Of course, he later argues against crypto agility, “any of the SHA-2 functions are fine. Pick one and use it everywhere, don’t try to design in agility at the protocol level”.

I’m going to spare you from further analysis of this pamphlet and will only add [3] as a link offering a probably explanation why this piece was written.

I’m wondering whether we (the set of individuals interested in this, certainly not the WG as an IETF construct) need do to more in offering factual material to the channels that are being used for this “marketing”.

Grüße, Carsten

[1]: https://dlorenc.medium.com/signature-formats-9b7b2a127473
[2]: https://github.com/paseto-standard/paseto-rfc
[3]: https://chainguard.dev/posts/2021-10-07-introducing-chainguard