Re: [COSE] [Technical Errata Reported] RFC8152 (6597)

Anders Rundgren <anders.rundgren.net@gmail.com> Thu, 03 June 2021 16:44 UTC

Return-Path: <anders.rundgren.net@gmail.com>
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 0595B3A0DA5 for <cose@ietfa.amsl.com>; Thu, 3 Jun 2021 09:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=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 8cIuqFa_QZkj for <cose@ietfa.amsl.com>; Thu, 3 Jun 2021 09:44:11 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 6B3AB3A0DA0 for <cose@ietf.org>; Thu, 3 Jun 2021 09:44:11 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id o127so3796966wmo.4 for <cose@ietf.org>; Thu, 03 Jun 2021 09:44:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Q/cA/fDUJTIyAJ9GSOHj11iUY85c4460b+AXChUrfLg=; b=NYR4/86blwElIGI9h63McNXJ4xXLVQ8LCFnFYKlyjRtNLKMZ6rJZqubqvONI/tBUPz 6K6OTa10KsrVnTgw1CmDymt4nUUN8gWBIhhhUy8OP9XZsoHRWN5sl4ncPtalLNHgi8D4 9JfG6o6kdgsoLQGXdlGQSyX2tQqHQ9lE1tWdotmfaQZH8mdF2zM1z8nUiMVWc3cquA02 y7O36wUi4UpJBeXSkx53yN3KgKNGkwMCw4KXZbdl8Lwt4Wk5iUUR1/imGdieStYTHqbR JYtpn93dPcGbi+zXVocScsCHoRnK2xE7h5+VgGNa9YBi4tmZPUUsWUXC7LrC8miHIIPO h8ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Q/cA/fDUJTIyAJ9GSOHj11iUY85c4460b+AXChUrfLg=; b=L/j+Ud4ZWcDaK4CfzSvZ9c2B/dNdw42CKma71nO+CMveHaz6OZ0XCapnutYI2jXYNp qrJl1mwyQ8xKEksNTor5Yrqq29u05wWQ3PysKYTek1m8afjruOrG+xyyG5dg3ojsdijx WJILI8JTsdb6ieBeav8V+mh75NMgCQwp8CeO3bQg8vRMF3FvggvHmls/0259YLO3ijzc d82Vh8TIZ13YUrL+qmbBWAZmeTPnQz0kRswSSU/MtsxuuZjj3fuMcT2mHC48UYvHVwWA SfCIteHpTYZun/xuLMIe8WgLJ2em9meFe6eKSDE8iTfWFrhfF8Tigk4UHDU/0X/etpDa Puzg==
X-Gm-Message-State: AOAM530RSK0Vj+fsrrQiSgCB5hQTrKv7P41bl//2TnLPzjsq6KeXkxHQ V2LqDti+l5jwLVZRv19f320cJm9dPdl8+g==
X-Google-Smtp-Source: ABdhPJy9wmRRUPK7nFkc5SrD6v9pxC/XthDHTTxk9spQV3ZVdnOsyLa5FcZTte5Az1liOgSNn/UIhA==
X-Received: by 2002:a05:600c:3510:: with SMTP id h16mr33063wmq.38.1622738644343; Thu, 03 Jun 2021 09:44:04 -0700 (PDT)
Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 31sm4214387wrc.96.2021.06.03.09.44.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Jun 2021 09:44:03 -0700 (PDT)
To: Ilari Liusvaara <ilariliusvaara@welho.com>, cose@ietf.org
References: <20210603121938.5BB49F406F3@rfc-editor.org> <YLkBeIfVNLPFWR8v@LK-Perkele-VII2.locald>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <f6a8ce30-528b-2da1-b400-533c7bff4159@gmail.com>
Date: Thu, 03 Jun 2021 18:44:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <YLkBeIfVNLPFWR8v@LK-Perkele-VII2.locald>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/wIS2vjsjlZz7_eFhw-iorFroVOU>
Subject: Re: [COSE] [Technical Errata Reported] RFC8152 (6597)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 03 Jun 2021 16:44:16 -0000

Thanx Ilari,

So apparently both the RFC and the associated IANA registry entries are incorrect.

Fortunately, my code did this assumption as well :-)

A remaining issue is that ECDH-ES+A256KW is a different algorithm
in JOSE.  Jim has in his own code rather used
ECDH-ES-HKDF-256+A256KW which seems reasonable.  Maybe that
is stretching things too far?

rgds,
Anders

