Re: [COSE] [jose] Review of draft-ietf-jose-fully-specified-algorithms-02

Orie Steele <orie@transmute.industries> Mon, 25 March 2024 17:24 UTC

Return-Path: <orie@transmute.industries>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE73CC151538 for <cose@ietfa.amsl.com>; Mon, 25 Mar 2024 10:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
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 fUP_Nis7rR7b for <cose@ietfa.amsl.com>; Mon, 25 Mar 2024 10:23:58 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061E7C14F5EB for <cose@ietf.org>; Mon, 25 Mar 2024 10:23:57 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1e0878b76f3so22571775ad.0 for <cose@ietf.org>; Mon, 25 Mar 2024 10:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1711387437; x=1711992237; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=atBC1vzuvb/kIVbBiSN6Jgnxvipadw7ybNDchYRkAH4=; b=e/w3I7ExY0TyOlY6BmjKC5a2BTMkLirss47iFY2klg2LvIw0MyiApRZw1nmUnWt0iP UOepYtD61zx/LQVfk/xJ+eqSbZOAXswCXcUPmFMHFvx7Pc/IMJs3U4/65ZnnT9CmjBjI MFgkEsAhT+z9oZa/zPyhS/HtbGvx8vxQI+MVHA79fPJFGBXy3k8Ym4p+YUzYwyWycpm+ xsM3RTMOyPRbqWY4MJRBIsuebfhJJRRrqqPXB/zwsRtqUUzQNORIBs3nRtLfoUd+OAKd Wv9yT8ExxhjwNKl6NlTELsGG9SiDKAVPaV9jjvNhQzfTgv4VlPT4GSG+FMAKWKcxq8yS xaVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711387437; x=1711992237; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=atBC1vzuvb/kIVbBiSN6Jgnxvipadw7ybNDchYRkAH4=; b=NU974rY3S3yawWRw/tMXkijCkVHldB8tmwGJYhrCCf0OR9KWWudD8r2Op3Bz30cZql hBzOy2Y8wCte0f582WDybxg9jmKhUPVoN0eWchVM7yN2dvsWcv5Ivb37OJSG+qrf84u5 czQCZuYaRn2jFaWtldP8FWsYfwzUDyeQWQrJGyfltOCjsX8tsTbxtVqCGCD5JtM/CniJ sZNKFkScMS1IB3+blxedPxC37wfT6fevMMn/Jv0Qedfo3dFJGwSkzQLXyFu4+jq9G7PO wCrv+UK5kOv1TT/R7WU2R69RSNo4HVM/iEKc66A74MdzuU5ncboi0pq55TQC0oUnTOtO f3uw==
X-Forwarded-Encrypted: i=1; AJvYcCWY4Q2wDyz+lffMAUnLHloxtRXx8UkVGBBQhqgNshEpJRWqy/upm0qLeoXun87FDwL0lpOfRGlQAxzfcYXQ
X-Gm-Message-State: AOJu0YzUN2uguYQjoEbZXcxVkec3N9YhWxnEQHyyMJzyWQ6WQhHLrguu ZDnqUP1/Gb32mbxOBu+aiNwyvfI8Bru1RrHoh94sBFkrgbuR4SmCUPvzgagF3+R1mgtRxPEMDP4 5XzB1x9BCFExW3ceYKO9QSTN4z+ollVFuA2o9UNx8FX4QbrJfza4=
X-Google-Smtp-Source: AGHT+IGho7TQrmGFq/UnzTeDRTFPlTF1mnZAqsbEl6p9xJwbcACfM5CVyS8Idbw1RBfzwZFzX9fuxYiTJt8V05/eoTk=
X-Received: by 2002:a17:903:234b:b0:1dd:69bb:7f96 with SMTP id c11-20020a170903234b00b001dd69bb7f96mr10493656plh.6.1711387437231; Mon, 25 Mar 2024 10:23:57 -0700 (PDT)
MIME-Version: 1.0
References: <GVXPR07MB9678C20AE59F6B2251E926C389332@GVXPR07MB9678.eurprd07.prod.outlook.com> <GVXPR07MB9678FF40B08D2AB769DA422B89322@GVXPR07MB9678.eurprd07.prod.outlook.com>
In-Reply-To: <GVXPR07MB9678FF40B08D2AB769DA422B89322@GVXPR07MB9678.eurprd07.prod.outlook.com>
From: Orie Steele <orie@transmute.industries>
Date: Mon, 25 Mar 2024 10:23:46 -0700
Message-ID: <CAN8C-_JZji_Q5GMpoJFt-nwbJaUrg6OqTs3ib2KVFTDDsrPKog@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Cc: "jose@ietf.org" <jose@ietf.org>, "cose@ietf.org" <cose@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000450fef06147f700b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/v09VwrdvX_Nb9aX7F4KjjX9QhsI>
Subject: Re: [COSE] [jose] Review of draft-ietf-jose-fully-specified-algorithms-02
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2024 17:24:02 -0000

