Re: [CFRG] Update of the AEGIS draft

Martin Thomson <mt@lowentropy.net> Mon, 24 April 2023 00:04 UTC

Return-Path: <mt@lowentropy.net>
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 7AA4DC15155F for <cfrg@ietfa.amsl.com>; Sun, 23 Apr 2023 17:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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=lowentropy.net header.b="JZWqD72C"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="VjAzdgnQ"
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 Dz7ffrTMs-Ue for <cfrg@ietfa.amsl.com>; Sun, 23 Apr 2023 17:04:50 -0700 (PDT)
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 B01F6C151536 for <cfrg@irtf.org>; Sun, 23 Apr 2023 17:04:50 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 7E1EB3200914 for <cfrg@irtf.org>; Sun, 23 Apr 2023 20:04:49 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute6.internal (MEProxy); Sun, 23 Apr 2023 20:04:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1682294689; x=1682381089; bh=Ax3erttIXa3lYelHOMz+LXADtSkHtP7QOoF E6SXjcrI=; b=JZWqD72CefCKJJ7DY7LV3AKfF5Zy6Kh8Sq0IvlbEPK4wsSXp94l nVgDrZ3X24V41+JP5pA0eDzE4HsB+cPUmxOdJWbZhWVProOofSibv4tdiuYNz8u/ t3J2zTpRcF/FEvHfV1pgq0ZV4/+BrPLPU+ePvUe10pY5jHqiuqzz77lO4c7vVt77 UQ1psnjWl0OOr9aScNol37hZpqT/mmyuQvtX0ttPvkKvcIQe8pRC3OtNYMSx+I0G 5yx/RYUNS/XE00bbGByeM+utdjnruTgOeqwtC+TzOIEfa8oT8ZrsgfvOSbD0fQNB F484PgIt/eUaoGSCdbfbv6/5Nqw1QBnNEKA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1682294689; x= 1682381089; bh=Ax3erttIXa3lYelHOMz+LXADtSkHtP7QOoFE6SXjcrI=; b=V jAzdgnQ988qGoygAP5wDAgd4fQJ9TI0BXcuN33eNY+YVpffv4ZdwIv2sseImNrrX XkRMqEshoHlWKrT2vUBp9CZPIeWV2/uX6ND3G749SSUW4h9fUUMbTwrcxS/MQol0 x1+lvd0Tfj7Jsh5fA6yWa52SXWG0F/WweOx+YDYz4/NVh2+IzgvlLKWvy0FD0j5Q T235E/pn5jEFjUNpc6fbnuzFbVKhxbSXq46LRigypbuKn+STM9/5UxcuQXFxHq31 nNGKvEKH6QMS4Ft3O9AJwOgU6rDGeNevyO4XKPrHAL2vPZ8zU1p/WfwuRMQRj7ei 1TV86efDRwbsey9oOzuBQ==
X-ME-Sender: <xms:oMdFZKvOX96faUV6BlKCjWa5r1VKk-squQFgnbTFij9oydi48MBaow> <xme:oMdFZPe8EtoqFJK7XQ-6yQi53eP32uX8RZcfyn1q8IkzeGWk-Im2b_szALfuorBAY _4M4-u0XRYzNaVtcl0>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedtledgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth
X-ME-Proxy: <xmx:oMdFZFy31Axd38qsGr22YNsN6xVwD0G2RoK16FaDnXdLxfqgVyaa8g> <xmx:oMdFZFMmAqlSM1QeC3MF-oo7FzBuVOj0mpsQWDg7OdBamNFXh9A18g> <xmx:oMdFZK-nIG-lHkVt5nrIi3PQ8aoWoY4_dkvuqz0RAmNoeUXPM3nrGQ> <xmx:ocdFZNJDvcsdX8o3sA6X6yh8aOs3JpVcNYyAa2BmHi3jH6dcHwrIlw>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id DDEB8234007E; Sun, 23 Apr 2023 20:04:48 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-372-g43825cb665-fm-20230411.003-g43825cb6
Mime-Version: 1.0
Message-Id: <0869427d-eb78-4ea8-b597-0bab2eb0b82f@betaapp.fastmail.com>
In-Reply-To: <9CC12137-BADD-4CFB-B318-0850D68E29AF@csperkins.org>
References: <2F9EE079-3605-4451-BA69-99F12CE7AE38@pureftpd.org> <GVXPR07MB96786B0EA4017D02EFAB75D389999@GVXPR07MB9678.eurprd07.prod.outlook.com> <9CC12137-BADD-4CFB-B318-0850D68E29AF@csperkins.org>
Date: Mon, 24 Apr 2023 10:04:28 +1000
From: Martin Thomson <mt@lowentropy.net>
To: cfrg@irtf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/bBK3MqnCqQU2tB_amKoTfUL0teM>
Subject: Re: [CFRG] Update of the AEGIS draft
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://www.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://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2023 00:04:55 -0000

On Sun, Apr 16, 2023, at 00:37, Colin Perkins wrote:
> Section 2.1 of RFC 5743 requires certain statements be included in the 
> Abstract and Introduction of IRTF drafts. This includes making it “very 
> clear throughout the document that it is not an IETF product and is not 
> a standard”. Having this text in the Abstract is one way of addressing 
> that requirement, so I would not remove it.

Maybe this is a case where the algorithm and its application might be split.  One document might describe the algorithm in the CFRG and IRTF, and the application to TLS and other IETF protocols could then be standards track.