IETF Logo Mail Archive

Re: [CFRG] (no subject)

Filippo Valsorda <filippo@ml.filippo.io> Wed, 21 February 2024 18:04 UTC

Return-Path: <filippo@ml.filippo.io>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DC2C151084 for <cfrg@ietfa.amsl.com>; Wed, 21 Feb 2024 10:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.707
X-Spam-Level:
X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=filippo.io header.b="X66e9fHz"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="LhHjW94f"
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 i65U-hSN89IJ for <cfrg@ietfa.amsl.com>; Wed, 21 Feb 2024 10:04:27 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 EAD1FC14F682 for <cfrg@irtf.org>; Wed, 21 Feb 2024 10:04:27 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DE8C93200A57 for <cfrg@irtf.org>; Wed, 21 Feb 2024 13:04:26 -0500 (EST)
Received: from imap51 ([10.202.2.101]) by compute1.internal (MEProxy); Wed, 21 Feb 2024 13:04:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1708538666; x=1708625066; bh=4LFE9dXVa/ vX6v2EAOHY5Zk7Z1NSBObdjJUvwGtpkSs=; b=X66e9fHz8YYPCoGgMvjR4kB09t h0VkO44wanQ/tDCvxjlTErenKTXT66S0XVDONBQJi1vvJx3a+3NsDBKo8z6Z25yG R4bHmTpT2+5m8MfbiVZehcd3dBXUpDpZFPTuOadyBUyohcj1I1WA0wSpF6hSF8cj 3X4+Pl05Xs1UgV5NpAZRmDF3HztdEyRV68x4XXNDU52Y3l3VT/PbcDY2G1BiEBFH IGFmXIwry5wmQyh+VMyCPOV4yBB4z0c1OgZJ7NQXhwxqbFk3vi8Mb3sZL/R+Ys+s cJVEA9X8xXZCUTq8qgcSR15tG5iuIq2mPvJrejBvzIc7Lp58jyQvKZYn1aYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1708538666; x=1708625066; bh=4LFE9dXVa/vX6v2EAOHY5Zk7Z1NS BObdjJUvwGtpkSs=; b=LhHjW94fM95HQv3yZgcwEp/9au73e3kCfd6gUKDAfX9r F+rn5lFHZXgd37fM7bcutZJf8N8ykVREAw/nFmoA0vGYFjFKyBjzMIa9A21cg0gU +1QDn04sk6OiNbS76QOLZB9MWfaZB81GkgN20keGp4kN3NDguFQ59vkOkT65sqoB 4N13dwFaVvGekF4blgPfpl69MiLoQnm1KGjTBUtTWO7FFr5BPpd7BlGOnGnDts/4 o4xEfeo9+3e4eNDvuVzcYV8tZggpFuH4Ohz9MAU1PEoXcbEBvplzvGCX+JIaIHO2 TjgquKys/9xd707s84Edp8Hvz3aFAeA/k/E+Kp3z8w==
X-ME-Sender: <xms:KjvWZR6xQXmYEH36e4SFBJs6o21xjfm-9QOJ6vsnxRVbCcX6WBndOw> <xme:KjvWZe55tzk9uAwO3ewGO5tRRSyxA6pRvJvQSO54D8fREeW76QC_ug8mOhETE2nbT zmn7PN3g-lHgMXrng>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedvgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgogfhmphhthifuuhgsjhgvtghtucdluddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfhfhilhhi phhpohcugggrlhhsohhruggrfdcuoehfihhlihhpphhosehmlhdrfhhilhhiphhpohdrih hoqeenucggtffrrghtthgvrhhnpeffffeujeegkefgkeetgfduudejledthffhfedtvdei jefhhfdvueeugfejlefhheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehfihhlihhpphhosehmlhdrfhhilhhiphhpohdrihho
X-ME-Proxy: <xmx:KjvWZYcWcy1i8oLHdTVzFp0X3laoPwCK-HJYKcBYtkdsyRR1kjWruw> <xmx:KjvWZaJNldsdHQrRMpiVdBGlNQG00RXch_evZZ7ict7mtPB0FWTfzg> <xmx:KjvWZVJe7ev_5IUWQMc-QFtfuFMvktaOZ0a9cdlpOskrLXHn5FgsRg> <xmx:KjvWZaXhHzaIU-bcmJTtBoY_fn5OIAujuS3YWp2bxEWIkbqTXzUHfg>
Feedback-ID: i2e91459c:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1C62EB6008D; Wed, 21 Feb 2024 13:04:25 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.11.0-alpha0-153-g7e3bb84806-fm-20240215.007-g7e3bb848
MIME-Version: 1.0
Message-Id: <25cecba9-7c35-41c7-962a-c204a76e538c@app.fastmail.com>
In-Reply-To: <20240221165144.860827.qmail@cr.yp.to>
References: <20240221165144.860827.qmail@cr.yp.to>
Date: Wed, 21 Feb 2024 19:03:36 +0100
From: Filippo Valsorda <filippo@ml.filippo.io>
To: cfrg@irtf.org
Content-Type: multipart/alternative; boundary="d479c52fedea4f45ad7ff03136f69763"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/rOVxXBDJJh3Nyss-PHI256n6s3w>
Subject: Re: [CFRG] (no subject)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://mailman.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://mailman.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2024 18:04:32 -0000

2024-02-21 17:51 GMT+01:00 D. J. Bernstein <djb@cr.yp.to>:
> That paper unnecessarily imposes work upon security reviewers.

Are these security reviewers available to comment on the extra burden? Because so far we've heard unequivocal comments from implementers about the work a design where "alternatives to Kyber can be simply plugged in" risks imposing on us, and only speculation on the extra work that the opposite would impose on security reviewers.

In general I believe there is a pyramid of populations involved in deploying cryptography.

█ Specification authors
██ Security reviewers
███ Crypto implementers
████ Application developers
█████ End users

Any work that can be pushed up the pyramid should be, because it reduces duplication.

Just like as crypto implementers we should do extra work not to burden application developers, I think it's fair to do some extra one-time security review work to avoid multiplying work across crypto implementers.

Assuming, that is, the goal is rapid secure deployment, and not ensuring "alternatives to Kyber can be simply plugged in" in itself.

v2.46.0 | Report a Bug | By Email | System Status