Re: [CFRG] OCB does not have an OID specified, that is a general problem

Neil Madden <neil.e.madden@gmail.com> Tue, 08 June 2021 07:53 UTC

Return-Path: <neil.e.madden@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242D53A26E4 for <cfrg@ietfa.amsl.com>; Tue, 8 Jun 2021 00:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vKLJNnGI0NWk for <cfrg@ietfa.amsl.com>; Tue, 8 Jun 2021 00:53:35 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 13D7B3A26C9 for <Cfrg@irtf.org>; Tue, 8 Jun 2021 00:53:34 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id g204so1189134wmf.5 for <Cfrg@irtf.org>; Tue, 08 Jun 2021 00:53:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=GIvTP9UQ7OGAYkJy1svCN2Sbs95NPLEARLnoAy2xQjw=; b=F2F0qYQWd72SlKLL5RxKc2nQ00U362sR9hT2v0m7kCqo9At1kHLz9QmpoKmnMUB6k7 meDXN+5GMakouTpivX2A0GG8pCEyRKZY7l2FLhyzbIxuVei9Mcjvhi//Ln2ql0PerPvf +6RkpNHayYonqDFidQ6OiaEINeBbjHjDt9qNAK+2NHpUWKCSFaxu0H5amCJMvne4cPZg aBR3zWhyp0KxDgZOMUy82YtJx8eU9UgUR4qQnGQoilGcnGby9fjMeyef8eja9eWc7+7m F5AB1jx1JXjJGCJQkVmxJdaNJrkqh8X22hQIZLJRL4QHP+5SJdZbR1dkZqT/UMxPwnlq Ixig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=GIvTP9UQ7OGAYkJy1svCN2Sbs95NPLEARLnoAy2xQjw=; b=WEhdfRkZ7f1wcX3Ado+gL1SnrsmNePgM3D1w8nnuWkBMOhOSI3syVok9Pfyp8NVO9G xBOQnA2DuqpnLTjjs2frSWKmPugRyb9gBUXISVoP+gom+I488lxV0bvOLLvAzBwdSvo3 syKgTaKAmpms1WbOBLPwGkDJ1jzDfMr0l/CTNieMYYR2ulPvVW0kHEsZK/czBtDc4Ocr GR0qSKtwOnMBAmw8wdy/U062zd0n8s8gBgStGiSaCYiQHYnQvzRYfaR3K5w8AxVtYNnh TNcP5kgDZ6KPSPf0I9i37V5i+RJAFxasUshu73EDTNM+e30HvPEoI0tmlx4u8SJNvD8H 9M5Q==
X-Gm-Message-State: AOAM530iGEalrSkRml1bS0Lh3npYJYaOequWs6ceL2MMZY53bAtAHTdI ZF83NJBXEkqvlTnuUhiXaQ0=
X-Google-Smtp-Source: ABdhPJyx/efAatZsiKh3rp/xswYi1XeAMWAk4Z3f2Hq8axB5yrbOyafJlb1qvPl+q0UUpLgV5vniMg==
X-Received: by 2002:a7b:c417:: with SMTP id k23mr2703706wmi.71.1623138808242; Tue, 08 Jun 2021 00:53:28 -0700 (PDT)
Received: from smtpclient.apple (113.87.75.194.dyn.plus.net. [194.75.87.113]) by smtp.gmail.com with ESMTPSA id n2sm20221011wmb.32.2021.06.08.00.53.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 00:53:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-0032FC91-3F45-4DC5-A96F-AD9D192D3E07"
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.e.madden@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 08 Jun 2021 08:53:26 +0100
Message-Id: <D7B065DF-F0D8-451B-ADFA-2382A6440F10@gmail.com>
References: <CAMm+LwgUwj8w-2k63PN7EkOQzrD1-QW+EsXwx_K8fgkZCp0HzA@mail.gmail.com>
Cc: IETF SAAG <saag@ietf.org>, IRTF CFRG <Cfrg@irtf.org>
In-Reply-To: <CAMm+LwgUwj8w-2k63PN7EkOQzrD1-QW+EsXwx_K8fgkZCp0HzA@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
X-Mailer: iPhone Mail (18F72)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/bn3JaStM0sKLEQxRRfYwa1WN4pQ>
Subject: Re: [CFRG] OCB does not have an OID specified, that is a general problem
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2021 07:53:50 -0000

On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> 
>> On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <neil.e.madden@gmail.com> wrote:
>> Unless there is a compelling reason to do so, I’d prefer that registering algorithm identifiers for JOSE be a manual (and rare) step. JOSE provides no way for consumers to advertise which Encryption Methods they support (“enc” - which is what OCB would be), so adding new options here can only harm interoperability.
>> 
>> (This is in contrast to key agreement algorithms - “alg” - as these can be advertised in the JSON Web Key metadata).
> 
> I don't agree. JOSE has no algorithm negotiation mechanism because it is a format, not a protocol. After we went through the whole recommended/required algorithm thing on JOSE, it suddenly occurred to me that this was precisely none of JOSE's business. It is for the protocols and services built using XML Signature, JOSE, CMS etc. to decide what algorithms to require and/or recommend. 

Doesn’t this contradict your desire to have a single IANA algorithm registry? If individual application protocols are to state which algorithms to use then they need a registry each to state this. 

> 
> JWK is a protocol built on top of JOSE, so it makes sense for that protocol to specify recommended algorithms.

This is rather backwards: JWK is part of JOSE and indeed JOSE depends on JWK (see for example the “jwk” and “epk” headers). 

> But the recommendations made in the JOSE spec have absolutely no bearing on the Mesh which uses parts of JOSE because being written six years later, the state of the art has moved on. The Mesh does not support RSA at all and the elliptic curve algs are X448 and Ed448. The curve 25519 versions are not supported for profile signing, etc. etc.
> 
> I would expect the same to apply in the COSE world. Merely defining a code point for JOSE or CMS does not make a statement about the algorithm recommendation status.

Well it does actually - see the “JOSE Implementation Requirements” field: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

And the reason for this is because the algorithms are implemented by JOSE libraries. Indeed, this is the whole point of JOSE, that applications don’t need to implement their own algorithms but can just use a preexisting library. 

> All it does is specify the one canonical identifier every application will use. It is not at all important what that identifier is (provided it is not an absurd length) it is critical that everyone use the same identifier though.

If different applications are going to specify different algorithms then this somewhat argues against your point: they _don’t_ need to use the same algorithm identifiers as other applications in that case. 

But I think we’re rather getting off the track here because as I mentioned in my first email, OCB would be standardised as an Encryption Method (“enc” header value). This introduces more complications. JOSE supports encrypting a message to multiple recipients, each of which can use a different key management algorithm (“alg”). But the content of the message has to be encrypted using a common symmetric Encryption Method that all the recipients understand. This is why introducing new Encryption Methods is problematic because as the number of options goes up, the chances of finding an algorithm that all recipients agree on reduces.  

(The alternative is that we register as many new “enc” values as we like but they are all effectively ignored because everyone uses “A128CBC-HS256” as the only thing guaranteed to work everywhere. This is not the case currently because there are only a few “enc” options and so most libraries implement all of them). 

In 2021, I think OCB has very few advantages over JOSE’s existing GCM Encryption Methods, so I think it is much more trouble than it’s worth to specify it for use there. If we’re going to expand the “enc” registry I’d rather it was for an algorithm with significant advantages over the existing alternatives, such as misuse resistance or better performance on low-end hardware. 

— Neil