[jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)

Brian Campbell <bcampbell@pingidentity.com> Mon, 09 September 2024 21:38 UTC

Return-Path: <bcampbell@pingidentity.com>
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 03D27C1840FB for <jose@ietfa.amsl.com>; Mon, 9 Sep 2024 14:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=pingidentity.com
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 6ljJehv-n0UI for <jose@ietfa.amsl.com>; Mon, 9 Sep 2024 14:38:15 -0700 (PDT)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E7CC1516EA for <jose@ietf.org>; Mon, 9 Sep 2024 14:38:15 -0700 (PDT)
Received: by mail-vk1-xa36.google.com with SMTP id 71dfb90a1353d-501204753c4so2363739e0c.0 for <jose@ietf.org>; Mon, 09 Sep 2024 14:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; t=1725917894; x=1726522694; 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=j9vsLFQo4t6q0YsjdJ9ZqMGHBlqPlmlKsfXspxx60C0=; b=EsL+sHaDOOoDtYqHYKSCxh3BElwjvaRX1EHyZ1niEgkuoY/BGVoyR32SE0nh3CS1tD dURRBC6NUD7zpwpRcYgKcSVSAcMAQBwj8EUJCi7rLIE34qMjohJQm0uIizuTACAmLd3w 0DGH7U85onvjQkcuiPjXE7aFp7LFeNmfHhCqVthWHCpk18jiIKHo0bGorbUYkyhFfIeR IyTjpXJyizFDB9Ty+LyBlE6MuK8OXimCazPY+M/gC3fY+gffCgNG0G75Hti2D7x75Vq4 XN2oqZ9aAoRWoTgcGUxITuDFlZ+KVm6ZnxGL9wL1wy/dFODb0aq9kmwkEnU6++V//15w Mx7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725917894; x=1726522694; 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=j9vsLFQo4t6q0YsjdJ9ZqMGHBlqPlmlKsfXspxx60C0=; b=pjwfVEdyVmvUBmzCrMETedEhmXaCEFH6SyPj3sXB8XdjtWX9tdR9nLtQ9r4ui+vsFq kCPmQuycISd8YQhffqMBzBuyTltBtUmvBGRHPTlE00lVY7s92U84MK4q8iAJxent9i6p ZkAz9Pj1potdtQspoAeTNaLiVUqHh0tAeyxG/sGApsM64kyZnC6Y64APlABNblwXXLOB tFocVcl90iKR8E3i6UZ+yniciFOP2aeO5Kvbz2ucJ8QTl+SLLYhTpmrWfI42Z+gNBPzE 9Ohg5PkhA8+gSv5hR8yCpcduFPmSQL8hLOBj+US8zViXsXK6IR2r34FuRVKG5yrkOC9o sZSQ==
X-Forwarded-Encrypted: i=1; AJvYcCWVa6Y73Rx7xRlH3wsxA6CANb4QZWABK1OBhLPdaWTDAD4cTaUl0FUJZsjxGfJnNMn1qah0@ietf.org
X-Gm-Message-State: AOJu0Yw2aCdei4151TCSuTS7RqDvHhEYNlRPb+fMcQeUrzYEvNb7d8+g Jo4KfCLGUTjpEmUjQ+bKhcV5owd6UeGhXj28lWNG2O5fS61e3PfnF2HpPkmFfpOXRd0iG9EtICK avMHYyg43FlXIhb3vu8zrPQd8SmHQ96kWKQY0lzdPhuiaTnymT5MFov4otPrlR8Ia3F/9kaCCmi KEFseAzDao
X-Google-Smtp-Source: AGHT+IG4MRI8bo3hNpOExmi/BOuavN7GDR8ZUVVH3+MYCiHYWZiuSE+v0PYE6QEk+Df/D2aVsZe/wnoPtqHL2jOfmEY=
X-Received: by 2002:a05:6122:da4:b0:4f5:197a:d679 with SMTP id 71dfb90a1353d-502f72e1a49mr1188853e0c.1.1725917894249; Mon, 09 Sep 2024 14:38:14 -0700 (PDT)
MIME-Version: 1.0
References: <CA+mgmiOEbk9qjDwNTu198QVWAGqcuKNSPd2F-YtngcLZwjunZw@mail.gmail.com> <83704458-AC56-4CD1-9E7F-2875671FC2D8@gmail.com>
In-Reply-To: <83704458-AC56-4CD1-9E7F-2875671FC2D8@gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 09 Sep 2024 15:37:47 -0600
Message-ID: <CA+k3eCTUP6DVoKvyVQQF8Ozp+ZA93aj-Ey-o9DAe2dQ8dwsZyQ@mail.gmail.com>
To: Neil Madden <neil.e.madden@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ffa63c0621b69230"
Message-ID-Hash: 74SGKCKPQEVTN34KPQS7J62CSZTB6FYX
X-Message-ID-Hash: 74SGKCKPQEVTN34KPQS7J62CSZTB6FYX
X-MailFrom: bcampbell@pingidentity.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Karen ODonoghue <kodonog@pobox.com>, JOSE WG <jose@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/LnYZvfQdF2vcvazYcWvTraZgc6w>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

