[jose] Re: [COSE] Re: My review of draft-ietf-jose-fully-specified-algorithms

hannes.tschofenig@gmx.net Mon, 16 September 2024 09:53 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 BBB28C17C8A2; Mon, 16 Sep 2024 02:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Level:
X-Spam-Status: No, score=-7.103 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=gmx.net
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 lnXLgrtw_nYn; Mon, 16 Sep 2024 02:53:48 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0CFC14F71F; Mon, 16 Sep 2024 02:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1726480426; x=1727085226; i=hannes.tschofenig@gmx.net; bh=V1XN0dy6+6cF5p/r7JSstcqKIBTsIhAusCet0CHWqk0=; h=X-UI-Sender-Class:From:To:Cc:References:In-Reply-To:Subject:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=A44bNSE1FHFeTBRnyvrjapD3/gjK31ZLDZ8M5bWZ5m8b0Y3RWrqfuaMEh/2u+guK yCe8moB7fJP7t9Ab1xI2Vz2kEUTyi4EyXh+AqVRpbAKn8nteqbz02q9oNSaJgfLlJ gFwXC7PBo17EJiA9XJ+fQjnvTZeeU+ZhJRF4vhCb8muvPLaCuWIZR5TCETJEUZJHo 0t4MRH5G4McjJU3U/ZPmxH18LYUZapTqP943fqOqT5UIG6Mj5tH9CrTx8ovfvjPsx LPM6WdORJOh4O8MWoLu52oBGKJi7osSJydl6VS5V2XoBWerSKplW3oEKrxIx4HNEQ aLqjFEgFsT8z3aPeVA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from Surface ([185.176.157.173]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M9Wyy-1svek20Kyy-00FsSX; Mon, 16 Sep 2024 11:53:46 +0200
From: hannes.tschofenig@gmx.net
To: 'John Mattsson' <john.mattsson=40ericsson.com@dmarc.ietf.org>, hannes.tschofenig=40gmx.net@dmarc.ietf.org, cose@ietf.org
References: <008001db074b$57585530$0608ff90$@gmx.net> <GVXPR07MB96785F126A91D0AEA777F36689672@GVXPR07MB9678.eurprd07.prod.outlook.com>
In-Reply-To: <GVXPR07MB96785F126A91D0AEA777F36689672@GVXPR07MB9678.eurprd07.prod.outlook.com>
Date: Mon, 16 Sep 2024 11:53:45 +0200
Message-ID: <004601db081e$527238a0$f756a9e0$@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01DB082F.15FD79A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQK4I3wx6PfIr030tbuF7ew+CXiD2gFlIwA6sJTLZhA=
Content-Language: de-at
X-Provags-ID: V03:K1:TBPH6igUFZVHvUSG0WG4brUlATLqEvqGe2maWypSHcq9yLhEGU1 e7K4J2LD6OOjnqWIbHsO0+4Iv1Y3fRk3skGGkEmirTPBRaapvUs7UlFoJ6cYiwOQNqIAOd5 ylqCIvo51Pt5mKTDTsaROqAi64+DwaAgrjVsQ3wanx5+I8XCCphdkAVQ6Z56MGU795CuvN1 XxiR6VvCScnVHI3AwZJzg==
UI-OutboundReport: notjunk:1;M01:P0:cb70idfxzOk=;E92UF986dvbNzcaXpjRfL/HJ49l 8oA28WV/SsCn5q98gw2JdM9QanPI9Cn9kEMWAU4G/m35ey05RG8pR8umLSZfkdYwjdPS+mCGT noQKSMWKV5FJjoY4FUBwzD5TZgZH0n+l9bsoGRL6iZI/b+rP+jYNkafZpp60KkW7n+aNRu0o+ QmQMzQ0gZCZGE95RSdKiIgtfBfXzpeD86wggC2EN965T7rHocO995sBajqNcnQbbZEZ71+rw2 t9dc8jNEuw6kpy82Jpg0QikU2lJoK3l+vlly6/lV70rrOV+Fc+wd+5JkIpdo9zE/WUOVF+/cu acNfavJKQpXx29tXZAcoGTowCMryyrChHBxedK7VDS5feLYCws/1XEOierKML6BBLZp8qh55t 9j+yA/hVYnJmJxkdFSI75LfjYxEJKp4sYxKLgSHztsXqXKeuONR5NzPB+0RD1XxX9upskIm6e 5i8HQ/U/rKxBSvGtA00VMNxnQDsFNA7pYGWBt2gv8eTqFMGJenq01Le0ndZaB84JOaiE+on08 xH1njImtgMOKgX8Hsw+OYJzerOKwaU/fuxG40m9//7yGDz6dxqfbIAFOp6soRf2jYz+5T4o7E x7QRzUtvE7PtDdPMqNCixpsNxFukPMC4KdG+Me9XeJoTkr/qYYUWO7HaDUVeLTAnSEjx7Gvv7 Pp8LZFC2FB7lQtX9ph+snNC+XqmH7HM/Sh8jy6PtWzuR9S8D5IzlKSkwVzwt4nXORXzwPw/3d /0/GLtW0u0156B7AXFrYFIUugxMnUJfObf+uhguxIBBVQBocCqGvIrvb7c4LqjlvwSpW0yj9I MA6c5cQZ9RHP/YP8wrDxLM8aIcfx3OuzEdA5RXEuzCyXk=
Message-ID-Hash: 6R3NOYVF74TNGZFXCSGNBSXR45CE2PXK
X-Message-ID-Hash: 6R3NOYVF74TNGZFXCSGNBSXR45CE2PXK
X-MailFrom: hannes.tschofenig@gmx.net
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@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: [COSE] Re: My review of draft-ietf-jose-fully-specified-algorithms
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/B24sxI3-si-unl4ElvYEaXe5ASk>
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>

Hi John,

 

I agree that the term “ciphersuite” is not 100 % ideal either. However, even in TLS there is the option to not include an encryption algorithm with the introduction of RFC 9150.

 

How about „fully specified“ and “a la carte” as the two categories?

 

Ciao
Hannes

 

From: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> 
Sent: Sonntag, 15. September 2024 11:30
To: hannes.tschofenig=40gmx.net@dmarc.ietf.org; cose@ietf.org
Cc: jose@ietf.org
Subject: [COSE] Re: My review of draft-ietf-jose-fully-specified-algorithms

 

HI Hannes,

 

Thanks for your review. I include JOSE WG as well.

 

I think the cipher suite versus vs. à la carte is a good description for parts of the draft but not others. I don't think the discussion of having all domain parameters in the algorithm specifiers vs having some parameters in the key maps well to cipher suites. TLS 1.2 cipher suites are less specified than IKE and COSE and the term cipher suite only makes sense if there is an encryption algorithm included.

 

Cheers,

John

 

 

 

 

Sent from Outlook for <https://aka.ms/o0ukef>  VIC 20

  _____  

From: hannes.tschofenig=40gmx.net@dmarc.ietf.org <mailto:hannes.tschofenig=40gmx.net@dmarc.ietf.org>  <hannes.tschofenig=40gmx.net@dmarc.ietf.org <mailto:hannes.tschofenig=40gmx.net@dmarc.ietf.org> >
Sent: Sunday, September 15, 2024 10:43 AM
To: cose@ietf.org <mailto:cose@ietf.org>  <cose@ietf.org <mailto:cose@ietf.org> >
Subject: [COSE] My review of draft-ietf-jose-fully-specified-algorithms 

 

Hi all,

 

as requested, I have reviewed the document. Here’s some background information first:

 

Security protocols like TLS and IKEv2 perform an initial handshake to authenticate endpoints, negotiate algorithm combinations, and establish a symmetric key for securing data traffic. After the handshake, there's no need to carry algorithm information around, as the key identifier implicitly defines the algorithm in use. However, JOSE and COSE are not multi-round-trip protocols but rather building blocks for other protocols, often used in applications involving one-shot messages (such as JWTs or CWTs). It has become common practice to include algorithm information in the headers of JOSE/COSE payloads to specify the algorithm and key exchange mechanism. Despite the risk of attackers altering algorithm identifiers to deceive recipients into using incorrect algorithms with a given key, this practice persists.

 

There are two main philosophies regarding algorithm identifiers in JOSE/COSE headers:

 

- Ciphersuite Approach: The identifier refers to a meaningful combination of algorithms, key sizes, etc. This is an example from the draft: ECDH-ES using P-384 w/ HKDF and AES Key Wrap w/ 192-bit key --- this ciphersuite represents the combination of all these individual algorithms, key sizes, key distribution mechanisms, KDFs, etc.

 

- À La Carte Approach where individual properties are expressed independently.

Here is an example: Algorithm = AES, Key Size=128, Mode of Operation: GCM

 

The document aims to revise the IANA registry for JOSE and COSE algorithms to list ciphersuites, which is necessary as other specifications have assumed that ciphersuites are being used.

 

Initially, the focus of the draft was on digital signature algorithms, but later, encryption algorithms were also included. This added complexity, as encryption algorithms support various key exchange methods. The expanded scope was discussed at the last IETF meeting. This expansion of scope is, however, unavoidable since otherwise the content of the registry is misaligned.

 

Mike and Orie argue that content encryption and key exchange algorithms must be independent of each other:

 

"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. For instance, in JOSE, alg and enc values MUST each be fully specified, and their behaviors MUST NOT depend upon one another."

 

I disagree with this perspective since these algorithms depend on each other. The key exchange algorithm must produce a key of the appropriate length for the content encryption algorithm. Additionally, binding them together is necessary to prevent attacks, as discussed in the context of COSE HPKE.

 

Interestingly enough, later in the text they acknowledge this fact on page 14:

"

  In COSE, preventing cross-mode attacks, such as those described in

   [RFC9459], can be accomplished in two ways: (1) Allow only

   authenticated content encryption algorithms. (2) Bind the the

   potentially unauthenticated content encryption algorithm to be used

   into the key protection algorithm so that different content

   encryption algorithms result in different content encryption keys.

"

 

I disagree with the text as currently written, as described in  <https://datatracker.ietf.org/doc/draft-tschofenig-cose-cek-hkdf-sha256/> https://datatracker.ietf.org/doc/draft-tschofenig-cose-cek-hkdf-sha256/. I believe I understand what the authors are trying to communicate but it does not quite get across. Their view is purely from a registry value perspective and not so much from a security point of view.

 

Section 3.2's API descriptions are incorrect. For example, most ciphers used for content encryption in COSE and JOSE are AEAD ciphers, and their API does not align with the description in Section 3.1.1.

 

I found nits in the draft. For instance, Section 3.1.1 (which discusses direct encryption) references AES-KW, stating: "Key Wrapping algorithms impose additional implicit constraints on AAD and IV." While true, AES-KW, as defined in RFC 3394, does not have public parameters that vary per invocation. Consequently, for COSE, the protected header in the recipient structure is a zero-length byte string, which does not apply to the content encryption layer. You could call this "constraints" - it would be more correct to just state what is meant by these constraints or point to the respective section in the relevant RFC(s).

 

In Section 3.2.2, it appears that the document creates new KEM-definitions and their APIs, despite several existing IETF specifications that could be referenced. For example, text could be copied from RFC 5990bis (see Section 1.2 of  <https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5990bis/> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5990bis/)

 

Finally, I have concerns about the terminology used in the draft. For instance, I am not convinced that introducing the term "polymorphic" is a good idea, as it is not used in the security field. In the IPsec/IKE discussions I have seen the terms Ciphersuite vs. À La Carte being used. 

 

With all that said, I agree with the overall concept of the draft. My review focuses on providing feedback on the content, and I am happy to collaborate with the authors or the group to refine and improve the wording of the text.

 

Ciao

Hannes