Return-Path: 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 8927EC14F602 for ; Wed, 4 Sep 2024 02:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=gmail.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 9l3GrEqAmSVb for ; Wed, 4 Sep 2024 02:59:03 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 603A8C14F600 for ; Wed, 4 Sep 2024 02:59:03 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5becd359800so6587247a12.0 for ; Wed, 04 Sep 2024 02:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725443942; x=1726048742; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=KNoVyOY4OV3vuNEP8x1Glj1wJu2bgvsKYGt50fUpnWU=; b=IB0jCXZd+VBFqHXM6xj+uxWMNz0N5PEjoB3aBWwGK8bLRRLDHvsPGLIIzMNEab0OsR TJbzyaze/t1JCrSPKD63nLIwZc//2PAHwCEtv+M6NZLFXn5RDWAvtgsLa5HEwWtOvTSV Wuye3pPK0HHUSA8pqRIEK721sBFBiqFW/Mxntn+ODkW7Batmiw1MKjGCxZzUW2iWs6Xu fM+CIoHtqaxU5g8jeLfT2jzAamXjQ1yYgLX7WHb7yK2EnEiKju49mOawDPzWT1Qk1jGo GfxXTiJjA9gffsfSzdRBWsxlxVN0Pq/qALJ8jflyR3+5HbMMYwh3Xpo6I/yfOCxRu9oY uwFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725443942; x=1726048742; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KNoVyOY4OV3vuNEP8x1Glj1wJu2bgvsKYGt50fUpnWU=; b=ucmGpgkqqfSezfSUeE/BScscrbwyX3G6LGWXQ4i0wn+dD3A2Qaeif5YcaaaqLxfjn7 Q14bJ40REeDCieQrT3BKnmxrUvskm4VUWPrtUd10yFN/wP77La6DprEtIE4C9hb+XM1m SNPJlOu/Zp+sHRFnix9fv8Zl6lUPal8be3UucZbWGaLgiK0lqMhFUJO/UPbYOEI+Fzkw aBFMy94o57t3DyzLpFjTbqrh47gZKMWNZxrueHcx8RQDhbQGsWpfyTJFf6j2A+3Rq9uJ XTVHpR03SBEfZVhiaJbplN+KZTCRCFrEgGipMkai2uOel687PNqJFwGc0BH7wQfFTKZl LvNw== X-Gm-Message-State: AOJu0YymX+DyowvEcKl/gii2Yfq1Q7D8r/fcqjfd0EAczwxCkoIGu1R8 TIXVsHZ3wAU66I/CHamPn/ZPHdEIkJpQ2XvXxw4G6kEERw0asfelV/qRJQ== X-Google-Smtp-Source: AGHT+IH3VDJTFcpfkQeBOu45bhstzGgvua29HerGO1C0kTEem5yG1FXugWgbrt+wZOX8XOIKD/IYdg== X-Received: by 2002:a17:907:720f:b0:a7a:9144:e24c with SMTP id a640c23a62f3a-a89a3500b22mr1188853866b.9.1725443940880; Wed, 04 Sep 2024 02:59:00 -0700 (PDT) Received: from smtpclient.apple ([185.147.91.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a89891d86b5sm796406466b.178.2024.09.04.02.58.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Sep 2024 02:58:59 -0700 (PDT) From: Neil Madden Message-Id: <83704458-AC56-4CD1-9E7F-2875671FC2D8@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FDDFF430-9789-4D66-9E76-11EDA2A6F54F" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Date: Wed, 4 Sep 2024 10:58:57 +0100 In-Reply-To: To: Karen ODonoghue References: X-Mailer: Apple Mail (2.3696.120.41.1.10) Message-ID-Hash: YJJEAPAXFFSVSHNWKPQ6FKJAD4KBXXKG X-Message-ID-Hash: YJJEAPAXFFSVSHNWKPQ6FKJAD4KBXXKG X-MailFrom: neil.e.madden@gmail.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: JOSE WG X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bjose=5D_Re=3A_2nd_WGLC_for_draft-ietf-jose-fully-specified-algo?= =?utf-8?q?rithms_=28Fully_Specified_Algorithms=29?= List-Id: Javascript Object Signing and Encryption Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_FDDFF430-9789-4D66-9E76-11EDA2A6F54F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It might be helpful if the authors could describe how they have = addressed the feedback received? =46rom my point of view, there are still many problems with this = document. AFAICT, almost none of the points I=E2=80=99ve 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 =E2=80=9Cenc=E2=80=9D 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.=20 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 =E2=80=9Calg=E2=80=9D values, remove the = =E2=80=9Calg=E2=80=9D 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.=E2=80=9D But, as I=E2=80=99ve pointed out multiple times now, this is not the = case. Many FIPS-compliant HSMs limit RSA key sizes, e.g.:=20 = 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=E2=80=9D I=E2=80=99m 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 =E2=80=9Cfully-specified=E2=80=9D that this draft proposed = is arbitrary and inconsistent. As I=E2=80=99ve 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=E2=80=99t make any statement about = it. =E2=80=94 Neil > On 21 Aug 2024, at 15:10, Karen ODonoghue wrote: >=20 > JOSE working group members, >=20 > 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-algorithm= s/ >=20 > 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. >=20 > 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. >=20 > This will be a three week WGLC. Please submit your responses by 13 > September 2024. >=20 > Thank you, > Karen (for the JOSE WG chairs) >=20 > _______________________________________________ > jose mailing list -- jose@ietf.org > To unsubscribe send an email to jose-leave@ietf.org --Apple-Mail=_FDDFF430-9789-4D66-9E76-11EDA2A6F54F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = might be helpful if the authors could describe how = they have addressed the feedback received?

=46rom my point of view, there are = still many problems with this document. AFAICT, almost none of the = points I=E2=80=99ve 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 =E2=80=9Cenc=E2= =80=9D 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 =E2=80=9Calg=E2=80=9D values, remove the =E2=80=9Calg=E2=80=9D = 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.=E2=80=9D

But, as I=E2=80=99ve 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/S= ec_Policies_User_Roles/Typ_Sec_Policies/FIPS.htm
"RSA: must be 2048, = 3072, or 4096 bits=E2=80=9D

I=E2=80=99m = 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 =E2=80=9Cfully-specified=E2=80=9D that this draft proposed is = arbitrary and inconsistent. As I=E2=80=99ve 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=E2=80=99t make any statement about = it.

=E2=80=94 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-specifie= d-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

= --Apple-Mail=_FDDFF430-9789-4D66-9E76-11EDA2A6F54F--