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

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 15 September 2024 16:44 UTC

Return-Path: <ilariliusvaara@welho.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 33180C14F70D; Sun, 15 Sep 2024 09:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 3UVzhswElv2i; Sun, 15 Sep 2024 09:44:09 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05307C14F5F4; Sun, 15 Sep 2024 09:44:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 96A8E67F67; Sun, 15 Sep 2024 19:44:05 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 7cPu9-sKSCom; Sun, 15 Sep 2024 19:44:05 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-153-79.rev.dnainternet.fi [87.92.153.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 2FB33230A; Sun, 15 Sep 2024 19:44:03 +0300 (EEST)
Date: Sun, 15 Sep 2024 19:44:02 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: cose@ietf.org, "jose@ietf.org" <jose@ietf.org>
Message-ID: <ZucO0geTKZDGcqO7@LK-Perkele-VII2.locald>
References: <008001db074b$57585530$0608ff90$@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <008001db074b$57585530$0608ff90$@gmx.net>
Sender: ilariliusvaara@welho.com
Message-ID-Hash: SZT54IXZ2ZNUCI43K5WZCPN3B5JFJV2U
X-Message-ID-Hash: SZT54IXZ2ZNUCI43K5WZCPN3B5JFJV2U
X-MailFrom: ilariliusvaara@welho.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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: [COSE] 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/fvRdSY3qBkDQoVqtqlFTRWIhGRI>
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>

On Sun, Sep 15, 2024 at 10:43:30AM +0200, hannes.tschofenig=40gmx.net@dmarc.ietf.org wrote:
> 
> 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.

My interpretation of last meeting is that there is no consensus on
extending the scope to encryption, mainly due to the large number of
algorithms this would require.

 
> 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.

This contradicts fundamental assumptions in JWE: That "enc" and "alg"
are mutually independent, and that there is no need for binding to
prevent attacks.

COSE makes weaker assumptions: Any AE(AD) algorithm is independent from
all else, and that there is no need for binding to prevent attacks.

Unfortunately, the latter was left implicit, and then accidentally
broken.

And even if COSE does not fundamentally assume that all algorithms
are independent, it is very bad idea to have dependencies between
algorithms without a good reason (basically, either the combo makes no
sense, or is trivially insecure).

Most key managment algorithms in JOSE and COSE do not support binding
(in some cases, it would be highly nontrival to add), and assumption
"no need for binding to prevent attacks" is necessary to have such
algorithms.


> 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/.
> 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.

Yes, The text seems confused.

What is needed in case (2) is having a KDF step before symmetric
encryption to ensure that different symmetric encryption algorithms
use (cryptographically) independent keys.

In some cases, COSE already has such step depending on key managment
algorithm (e.g.,DKA and direct+KDF), but not all (e.g., any non-direct
algorihm).


> 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 think that description is strange, but not flat out incorrect, as
it does allow for additional aad input.

All JOSE content encryption algorithms are AEAD, as JWE absolutely
requires that.

COSE does allow using non-AEAD for content encryption, but all the
current algorithms suitable for content encryption are AEAD, and this
state of affairs is expected to continue. Moreover, using any non AD-
capable encryption at layer0 is of questionable use.


> 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/)

Looking at section 3.2.2:

What the heck is "Key Establishment with Direct Encryption"? Neither
JOSE nor COSE define such term, and it looks like an oxymoron
anyway.

Then some references to "JWE Protected Header" are incorrect and
should be "JOSE Header" instead.

Then the stated method of constructing a fully-specified algorithm
in JOSE does not work, as it breaks fundamental assumption in JWE
(the indepence of "enc" and "alg").

 
> 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. 

This draft is about interoperability, not security. It does define what
it means with "polymorphic", and it is not quite the same as "À La
Carte".

In fact, "fully-specified" can be less secure than "polymorphic", as
"polymorphic" might make some critical security checks into required
for function. Unfortunatly, this has proven to not be theoretical.




-Ilari