Re: [jose] RFC 8037 "alg" quirkiness

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 17 September 2020 05:02 UTC

Return-Path: <anders.rundgren.net@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 775763A0B01 for <jose@ietfa.amsl.com>; Wed, 16 Sep 2020 22:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkqeiddcJZsJ for <jose@ietfa.amsl.com>; Wed, 16 Sep 2020 22:02:43 -0700 (PDT)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887263A07BD for <jose@ietf.org>; Wed, 16 Sep 2020 22:02:43 -0700 (PDT)
Received: by mail-ej1-x62b.google.com with SMTP id z23so1287439ejr.13 for <jose@ietf.org>; Wed, 16 Sep 2020 22:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=eymnmoIiqZFwi2SztYDeCcDBgBlYYBkER5rFuNmshQU=; b=ESknhzMunu1Kua/joh72ymzX/cMGlHmHNMSMINGUrl0DSST3gwvvxdqEjcAdb9GXaJ G8wOHsbhmvFBfE/j5ejm2lxCLue7d2tIWexoa1Ih+1MtypbQhjVsNonUm8lmt/AbZqQ/ Ycz/qxpgqUdtFjDMLU1gjlSrulLpaJqi2JzTeJRGfvTGpBSz6HS4ZRWiEFXddvX9MnPh AQY0tX69KV3ScMySPL2RzWh0LUxDxGV96SM8SFdPfhq/eh0M/05ffzqQS/NeacPCxpkI NQo1fnz6JKwU1jkk31A2Q1ZgVFlTpPR8l8loN4WBaPTT86YPMWxXV9UNZSyt1Q9LKaCx AFpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eymnmoIiqZFwi2SztYDeCcDBgBlYYBkER5rFuNmshQU=; b=HhCJPvtsZCtUrGejFAdwNyFprCuLvC4PKroX1bQOdBwNUMdg1lxkH7C7ERmJEUWe91 jQd/8Oybo0Z+oePCrojWnrGiHX8Zp1YvybymT3bmpjPr0O2hpXiBRwZDAuWebaoSp5z1 YBRdr7+0pMDQWq27Nq0YZFB+w1dFPiKpNv0vQLyANzVMsWr/xwq911WaqNf7kfqjsrcu pRoA6W0wl8/bBJMaYVOevg4tYFjQHAVtLmxbXGhi5IUzGAlTHauhz71TtiyY3Vapus26 GojztsuN0huE7uaQ4m9zRPVCPlgIZbkizo0kEvsFdLUqt1ohJZwn64jdXnXNuDPYqRXg 4S5g==
X-Gm-Message-State: AOAM530Yuit+ntdNchcHOt9w9MrKORw+Wi6CMD2cSxlaHpkQ8pTBenou GqSUpmChN2L5vK8SwDyZWBrKBkRurQdbbA==
X-Google-Smtp-Source: ABdhPJwdMMAz/9LePK60Tfxnp9JYiNqGQBZS36iDMpsudzPXgeIf82dJd1o9OxHb6UoLg3Y7n3QaGQ==
X-Received: by 2002:a17:906:3e90:: with SMTP id a16mr27308718ejj.363.1600318961110; Wed, 16 Sep 2020 22:02:41 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id d13sm15499404edu.54.2020.09.16.22.02.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Sep 2020 22:02:39 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, "jose@ietf.org" <jose@ietf.org>
References: <1a84f81d-c7bd-9961-9f5c-e6c358fc1095@gmail.com> <3B2FF2C4-44EB-4462-868E-C6DD1DD3F1CA@forgerock.com> <20200916123043.GB1653297@LK-Perkele-VII> <f8b75958-0461-a824-1de4-d50332e49f8c@gmail.com>
Message-ID: <9403cfeb-40aa-8e85-3193-b403ff685168@gmail.com>
Date: Thu, 17 Sep 2020 07:02:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <f8b75958-0461-a824-1de4-d50332e49f8c@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/vqDDokpSJ3lC4OrQABpnylF-lnM>
Subject: Re: [jose] RFC 8037 "alg" quirkiness
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2020 05:02:46 -0000

