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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Sun, 15 September 2024 10:18 UTC

Return-Path: <prvs=1988afb204=uri@ll.mit.edu>
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 CA95AC14CF18; Sun, 15 Sep 2024 03:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.904
X-Spam-Level:
X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TRACKER_ID=0.1, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 h1ajmtLhygWc; Sun, 15 Sep 2024 03:18:46 -0700 (PDT)
Received: from MX2.LL.MIT.EDU (mx2.ll.mit.edu [129.55.12.51]) by ietfa.amsl.com (Postfix) with ESMTP id 77EB4C14E513; Sun, 15 Sep 2024 03:18:44 -0700 (PDT)
Received: from LLEX2019-02.mitll.ad.local ([172.25.4.98]) by MX2.LL.MIT.EDU (8.18.1.2/8.18.1.2) with ESMTPS id 48FAGePg220673 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 15 Sep 2024 06:16:40 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=SbGGUSdRV54W3t7MxPwoOa77b/lbqqd+McsozPFHQVSXr88BYuqiIqvZSOsFzt1dnyNBBs7Nn1uCkquft2SBhnDK9twP453RTCOdKiKe8dlbLJQ75N/kACRqpSGZPHvnUW9lagdhq6Gjnw7p+FF3hlPZH68DTB9rTFnxbXO0VEofVAmQD3qfZ6eIIz3qxqCOdpDf3C9XxAok+7kDJjb48bbAi2KPl/1oiuLt/tA/0FHB/qy//fLlfZpD/3G7Q+xkpyROzqHlQMGdEW1piCLQ0GFQg6LhjRJPw/sch5fdpmykCd/pl6J/0d6bkWIkBZT22FJN474d0YUEDM84iyELQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=BQJu+uW4zZeFND6f7uQpVLKP2Oe938GxYsGZxKzeJ6Q=; b=OVK78EVXN81xxDLiE69GnDhC74zsbEcQfxgMin9hKXBCIRmLZWIyznVMdqt2Rct5N7oWHWJU0B90pXgfIiQr3Z+8t9Puvk2G4pEuqdXB44CghD+U/CVDjhWpt+JIyzgcE8aIO0WkRqo2htnl3h/1tIXf/rB+TKAqoZza2qWUivvkMZZ1fzLq3zzLNL89vJKv1Aw7XJ4RDvOjZH6aTw5I1oss+egA444Jy6eTLczf9By72qvNcpe4BgTLfMqomOa7EY6gPBVXgtPasn5KzeSvg1XmKrPEnZ5ue7RQiL0FN5xyQoCkawF/W0oYOfLadhWpn3Wa6R1xYs4sWgHMUvXEjQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ll.mit.edu; dmarc=pass action=none header.from=ll.mit.edu; dkim=pass header.d=ll.mit.edu; arc=none
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Thread-Topic: [EXT] [COSE] Re: My review of draft-ietf-jose-fully-specified-algorithms
Thread-Index: AQHbB1HvMEtHVxdjP0u2fPc89jLPXLJYopAA
Date: Sun, 15 Sep 2024 10:18:30 +0000
Message-ID: <C86E4BBB-2478-44E8-9D16-AC6050207496@ll.mit.edu>
References: <GVXPR07MB96785F126A91D0AEA777F36689672@GVXPR07MB9678.eurprd07.prod.outlook.com>
In-Reply-To: <GVXPR07MB96785F126A91D0AEA777F36689672@GVXPR07MB9678.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0P110MB1419:EE_|BN0P110MB1867:EE_
x-ms-office365-filtering-correlation-id: 2a69aa87-bc2d-47c4-f225-08dcd56fbf16
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|4022899009|38070700018;
x-microsoft-antispam-message-info: YqxSC4YF5wVmTit27r+jn4pqUPdF5TQNIh67wu3+QMgg4ioSMEszFPgc1IuB2LcTCgW11fZhii/qFZWGSpwxVfL+AahStaXZOmx6nRqwH20E71+nZdSlD6j9874Smnh6W5g6GXTQ4b8CxymjECsqH2tKivRmzbdHPVe3wT+icGz/A+qR7gMjkYuSAaeXCEPRL7Jfx65wchsbcPKgp4dspEzHYOtEe+dsWrEzBOrrG7C2WuzRFzc+7tXfYA6tFhjqYaa89HktO7HBCEAzYiUM68IFInkxnPP7nHscEMdVn0aK/GhrMU+nAaG9hJvaEcv/SZnIcac4aO1iLPZ3q7Vk6yo7xUd2j9vpy+INakXXtk4vfdPuxaaKkiS8zrthOoo+tcDzgeJXA7amtq2OSmn9Y3aEzwIVbuA9NoAb6Ee9HmOYPiuCtUMyHRxv0dj99y41S+QqEe2v4WdbE9lDePHJvxOITLPOGGprX3YO6fhxxqWIhsL6I3s14aoDp07ZI54+1HHSsoKrW08Ycw4YMipz+PANEeLk5EFeHYZPTcK8BePsXAv7Iheq0DWk3arEvnT/9lSGYfbZAIHxShKrvj0bFENEoQf3XXGIOv8PV/iGr/UhOKX74rudggpdhQoMBEEBGfiYTFr3Gu1spN931tVMM51Hw5AUHGLLUcVAjRLfwmGbCdZRwDKJZHgD5vluvDdEuw8mdgsuMvxJlypF7/Q0r8ie+tppFyq5uBkc0eQLvD6ipiFeclLaShIaxfmO5vp5uoJk2WEgaGTF+g9LECZUoYZfYsGUkfw9Q7W0cZY8WKRVrF0NOE2b6LR36FaMHqTzLJz0aYCt4YRl0mK6Qm5Pd3rSMZT3gb6X/i082qrMc/6VeAFnVbi1CPs3PjJnvmLP/YC1g0Pi3fTWg02slF6i639d74KSsSWX5Uck8TUUKO3NrAT8vJ6z6YXTrY7isDgBEeD6Pns8PoFD6otq+fqlS0y/74w1L8ZEDExZhwCqqsgPjvX/h2RJohRyFSyxd6gRedt8pVciyBZ92jAJ5AeKoxQHG79e4jmm2TbcF276tbqsa7WCbJ3DA813XsIknoDZkMPxbJqUr+ye3dPSby+9ULwfIey/H1/qpYb0a7jyn8jM1TMAQRgxw07h0tW02Pl3/Nvo6lOZOcIKHp/2K3Im0h+kbKBXcxVnZJZzN/8s6PuHxTKzRH7R9m3EoHphpWECdk9Rhp4JarXQXech5oQnBi9ylnpAWYHVwUk9qBPST6CoSBvhQRRsppGu7LDN5i/5DweA5QZ1v1B/k/mU/Ecj6YwNIUB7KCexgp4dbqNlKRmAgp2ESh/w0EeHSk5Kv8FpFGjeuSr15Z+hjHlOjD5Z6qCM2Mzy4HQmPAv97NJix/G6GTQ8Tpqs+cTSXoODC3TUtG39ttzKJXD0+QeasqE8Mg==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(4022899009)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: HJ4TuROiW9yI+V9/BDdaqmQWr/Rw1+oxoVB/DNyipzOiFyBGMSit/5KYYreRaJcw27plznce2LPchhWDu6vJPyYZ7UNKstVDK05cfoDxkRiPn1fxsbC950XB498Y4A8GbBfmrTgXS13Ov/7k24NYaoFZB1s0WSNQNu7MfMTt6uTxLq+0Ec1BMgfXayRRWHtu+N1mjf9yzfqjksR4WnAxqNBUbVLJwml9jdgUhcb6ycEs/vy9sK82vQwQH9jSamAWiVp1aOtkKPas/9deg1A/NFUrDn9bSIfJJvx9rBhFlGDyChdcTZeWtiiQvIQW7TZcyYHk5RQZPCjQL9pPZAWF0VIV5SsfljxVA4TndMz1M6mqzuWpcmLnHwLOo9cAIcpiALrkRTJp6FDVVd85P0/15ZiHGWSBYxBC1wLi3ov2jXFNAt050o9JzErPYChnYPv+DdMmNlA9TdWyVJfYUy3l5xklcnutAxWVjrHAZmoODgVosh94+wIZRR0NF9Do5Sd2irXkfrBAPS3+pB2uUnIm8BV17ZXKiAh52kn4na9XOf6aDgz9W3DeCmGa6QmzYXo+Bxn4S5FYkyef0ww8b9l0Hqog4gG+5AhvnfqRI5DS3ceXYklpBFPiOlySP7Iknf7X0HObYCvJ4lDOuTnoybJ23tbAb17Zccfnfr5ekJOINsNLBq5ANbO6nY88TR23TmNVK5AWwj98bk6/zomxN4geL9LWpa+hsNJ9Wt4GPGBR9msFFM5YebY5PZwf9yQfha38HqzI3Q1L5FbI0VdVrdXLq+tMlSi6kBxnERXortyC5qiPtWhecencAxkxOsTw41acojQr8VYBjoxLyTFSoW9e0cKaRDMyq+/FHjJ1h4q1LGyPi6mFpYpnPhg6plk/zWdeUH+k0v7R34+qj0gjX3NzOijRRkVa07XXtjyM2GU9i+P0xP5NMcnvCIKRQJ7Ov4g+vKJP54ESAJcq/eylAl70B+/2PKviVGG318aHl4cEOQEVzBFOkR5aFm+b9+Mrm1752jkjxxSx0UGtq7CxlZ+U6JEhuLTr8pg04+K0aHHO7N4gFNUS0IlUiBfrOWK8RazP1DYcIeqM+jYb6QrRTl5vuZ4Ctc5G8OcazuoN5mPdRuCWcONB1mZsqQYUXx7geUv3LIAN32znwgnLYrD0lGnsPtXtCS1ZEipCMJC7/BSrqVJTgITkYln3Bg3uVsVM4t6DQApGWNNaUdta+t6VVj1TkJznUvVJKIf1pGgP7ava9rjUC34j3BUFEXUUMO21mRqP0sRTu0JTnmcSclEsWTVxkpu2UbGlhDc4U08+hfNHY313IAF/d2tZ6bOXwDvKZysnZCke3Or4OxnA2sOB2srblq2atdMjnQ5VWVWrJ9oX9b4=
Content-Type: multipart/signed; boundary="Apple-Mail-A9685255-6A3B-4009-BA6B-E2563900944D"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a69aa87-bc2d-47c4-f225-08dcd56fbf16
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2024 10:18:30.3221 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 83d1efe3-698e-4819-911b-0a8fbe79d01c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB1867
X-Proofpoint-GUID: T9ThDDiRKNjprTlJyxEIgNI9yp8mm37Y
X-Proofpoint-ORIG-GUID: T9ThDDiRKNjprTlJyxEIgNI9yp8mm37Y
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-15_02,2024-09-13_02,2024-09-02_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxscore=0 mlxlogscore=999 phishscore=0 adultscore=0 spamscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2408220000 definitions=main-2409150077
Message-ID-Hash: QIGYKBVABQC373HKEUHHLAJH6ACIJTID
X-Message-ID-Hash: QIGYKBVABQC373HKEUHHLAJH6ACIJTID
X-MailFrom: prvs=1988afb204=uri@ll.mit.edu
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: "hannes.tschofenig=40gmx.net@dmarc.ietf.org" <hannes.tschofenig=40gmx.net@dmarc.ietf.org>, "cose@ietf.org" <cose@ietf.org>, "jose@ietf.org" <jose@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: [EXT] [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/cRQ3-LQDMlD5PxFmXiIIT89cBnM>
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>

FWIW, I support the Ciphersuite approach, and am against a-la-carte. 
Regards,
Uri

Secure Resilient Systems and Technologies
MIT Lincoln Laboratory

On Sep 15, 2024, at 05:30, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:


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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
 
ZjQcmQRYFpfptBannerEnd
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 https://aka.ms/o0ukef" rel="nofollow">Outlook for VIC 20

From: hannes.tschofenig=40gmx.net@dmarc.ietf.org <hannes.tschofenig=40gmx.net@dmarc.ietf.org>
Sent: Sunday, September 15, 2024 10:43 AM
To: cose@ietf.org <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/" rel="nofollow"> 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/" rel="nofollow">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

_______________________________________________
COSE mailing list -- cose@ietf.org
To unsubscribe send an email to cose-leave@ietf.org