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

Neil Madden <neil.e.madden@gmail.com> Tue, 17 September 2024 08:35 UTC

Return-Path: <neil.e.madden@gmail.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 CC3A5C18DB8E; Tue, 17 Sep 2024 01:35:06 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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
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 YYitQwOUzqXp; Tue, 17 Sep 2024 01:35:05 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 9DA30C14F68C; Tue, 17 Sep 2024 01:35:05 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-42ca6ba750eso34152185e9.0; Tue, 17 Sep 2024 01:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726562104; x=1727166904; 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=R51myCze6MZgvaJWDzQrGYxBQ1YTDRN256FYAcpqKW4=; b=OQf/uPWIqEIfCy92+AaSZ/k5nqX8LM1MBI5H2ilx3/0ajGpL64drQWtp42/ZUQaFcf zqfUnq95OJDewMtMdaoJNF1gwmLa+6iaWGMPBLvOsjgrID+KF4pRv0i5kHmOTs/WC0iJ myD+1G+o9RLf0iAuQxw5tvGRFIa3htuLbjofR9YfqIuoZBhrD4gGa80zgpXA4ioc3cAa tA/CQsMXR+5qLckHnhXhK8YEw6Xd9Oa4jnaBWToak6dV/MctKyja+4vhI3nBT5+VRK5b 2wzS80s4p73uTe3rJIcEzgi4WAh2LJqkzW0UbM+c+0lU/7w4ASq2FzHhGrv/Uj9h5jt+ Gnjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726562104; x=1727166904; 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=R51myCze6MZgvaJWDzQrGYxBQ1YTDRN256FYAcpqKW4=; b=GcZO6FVAaLDVTKn5ocQNubCXHeL3lAgEM5PrRVstlduiupUEtI2lT64gwDeF+Heq7D NctXe9AB5NONXpdzXWxvcMXpQzh53fJ6NUqntSlvvCOqIsp6G1H1lkVJMaQ2k5LYgFxq G12KLENa/nKcaioNsCxJDoujX0Y0a9kbLmwQH6QNM7CJ0jrwaclK98wXk+dCNPZtp8v9 wj/uK7Ondo8rbOVcpfWPDFMXrNESZBqNq+yLvixewc2vF6EWlsIdV7+mxrZC+ArMhRWh 3GVyKGM3ECdYADDbuiJF5NnsueB5xrNOdb/HYfDl9u+3qeWvZSCFePsBu41+TvhWX5/w 5S6g==
X-Forwarded-Encrypted: i=1; AJvYcCX7yUqIYhp/QFYlGWhstqZdUIfEefFAKP1Qu2/oVcbJb/JtwMbjzJAxhR46T/gisOvEEQSIBw==@ietf.org, AJvYcCXDzHRQIvP6cKG5kxRgVrpiLrlotQUN3Ji9nObfk+jVz0Tp2J9QNh5P69aUhPz0xVFwmL/u@ietf.org
X-Gm-Message-State: AOJu0Ywnf/wTFFeXTKpAENj3Acs1NeZGCU5EyMfiAAmCbrq/sgIk5rkz 2mNjV7bn1QhrLw4lj59NjcrlnF7uMk8aszimFMWZaN+hOXZohcrZ
X-Google-Smtp-Source: AGHT+IEj8TMfx8AyxQkrmtAHZcK/f183A/qvIMaPyHsKoPIBVoeMYoF73GmP2nNuJn83Qj2P9jHwVA==
X-Received: by 2002:a05:600c:5128:b0:426:5c36:f57a with SMTP id 5b1f17b1804b1-42cdcabcf3fmr107367675e9.14.1726562103407; Tue, 17 Sep 2024 01:35:03 -0700 (PDT)
Received: from smtpclient.apple ([185.147.91.181]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42d9b055018sm129675225e9.10.2024.09.17.01.35.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2024 01:35:02 -0700 (PDT)
From: Neil Madden <neil.e.madden@gmail.com>
Message-Id: <459FD82B-D8DB-4A5D-9549-8A78296B711D@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2113FCCD-5F77-4876-A377-21EECAF33807"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Date: Tue, 17 Sep 2024 09:35:01 +0100
In-Reply-To: <004601db081e$527238a0$f756a9e0$@gmx.net>
To: hannes.tschofenig=40gmx.net@dmarc.ietf.org
References: <008001db074b$57585530$0608ff90$@gmx.net> <GVXPR07MB96785F126A91D0AEA777F36689672@GVXPR07MB9678.eurprd07.prod.outlook.com> <004601db081e$527238a0$f756a9e0$@gmx.net>
X-Mailer: Apple Mail (2.3696.120.41.1.10)
Message-ID-Hash: 4SRSBFKBTSPPGNTLS47TTTLVEVJFZCK4
X-Message-ID-Hash: 4SRSBFKBTSPPGNTLS47TTTLVEVJFZCK4
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: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, cose@ietf.org, 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/MKzOoowNqoi0kBtIEb3zSRgwwG0>
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>

Maybe “a la carte” and “prix fixe”? Recognising that there will always be new items on the menu (eg key/message commitment, canonical signatures, to name some recent additions to the security plat du jour).

— Neil

> On 16 Sep 2024, at 10:53, hannes.tschofenig=40gmx.net@dmarc.ietf.org wrote:
> 
> 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
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org