Re: [jose] [COSE] HPKE PartyU / PartyV

AJITOMI Daisuke <ajitomi@gmail.com> Sun, 03 March 2024 08:34 UTC

Return-Path: <ajitomi@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 9A2ACC15170B; Sun, 3 Mar 2024 00:34:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=gmail.com
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 IG0epXVLROUw; Sun, 3 Mar 2024 00:34:09 -0800 (PST)
Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 65C02C151710; Sun, 3 Mar 2024 00:34:09 -0800 (PST)
Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-dc25e12cc63so4343443276.0; Sun, 03 Mar 2024 00:34:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709454848; x=1710059648; 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=5VAu4pVG6hiMi88E/BUB7nIkBA4zxpAV4Dzuec9iZtw=; b=DOZn0/xwwSP8Zofe+6b+UKUws/5VTGnJMNEI23M8GpOTeXs76D/MIUPHEhFq8vMmM+ Nu9v83y04+UWl9rSL3D/paRpZ35v6wMc8fEGh8Xj01lZYMCk3EKcbvOu2uSNOeroV2km iAgrx5oUcP2tfcuXkniLnYeIbdsAXwWhmR5/D+Bl+Oadqikt39cAzNlab/YM4wHGANpl UGVKhphBej/nS1WhSuJ0MnKlRE8K4m+BRFyrRHxqjxF+vM7sai6ryf58lx8syJ2jYRJb 97rlk1ixBXF0T6cIidrDFkwpvbAwff1PNsVfjwtU5OAt1EdcHCI2EApBHzOhWHII9nVU jtFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709454848; x=1710059648; 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=5VAu4pVG6hiMi88E/BUB7nIkBA4zxpAV4Dzuec9iZtw=; b=GvTSNlwi5fuN5wHUtyMbQVX0oFChXi15B8NC/8v/CIeI98BzBY3iPMjd1RUlaBfD8u 9sVjgAYcWu7utNBUvaD/sluOPfvzRCj+S+4ldTztOBvsS/qTyYw80fX5Ib5HIA/kICfR Ds201XbZ2mCjyIpXq7uIntb2PKA/FTLMK/GzwWxzVyeJ+gCyAVnQ5vfGhlsm6Hfcaspz Nt9vtRbpVxBINitIsyZZ1woB0luk76uRKc1iqsR8yrZZ+SCHdyQRRIfqr55KJBiO1Hrg 7CfGulWmYUVQURHsJCtCY2BGhKkC01zcbK+ByvSjFsUIMX0jzZj0qisMoCFRXFLLuKKM +uEQ==
X-Forwarded-Encrypted: i=1; AJvYcCW1H6WDIVczPiqsNPBB/vKeIHL9kJXH5UjU/atJz9+U6YALAE9gawSiJzIpH0JpaMxJ5hEtPtcfPEIAKdqzwQBzov/FH6t9LPSPIQns
X-Gm-Message-State: AOJu0YzS4oN+BhZJNZ4bBtRKiCHnBSeiAo8zHOSk7Lkx2+4wYQuYfU+I qMXDpNZii7Ku0qdX7/oOMFWvoP48BqwjpYk8FcPkJwtKSP8GEgSvxaqoVAWhkx+fPd2YIFuWZ4N Ey5spUoxOwtQ3dDWcWKpr9Eb9kA==
X-Google-Smtp-Source: AGHT+IF9YvJ0vXJba4fn9n2WmT8MtkPEIusbG82w5eAssy6k9tQ8KIwa8G6/Vh7kJiIr7eQ6WkW3A3tuGg8RHKeX9ho=
X-Received: by 2002:a05:6902:180d:b0:dc6:c252:75fe with SMTP id cf13-20020a056902180d00b00dc6c25275femr7084753ybb.10.1709454848178; Sun, 03 Mar 2024 00:34:08 -0800 (PST)
MIME-Version: 1.0
References: <CAN8C-_LUMe09=WbkwT-RckhR8+LYCQMw8XWnwmDLE5riYjd7pg@mail.gmail.com> <Zd749IrwWC2hI6yX@LK-Perkele-VII2.locald> <CAN8C-_J+mMABCa2HPWv5zJ=u1HSb+saq_mn5kB0Wq5upWUyM9Q@mail.gmail.com> <Zd-NRA2kH4fc_d-X@LK-Perkele-VII2.locald> <CAN8C-_+tG9845bn986Anr89ObNpUCzOAuiEJMPh4KGK3ixB+uQ@mail.gmail.com> <Zd-colj_jF47gLQP@LK-Perkele-VII2.locald> <CAN8C-_Jw2J6OY6N7gRVepVuHiC5NqgH36dXQ6krZ1U-Spqq7fQ@mail.gmail.com> <ZeCZJK76cQNZp7q9@LK-Perkele-VII2.locald> <CAN8C-_+_nzGCWV6zNny1j_9TTikW8rBtw9388YB7UGzSwEzoTw@mail.gmail.com> <ZeDih4he5eZ1y3PO@LK-Perkele-VII2.locald> <729F40F3-B0EC-41EF-A0D2-FD8EDEA39D56@island-resort.com>
In-Reply-To: <729F40F3-B0EC-41EF-A0D2-FD8EDEA39D56@island-resort.com>
From: AJITOMI Daisuke <ajitomi@gmail.com>
Date: Sun, 03 Mar 2024 17:33:57 +0900
Message-ID: <CAFWvErWwfkT7cz4R-jMt+3-54ywyVwBjE=Lita7TwsQEi04TTw@mail.gmail.com>
To: "lgl island-resort.com" <lgl@island-resort.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, JOSE WG <jose@ietf.org>, cose <cose@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fc45ee0612bd7888"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/1G9YkvgT6yGnpzdK7mFTrR31H_k>
Subject: Re: [jose] [COSE] HPKE PartyU / PartyV
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 03 Mar 2024 08:34:13 -0000