I wouldn't say there is nothing wrong with those algorithms.

I would say there is disagreement on the binding between keys and
algorithms, and positions vary depending on which working group you ask.

For example:

https://mailarchive.ietf.org/arch/msg/tls/4CryTBuFG64IlMhpCEvE2tLjeeg/

Not all the changes COSE made were improvements, some of the differences
from JOSE are mistakes, and have gone against security guidance, and leaned
into the "a-la-carte" cryptographic suite approach, which I believe we have
learned to avoid in protocols.

In COSE, algorithms such as ECDH-ES + HKDF-256 and ECDH-ES + A128KW not
committing to the algorithm used with the content encryption key, have
introduced attacks, which we are still discussing how to clean up:

https://www.rfc-editor.org/rfc/rfc9459.html#section-8

As evidenced above ^ deprecation without replacement is possible... when
there is no other option.

Signatures being not fully specified seem to have less of an impact, but
guidance moving forward should be clear, especially for PQ and Hybrid
Algorithms.

Perhaps a compromise would be to only register new code points for
Ed25519EdDSA / Ed448EdDSA in JOSE and COSE and simply deprecate the other
algorithms without additional allocations?

Will be marking all the ECDSA / EdDSA / ECDH / DH stuff deprecated when a
CRQC arrives anway.

Regards,

OS




On Wed, Mar 20, 2024 at 6:17 PM John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
>
>
> It would be good with more discussion of the draft in COSE. Some people go
> to both COSE and JOSE, but many people are strictly interested in one of
> them.
>
>
>
> One more comment:
>
>
>
> I think the deprecations are problematic:
>
>   - JOSE EdDSA
>
>   - COSE ES256 (-7)
>
>   - COSE ES384 (-35)
>
>   - COSE ES512 (-36)
>
>   - COSE EdDSA (-8)
>
>
>
> - There is nothing wrong with these algorithms in systems that do not need
> to do negotiate capabilities using the algorithm identifiers. A lot of
> systems are using these algorithms without problem. They are also hardcoded
> in other RFCs and external specifications.
>
>
>
> - COSE: Deprecating ES256 (-7) and EdDSA (-8) and registering ESP256 (-9)
> and Ed25519 (-50) adds one (or more) byte for people using Ed25519 in COSE
> and uses one more of the rare 1 byte identifiers.
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> *From: *jose <jose-bounces@ietf.org> on behalf of John Mattsson
> <john.mattsson=40ericsson.com@dmarc.ietf.org>
> *Date: *Thursday, 21 March 2024 at 09:55
> *To: *jose@ietf.org <jose@ietf.org>, cose@ietf.org <cose@ietf.org>
> *Subject: *[jose] Review of draft-ietf-jose-fully-specified-algorithms-02
>
> Hi,
>
>
>
> - “6.1.  Algorithms for Signing with RSASSA-PKCS1-v1_5”
>
>
>
> Probably better to call this “6.1 RSA Algorithms” as is applies to RS*,
> PS*, and RSAES-OAEP.
>
>
>
> - “The working group has discussed whether the RS256, RS384, and RS512
> algorithms should be considered fully-specified or not”
>
>
>
> I think the groups needs to decide if registrations like this should be
> allowed in the future. This should be clear if someone want to specify
> similar algorithms.
>
>
>
> - “This is not a problem in practice, because RSA libraries accommodate
> keys of different sizes without having to use different code.”
>
>
>
> This is not always true. I know of still deployed RSA implementations that
> only support up to RSA-2048. But this was not COSE/JOSE. I would however
> not be surprised if COSE implementations on very constrained devices run
> out of memory if they are given a large RSA key.
>
>
>
> - HSS-LMS is not fully specified. Maybe that should be mentioned.
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>