Re: [openpgp] ECDH PKESK v5 change

Daniel Huigens <d.huigens@protonmail.com> Tue, 20 December 2022 14:18 UTC

Return-Path: <d.huigens@protonmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343B0C14EB1C for <openpgp@ietfa.amsl.com>; Tue, 20 Dec 2022 06:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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=protonmail.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 Aj9pDufo5WIW for <openpgp@ietfa.amsl.com>; Tue, 20 Dec 2022 06:18:19 -0800 (PST)
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 1E856C14E514 for <openpgp@ietf.org>; Tue, 20 Dec 2022 06:18:19 -0800 (PST)
Date: Tue, 20 Dec 2022 14:18:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1671545896; x=1671805096; bh=eE18ZntlWHrdiK0Y3FE3BYDHGBAOCNl5IcqS4jZaTiY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=ELhmbH9c0TLefDgKPih1anAxQQC4/FVQHrvJmgUqmjukDOFcTfnzElOVsiu6Ft053 TpRlotwAWnMbSqEKWLD3PVajFRqle+cBY4g+OogCbA/nc+i/AePN7v/KR5Lt1dEAjO K4aLMQZFXx/QGqb25g2vug9vex8mcZQi9QzHRWftMlqYzn+ldKpPZnJTu/cnfeOFfg qhEvgyrzI6NDVQSxgFo4oIBzxkNMMS5YBIJJHXJKs7Yw4t+Ftsh8FBgI3MIWTP9zXl 0yp2UUVSMQnEUKPyskp93M3OVrgfzsmoDaGScbq6/wd6t0liV0OaqSA8lE2NcxZg/D 8BsGJa79T0SsQ==
To: Aron Wussler <aron@wussler.it>
From: Daniel Huigens <d.huigens@protonmail.com>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>
Message-ID: <X-ndzYQ6FMvna-Nd7GDAtYe51meby_gRuT2tStjqL_kmd2lhvErVDygkxUJbuGCTMnKrtZzEguBI8kycE-5VtWNLMhG48C0cxEECH5ShUvw=@protonmail.com>
In-Reply-To: <Axf6rk8dxEfOSaNLdXrdl_yDa8sr-3ypOUYEO-gq8IyIw869K9sRUdoBA1FRgc2CKgcf4idwfR2TCo0EH3FvA9eTlCAe7WL8pMxJjZY27Tc=@wussler.it>
References: <Axf6rk8dxEfOSaNLdXrdl_yDa8sr-3ypOUYEO-gq8IyIw869K9sRUdoBA1FRgc2CKgcf4idwfR2TCo0EH3FvA9eTlCAe7WL8pMxJjZY27Tc=@wussler.it>
Feedback-ID: 2934448:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/gcxBbScn9Qf8S0GkbXiJ7FVSsFo>
Subject: Re: [openpgp] ECDH PKESK v5 change
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2022 14:18:23 -0000

Hey Aron,

On Tuesday, December 20th, 2022 at 14:36, Aron Wussler wrote:
> In section 12.5 we change the encoded data in the encrypted part of the v5 ECDH PKESK, removing the symmetric algorithm ID.
> 
> 1. Doesn't this effectively remove the binding between session key and PKESK?
> I could reuse the same key packet for a different Sym. Encrypted Integrity Protected Data Packet encrypted with another algorithm.
> Embedding this into the Param of the ECDH KDF could also be very tricky, as we would be mixing info from different packets.

SEIPDv2 has an HKDF step, so the key that actually ends up being used
for encryption is bound to the algorithm ID.

Nevertheless, you could indeed reuse a PKESKv5 packet with an SEIPDv2
packet with a different algorithm, but I don't think that's actually a
problem, in fact it's essentially what e.g. Justus wanted, to be able
to reuse PKESKs for reply-to-all.

> 2. Can we also drop the checksum?
> 
> RFC 3394 contains already a 64-bit checksum, making this effectively a 10-octect checksum.

Yeah, I agree. And actually I think we could remove the padding as well;
since we moved the algorithm ID to the SEIPDv2 packet (in plaintext)
the padding doesn't really hide anything (nor does it seem very valuable
to hide the key length). That way, we could use "plain" AES-KW, which
should simplify things.

Best,
Daniel