Apparently the PKIX folks came to a different conclusion:

https://tools.ietf.org/html/rfc8410#section-3

"The same algorithm identifiers are used for identifying a public key,
  a private key, and a signature (for the two EdDSA related OIDs)."

Anders

On 2020-09-16 15:01, Anders Rundgren wrote:
> On 2020-09-16 14:30, Ilari Liusvaara wrote:
>> On Sun, Aug 30, 2020 at 08:10:17AM +0100, Neil Madden wrote:
>>>> On 30 Aug 2020, at 07:58, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> Hi Ilari, thanx for the explanation.
> 
> I guessed that the motive for changing the 00 spec was because no
> other algorithm was considered useful.
> 
> Personally, I rather noted the "deviation" in how things were
> expressed compared to the EC algorithms.
> 
> It is a bit in the same vein as JWS's Base64Url-encoding all binary
> elements except for "x5c".
> 
> I'm apparently "allergic" to asymmetry :-)
> 
>>>>
>>>> I have just implemented support for Edwards curves in my JSON
>>>> library.
>>    
>> You mean JOSE or JWS? Because JSON is a data model and encoding of
>> it. :-)
> 
> My JSON tools/library does indeed have integrated support for signatures
> and encryption, although based on RFC 8785 rather than forcing the
> entire caboodle to be in Base64Url or relying on HTTP headers holding
> detached JWS signatures (which does not permit simple serialization,
> embedding, or counter-signing) used by several Open Banking schemes.
> 
> Anders
> 
> 
>>
>>>> Although it is certainly not a deal-breaker I find the use of
>>>> "EdDSA" as a generic Edwards algorithm identifier rather quirky
>>>> since it departs from the other JWS algorithms:
>>>> https://tools.ietf.org/html/rfc8037#appendix-A.4
>>>>
>>>> For curiosity reasons I took a peek at the initial draft which has
>>>> (in my opinion...) a more logical solution:
>>>> https://tools.ietf.org/html/draft-liusvaara-jose-cfrg-curves-00#appendix-A.4
>>
>> On weird changes, I find the member name changes a bit weird. For
>> example it calls something that is not a curve a curve.
>>
>>>> May I ask why this change was performed?
>>
>> After prehashing was eliminated, there was only one algorithm that made
>> sense with either, so those were merged.
>>
>>>> For JSF (JSON Signature Format) I will stick to the "00" scheme
>>>> which also permits use of ed25519ph and friends if needed:
>>>> https://mobilepki.org/jsf-lab/home
>>
>> Beware of implementations that use wildly wrong algorithms.
>>
>> And on interactions of Ed25519 and Ed25519ph, they originally interacted
>> in harmful ways. Ed25519ph was later changed (in very hacky way) in
>> order to fix this (the same mechanism as used to contextualize Ed25519,
>> which turned out later to be horrible idea due to API issues it causes).
>>
>> And Ed25519ph is weaker than Ed25519. In order to prehash without
>> weakening the algorithm, one needs to salt the prehash, which Ed25519ph
>> does not do. And lack of salting has been exploited in real world.
>>
>>> 8037 was done by CFRG, so probably best to ask there.
>>
>> 8037 was done by JOSE. The CFRG part (generic specification of
>> EdDSA2) was 8032.
>>
>>> I like this aspect of the spec. IMO “alg” as a header was a mistake.
>>> By using a generic algorithm header, it forces implementors to
>>> associate the specific details in metadata stored with the key, which
>>> is much safer.
>>
>> Actually a few months ago I came up with idea of having a way to express
>> "algorithm determined by the key" in JOSE/COSE.
>>
>> - There have been some serious security issues in JWS implementations
>>     that have been caused by using completely wrong algorithms.
>> - In general, using the same key with multiple algorithms is not
>>     cryptographically safe. There can be algorithm pairs which interact
>>     badly (for instance, Ed25519 and the original Ed25519ph).
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>