Re: [jose] Call for Adoption: draft-jones-jose-fully-specified-algorithms
Orie Steele <orie@transmute.industries> Fri, 05 January 2024 22:52 UTC
Return-Path: <orie@transmute.industries>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCF3C26F268 for <jose@ietfa.amsl.com>; Fri, 5 Jan 2024 14:52:42 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMV5vgMvv3tU for <jose@ietfa.amsl.com>; Fri, 5 Jan 2024 14:52:37 -0800 (PST)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDD9C26F267 for <jose@ietf.org>; Fri, 5 Jan 2024 14:52:37 -0800 (PST)
Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-28d0052beb0so90420a91.0 for <jose@ietf.org>; Fri, 05 Jan 2024 14:52:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1704495157; x=1705099957; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wxvbLaoTd30guUNk7uvSgyLXdWG026S1R7zUS0/vENk=; b=T++eteYc58l+S0zeJkgbOdykU/FwtKoKPEZxU198Cg9LG/i6Rir8Plj/bYBIM8JJUn YNYWDs2J1HdMMLRLprvKifjIZBR7U5qRCyJJ/nSwATYBxnRt0xin1VAdfl9UJfTuaj5B YhnLnHyPg4xJLk1WBWIutdMRaxR5h0DCU5GwFDI5ir6rpZ7Xbql99luEYoeqhi+vnFrs xnYBjl/fKN5rLCv1WNBMHDErnZDdirQm9zzkD8ag76BOhy1vjXCGWuRW/f9Xry4ad5AI f95bltwhs7nIFkeq3BtwfhTPGuyjWOQT1wvwFfUrwOe5RWdYlPNtIkFBQLWjnSWvoEN6 QgQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704495157; x=1705099957; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wxvbLaoTd30guUNk7uvSgyLXdWG026S1R7zUS0/vENk=; b=OMcN6pjg2WNbgP6RItJfCipSGdGHV/weQOky6s3YbXdWVj9jkknvT8NyGAh/bctOGc fWuV4q8OhRS4SyKPtlKlKkt7Gpu8nh3Q2Ck7eQwxKvxS/QGhebxEzcs9n7x3K9pN2mxQ XO/SZJVQXb3k+tE5Lbo8SJRSNrWNMLQEPeJ5vlNT9DO+Hys95niPVARvs4SvhpY91nKw SLmfq6GyzDUTF2Kk+F4rE3P14B9F52jk+w/BxryttOltMbJLWEFTDdJqV8bproUF6mu0 /vjivx7sXVr2VEQO5wcmR0iMiy0v2xxmJDX9WBTdlQU7hhpawlUULaKGe1i5epoLiE5y 6+EQ==
X-Gm-Message-State: AOJu0YxvwW/88UhtGLedtpI8qmq1jOuA53b/wPgkdZDNf4wg/QQwX29E MM70pFRSMBb7Phuma9uUgXYqejyh+WNbtnh/CkMn7HuXz02cZ4TNpTEbZYoPmlWiCw==
X-Google-Smtp-Source: AGHT+IH5Nd4AKEqcBe34hHOwwkp8IRCPrUcFQE2DAww1v5GyiJ0KUhMEqZozkEJCdvqtaJ0v3PFp+GLobSdy3m5jjh0=
X-Received: by 2002:a17:90a:854b:b0:285:8a2a:173f with SMTP id a11-20020a17090a854b00b002858a2a173fmr159935pjw.0.1704495157027; Fri, 05 Jan 2024 14:52:37 -0800 (PST)
MIME-Version: 1.0
References: <CA+mgmiMRLh=CskaOY_Ex4Q6-XfXLhkw-rQp4CezOXxBD8J=Xjg@mail.gmail.com> <A7286B92-BFB2-45C8-A811-CBF5113F91B0@gmail.com> <CAN8C-_+UftOWR0K24XdCAtJ0C5TsEvNWKC+CdCYctGfe9gbBxQ@mail.gmail.com> <B28A795E-EA91-4F2E-8F26-422C1C4E7E4E@gmail.com>
In-Reply-To: <B28A795E-EA91-4F2E-8F26-422C1C4E7E4E@gmail.com>
From: Orie Steele <orie@transmute.industries>
Date: Fri, 05 Jan 2024 16:52:25 -0600
Message-ID: <CAN8C-_Js=7touqKt0b=xeC4H8Yr2F9N_Qfu-=vi72VjFesmQ=g@mail.gmail.com>
To: Neil Madden <neil.e.madden@gmail.com>
Cc: Karen ODonoghue <kodonog@pobox.com>, jose@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005b3838060e3ab4bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/Ts4haMYTCBBmRD1GFXd0Kp1pJN4>
Subject: Re: [jose] Call for Adoption: draft-jones-jose-fully-specified-algorithms
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jan 2024 22:52:42 -0000
Inline with snips (which I don't often use, so apologies if I get one wrong), and thank you again for these excellent comments: [snip] Right, and the point of associating the "alg" with the key is to ensure > that it is only used for one thing. > That's right, but if you need to know the key type and the alg to verify, you have a "not fully specified alg". https://datatracker.ietf.org/doc/html/rfc9053#section-2.1 https://datatracker.ietf.org/doc/html/rfc7518#section-3.1 ES256 is P-256 ECDSA with SHA-256 in JOSE. ES256 is any curve ECDSA with SHA-256 in COSE. ES256 in COSE can easily lead to cross curve scenarios, where the hash function is correct (the same), but the curve is different... You need to negotiate the triple: [kty, crv, alg] in COSE and the singleton "alg" in JOSE. [snip] I'm not familiar with this issue or what "lower S" refers to here. Do you > mean some implementations spell the algorithm "Es256K" with a lowercase s? > https://github.com/Legrandin/pycryptodome/issues/759 https://bitcoin.stackexchange.com/questions/85946/low-s-value-in-bitcoin-signature (you replied before I hit send, but for others who might be curious, I'll leave the reference)... I agree it's a "bug" except those are called expected behavior when they happen frequently enough... it was an analogy at any rate. > I agree with your comment, but I don't see anything better to do than > enable more precision, so that implementations that are aware of it, or > that come after it's available, can take advantage of it. > > > Given that an EC/OKP JWK already specifies the curve, this is a case where > this draft doesn't make things more precise and just causes compatibility > issues for no gain. > > Your argument is that fully specified algorithms in JOSE & COSE are redundant to the key type requirements (kty, crv, alg = fully specified)? This is true, that's the nature of fully specifying things, you can rely on 1 value to uniquely identify a security relevant capability. [snip] What I mean is that this draft is motivated by saying that algorithms like > "EdDSA" don't give enough information to be useful in negotiating an > algorithm because one party might only support the curve Ed25519 while > another supports only Ed448. Well, exactly the same thing happens with > content encryption algorithms. Both parties might support "RSA-OAEP" key > algorithm, but one supports only "A128GCM" and the other only supports > "A128CBC-HS256". Following the logic of this draft, the issue is that > "RSA-OAEP" is not fully specified, > Indeed, I agree. > so we should really add the following additional algorithm identifiers: > > RSA-OAEP-A128GCM > RSA-OAEP-A192GCM > RSA-OAEP-A256GCM > RSA-OAEP-A128CBC-HS256 > RSA-OAEP-A192CBC-HS384 > RSA-OAEP-A256CBC-HS512 > > Not to mention doing the same for RSA-OAEP-256 and RSA1_5 and ECDH-ES and > ECDH-ES+A128KW and ... > > This is what I mean when I say that "fully specifying" the algorithm > results in a combinatorial explosion of cipher-suite like identifiers. > Except it's 2024, and as you said, systems already understand these algorithms : ) We don't have to backport full specification for things that we think people should not use, won't use in the future or that are not being used. Creating a limited number of new code points does not break old code points. > It doesn't seem like a sensible way to do things, which is why TLS 1.3 > doesn't do that any more. And this is also why OIDC, which is cited in the > draft as a motivating example, has both metadata fields: > id_token_encryption_alg_values_supported > id_token_encryption_enc_values_supported > Indeed. > Probably OIDC should add similar id_token_signing_crv_values_supported and > so on metadata fields to address this properly, rather than trying to cram > everything into a single algorithm identifier. > The intention is to give a "name" to a "reasonably safe thing that is supported". If changing the curve does not affect the security properties, then it seems reasonable to omit it... is that true? https://datatracker.ietf.org/doc/html/rfc8446#section-9.1 > A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. ecdsa_secp256r1_sha256 = ES256 in JOSE but != ES256 in COSE. (addressed in this draft) ... later: > The following values are marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and *ed25519*. Here "ed25519" is defined as... https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.3.1.3 /* EdDSA algorithms */ ed25519(0x0807), If TLS mirrored COSE and JOSE, the algorithm would be called "EdDSA" and the curve would be unknown. (addressed in this draft) TLS 1.3 algorithm name is better... "0x0807" refers to EdDSA with Ed25519. Recent algorithms registered for use in COSE follow the same approach: kty: HSS-LMS, alg: HSS-LMS kty: WalnutDSA, alg: WalnutDSA Naming the algorithm after the key (and all parameters necessary to use it) is fine. Naming the algorithm after the process that you used the key with is not. Because that process breaks when: a) multiple keys support the same process, and b) we don't know which key is supposed to be used. You argued that b is a negotiation problem, and I agree... but that problem is compounded by a few poor names, adding a few more precise ones eliminates it, and establishes a safer convention moving forward. [snip] My point is that "fully specified" is a vague term that depends on what you > consider important and is likely to evolve over time. > > Fully specified is not a vague term, it means that when I tell you EdDSAEd25519 or "0x0807", you know its EdDSA (which uses SHA-512 internally) with Ed25519 and that it won't work with an Ed448 key... Today, if I tell you EdDSA, you don't know if it's from an Ed25519 or Ed448 key. > [snip the rest] > > In short, I don't think this draft improves anything and it makes some > things worse so should be rejected on that basis. > There are at least 3 parts of your arguments (thank you again), that I don't feel can be dismissed: 1. What cost for more precision is worth bearing in implementations and registry maintenance... If the current draft is "too costly" it should be rejected. 2. What should "fully specified" mean, for a series of processes, such as hash algorithm, then sign algorithm or key establishment, and then symmetric encryption. 3. Is the guidance we give on how to create new registries likely to cause problems in the future, including repeating very long debates, regarding how things were done, vs how they should be done. ECDSA with P-521 can be used with lots of different hash first approaches.... Are all those worth registering?... No! ECDSA P-521 with SHA-1 makes no sense... arguing that it MUST be registered and that it would not be used is a straw man fallacy. Fully specifying things does not imply registering things that don't make sense to fully specify or to use in 2024. Maintaining the registries is not about "what is possible". It is about "what is good for interoperability", "what lowers implementation burden", and "what improves security", and most importantly in this draft, providing guidance for new entries, that eliminates optionality, ambiguity and hopefully makes future discussions on this topic shorter and more satisfactory. In your earlier reply you said "I’m fairly receptive to it in general, but I think it might be closing the stable door after the horse has already bolted." It seems like part of standards is watching a different horse escape over and over again, until consensus is documented to not leave doors open : ) > -- Neil > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
- [jose] Call for Adoption: draft-jones-jose-fully-… Karen ODonoghue
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Michael Jones
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Filip Skokan
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Michael Prorock
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Giuseppe De Marco
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Ilari Liusvaara
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Neil Madden
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Ilari Liusvaara
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Neil Madden
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Neil Madden
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Neil Madden
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Carsten Bormann
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Neil Madden
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Manu Sporny
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Manu Sporny
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Carsten Bormann
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Simo Sorce
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Jeremie Miller
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Axel.Nennker
- Re: [jose] [COSE] Call for Adoption: draft-jones-… Ilari Liusvaara
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Michael Prorock
- Re: [jose] [COSE] Call for Adoption: draft-jones-… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Roland Hedberg
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Ilari Liusvaara
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Orie Steele
- Re: [jose] [COSE] Call for Adoption: draft-jones-… Ilari Liusvaara
- Re: [jose] [COSE] Call for Adoption: draft-jones-… Orie Steele
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Leif Johansson
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Joseph Heenan
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Ilari Liusvaara
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Simo Sorce
- Re: [jose] Call for Adoption: draft-jones-jose-fu… David Waite
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Pieter Kasselman
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Karen ODonoghue
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Oliver Terbu
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Tobias Looker
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Vladimir Dzhuvinov
- Re: [jose] Call for Adoption: draft-jones-jose-fu… Karen ODonoghue