On 2021-06-03 18:21, Ilari Liusvaara wrote:
> On Thu, Jun 03, 2021 at 05:19:38AM -0700, RFC Errata System wrote:
>> The following errata report has been submitted for RFC8152,
>> "CBOR Object Signing and Encryption (COSE)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6597
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Anders Rundgren <anders.rundgren.net@gmail.com>
>>
>> Section: 12.5.1.
>>
>> Original Text
>> -------------
>> The RFC is unclear to whether Concat KDF or HKDF is to be used:
>>
>> In table 20 there is an entry:
>> ECDH-ES +  -31   | HKDF -  | yes        | A256KW | ECDH ES w/    |
>>     | A256KW    |       | SHA-256 |            |        | Concat KDF    |
>>     |           |       |         |            |        | and AES Key   |
>>     |           |       |         |            |        | Wrap w/       |
>>     |           |       |         |            |        | 256-bit key
>>
>> That is, the table talks both about Concat and HKDF.
>>
>> The IANA registry for this algorithm says Concat KDF
>>
>> Jim's sample code for algorithm -31 says HKDF.
>>
>> Corrected Text
>> --------------
>> I have no corrected text to offer since I don't have the answer to the question raised.
>>
>> Concat is referred to once and without any external references.  In JOSE, Concat denotes a NIST standard which is quite different to HKDF.
> 
> Here is what I presume table 20 should be (modulo precise way HKDF with
> SHA-256 should be written):
> 
>     +-----------+-------+---------+------------+--------+---------------+
>     | Name      | Value | KDF     | Ephemeral- | Key    | Description   |
>     |           |       |         | Static     | Wrap   |               |
>     +-----------+-------+---------+------------+--------+---------------+
>     | ECDH-ES + | -29   | HKDF -  | yes        | A128KW | ECDH ES w/    |
>     | A128KW    |       | SHA-256 |            |        | HKDF SHA-256  |
>     |           |       |         |            |        | and AES Key   |
>     |           |       |         |            |        | Wrap w/       |
>     |           |       |         |            |        | 128-bit key   |
>     |           |       |         |            |        |               |
>     | ECDH-ES + | -30   | HKDF -  | yes        | A192KW | ECDH ES w/    |
>     | A192KW    |       | SHA-256 |            |        | HKDF SHA-256  |
>     |           |       |         |            |        | and AES Key   |
>     |           |       |         |            |        | Wrap w/       |
>     |           |       |         |            |        | 192-bit key   |
>     |           |       |         |            |        |               |
>     | ECDH-ES + | -31   | HKDF -  | yes        | A256KW | ECDH ES w/    |
>     | A256KW    |       | SHA-256 |            |        | HKDF SHA-256  |
>     |           |       |         |            |        | and AES Key   |
>     |           |       |         |            |        | Wrap w/       |
>     |           |       |         |            |        | 256-bit key   |
>     |           |       |         |            |        |               |
>     | ECDH-SS + | -32   | HKDF -  | no         | A128KW | ECDH SS w/    |
>     | A128KW    |       | SHA-256 |            |        | HKDF SHA-256  |
>     |           |       |         |            |        | and AES Key   |
>     |           |       |         |            |        | Wrap w/       |
>     |           |       |         |            |        | 128-bit key   |
>     |           |       |         |            |        |               |
>     | ECDH-SS + | -33   | HKDF -  | no         | A192KW | ECDH SS w/    |
>     | A192KW    |       | SHA-256 |            |        | HKDF SHA-256  |
>     |           |       |         |            |        | and AES Key   |
>     |           |       |         |            |        | Wrap w/       |
>     |           |       |         |            |        | 192-bit key   |
>     |           |       |         |            |        |               |
>     | ECDH-SS + | -34   | HKDF -  | no         | A256KW | ECDH SS w/    |
>     | A256KW    |       | SHA-256 |            |        | HKDF SHA-256  |
>     |           |       |         |            |        | and AES Key   |
>     |           |       |         |            |        | Wrap w/       |
>     |           |       |         |            |        | 256-bit key   |
>     +-----------+-------+---------+------------+--------+---------------+
> 
> That is, the value of KDF column is correct, and the description is
> incorrect. In section 12.5, there is definition of how key encryption is
> done, and it references functions "KDF" and "KeyWrap", which are
> presumably the values of colums "KDF" and "Key Wrap".
> 
> Furthermore, if one supposed it was intended to be concat KDF, I do not
> see anywhere what the hash function would be (for JWE, the text
> specifies that the hash function is SHA-256).
> 
> 
> And I note that draft-ietf-cose-rfc8152bis-algs-12 has table with the
> same sort of inconsistency (table 16). Presumably that table should be
> fixed before publication.
> 
> 
>> Notes
>> -----
>> It is pretty vital for interoperability knowing if Concat KDF or HKDF is to be used.
> 
> 
> -Ilari
>