I haven't been able to read through all of the long discussions so far, but
...

Ilari, even if you can’t say why, can you tell us where the text that
> prohibits use of both INFO and AAD is?


I think this is about the following in Section 8.1 of RFC9180:

Applications that only use the single-shot APIs described in Section 6
> should use the Setup info parameter for specifying auxiliary authenticated
> information. Implementations which only expose single-shot APIs *should
> not* allow applications to use both Setup info and Context aad or
> exporter_context auxiliary information parameters.


It's not prohibited, but it says "should not''.

This essentially means that, in HPKE, In HPKE, both INFO and AAD serve the
same role of binding information from the application layer to the HPKE
process and the difference between INFO and AAD only comes down to whether
the same can be used across multiple EncryptionContexts (INFO) or not (AAD).

I believe that at least the authors of HPKE regard both in this way.

Best,
Daisuke

2024年3月2日(土) 4:23 lgl island-resort.com <lgl@island-resort.com>:

>
> On Feb 29, 2024, at 1:01 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> On Thu, Feb 29, 2024 at 11:04:57AM -0600, Orie Steele wrote:
>
> I think we actually agree here.
>
> The remaining point is just what to do in HPKE.
>
> 1. New header parameters, mandatory processing rules, mix
> content encryption algorithm into the KDF (via HPKE INFO).
>
>
> HPKE does not allow using both INFO and AAD for one message (I do not
> know why), and INFO has a short length limit (because it is used in
> ways that pretty much require buffering).
>
> So only AAD can be used.
>
>
> Illari, even if you can’t say why, can you tell us where the text that
> prohibits use of both INFO and AAD is?
>
> Note that COSE -25 and -29 allow the input of a salt into the KDF outside
> of COSE_KDF_Context. If we wanted to do similar in COSE-HPKE, use of the
> info parameter is the obvious place.
>
> I can’t see any technical reason that both couldn’t be used and I wonder
> if there is some reason we might want to allow COSE-HPKE users to be able
> to supply inputs to the KDF function.
>
> Or asked another way, what are the security trade-offs between AAD and
> INFO? There’s lots of security considerations in RFC 9180, but none seem to
> discuss this.
>
> I don’t see an issue here, but it would be nice to understand.
>
> Thx!
>
> (RFC 9180 is impossible to search because the variable names used in the
> Python code are so short. “info” occurs almost 200 times)
>
> LL
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>