IETF Logo Mail Archive

Re: [COSE] COSE HPKE Public Key Format Consensus Call

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 26 September 2022 10:54 UTC

Return-Path: <ilariliusvaara@welho.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 60042C14F725 for <cose@ietfa.amsl.com>; Mon, 26 Sep 2022 03:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 QmZ7JPAPmdH0 for <cose@ietfa.amsl.com>; Mon, 26 Sep 2022 03:54:44 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51266C14CE31 for <cose@ietf.org>; Mon, 26 Sep 2022 03:54:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8D2A2680B9 for <cose@ietf.org>; Mon, 26 Sep 2022 13:54:38 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id wMwdM3ghlBK1 for <cose@ietf.org>; Mon, 26 Sep 2022 13:54:38 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 6454E7A for <cose@ietf.org>; Mon, 26 Sep 2022 13:54:37 +0300 (EEST)
Date: Mon, 26 Sep 2022 13:54:37 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "cose@ietf.org" <cose@ietf.org>
Message-ID: <YzGE7cbN6HXb9TsK@LK-Perkele-VII2.locald>
References: <CO1PR00MB130824EBDD7C1420E9D3065CF54E9@CO1PR00MB1308.namprd00.prod.outlook.com> <CAFWvErXY4NmpAr5SwN7UTsYmYJiL0HdxhmFrdPjpm0Ca0Hh++Q@mail.gmail.com> <DBBPR08MB59155B9005035B3365BCC12AFA529@DBBPR08MB5915.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DBBPR08MB59155B9005035B3365BCC12AFA529@DBBPR08MB5915.eurprd08.prod.outlook.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/5EvEsk4JGLHMBIUWwDcqT5tQohg>
Subject: Re: [COSE] COSE HPKE Public Key Format Consensus Call
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, 26 Sep 2022 10:54:45 -0000

On Mon, Sep 26, 2022 at 07:33:49AM +0000, Hannes Tschofenig wrote:
> Hi Daisuke,
> 
> With your proposal and Ilari’s proposal there are two ways to encode
> public keys in COSE libraries. This adds complexity. Complexity
> leads to security problems.
> 
> Here is my question to you: How do you deal with this added
> complexity? (FWIW this is not something you mention in your comparison
> table.)

The way my test implenetation dealt with that complexity is by strictly
treating one as compression of the other. Once uncompressed, there was
no difference between the two.

As consequence, if message to P-256 long-term public key had EC2/P521
ephermeral key, the implementation would happily uncompress the key
and then call into HPKE code (which then vomits with ek length
incorrect).



-Ilari

v2.23.0 | Report a Bug | By Email