From nobody Tue Dec 20 06:18:24 2022 Return-Path: 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 ; 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 ; 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 ; 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 From: Daniel Huigens Cc: "openpgp@ietf.org" Message-ID: In-Reply-To: References: Feedback-ID: 2934448:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 v= 5 ECDH PKESK, removing the symmetric algorithm ID. >=20 > 1. Doesn't this effectively remove the binding between session key and PK= ESK? > I could reuse the same key packet for a different Sym. Encrypted Integrit= y 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? >=20 > 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