Much of Neil's feedback resonates with me.

Please consider my last call part 2 feedback to be a preemptive
meta-comment that his positions are not entirely "in the rough" or outside
rough consensus.

On Wed, Sep 4, 2024 at 3:59 AM Neil Madden <neil.e.madden@gmail.com> wrote:

> It might be helpful if the authors could describe *how* they have
> addressed the feedback received?
>
> From my point of view, there are still many problems with this document.
> AFAICT, almost none of the points I’ve raised previously have been
> addressed. Although the document no longer deprecates encryption
> algorithms, it still contains problematic statements about them, and
> clauses like this one in section 3.1:
>
> "Each of these multiple algorithms must be independently fully specified.
> The operations performed by each of them MUST NOT vary when used alongside
> other algorithms. So for instance, for JOSE, alg values and enc values
> MUST each be fully specified, and their behaviors MUST NOT depend upon one
> another."
> These requirements would make ECDH-ES with direct key agreement unusable,
> because it includes the “enc” value in the KDF context info, so very
> directly depends on the specific content encryption algorithm. (And this
> kind of context inclusion absolutely *should* be done for security). IMO
> most of section 3 is wrong or misleading and should be removed entirely.
>
> Section 5 should say how implementations that want to support old and new
> algorithms for a transition period should handle this: publish the same key
> twice with different “alg” values, remove the “alg” field entirely (not a
> good idea), etc.
>
> Section 6.1 on RSA states:
>
> "This is not a problem in practice, because RSA libraries accommodate
> keys of different sizes without having to use different code. Therefore,
> for example, there are not known cases in the wild where it would be useful
> to have different algorithm identifiers for RSASSA-PKCS1-v1_5 with SHA-256
> and 2048-bit keys versus 4096-bit keys or 8192-bit keys. Therefore, the RSA
> signature algorithms are not replaced by this specification.”
>
> But, as I’ve pointed out multiple times now, this is not the case. Many
> FIPS-compliant HSMs limit RSA key sizes, e.g.:
>
>
> https://thalesdocs.com/gphsm/ptk/5.9/docs/Content/PTK-C_Admin/Sec_Policies_User_Roles/Typ_Sec_Policies/FIPS.htm
> "*RSA*: must be 2048, 3072, or 4096 bits”
>
> I’m not pointing this out because I think we need to specify RSA key sizes
> in algorithm identifiers, but to again point out that the definition
> of “fully-specified” that this draft proposed is arbitrary and
> inconsistent. As I’ve said many times before, I would have far less concern
> about a document that simply registers Ed25519/Ed448 and marks EdDSA as
> discouraged.
>
> The first paragraph of the security considerations section 7 is outright
> wrong and should be removed. There is no additional attack surface before
> these changes. If anything, this spec introduces more attack surface!
>
> Appendix A is entirely opinion and should be removed - there is no
> consensus about which combinations of ECDH-ES algorithms should be
> considered and this document shouldn’t make any statement about it.
>
> — Neil
>
> On 21 Aug 2024, at 15:10, Karen ODonoghue <kodonog@pobox.com> wrote:
>
> JOSE working group members,
>
> This email initiates a second working group last call for the Fully
> Specified Algorithms document:
>
> https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/
>
> The authors have updated the draft based on WGLC comments and
> discussions at IETF 120, and the chairs have polled the working group
> about the readiness for WGLC. Seeing no opposition, we've decided to
> proceed with a second WGLC.
>
> Please review the document in detail and reply to this message
> (keeping the subject line intact) with your opinion on the readiness
> of this document for publication and any additional comments that you
> have.
>
> This will be a three week WGLC. Please submit your responses by 13
> September 2024.
>
> Thank you,
> Karen (for the JOSE WG chairs)
>
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org
>
>
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._