IETF Logo Mail Archive

Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05

Paul Wouters <paul@nohats.ca> Wed, 05 January 2022 15:01 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BCD3A0B3C for <ipsec@ietfa.amsl.com>; Wed, 5 Jan 2022 07:01:34 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG57fgt3FA6i for <ipsec@ietfa.amsl.com>; Wed, 5 Jan 2022 07:01:29 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7B53A0B3D for <ipsec@ietf.org>; Wed, 5 Jan 2022 07:01:29 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JTXkG6G9Jz35D for <ipsec@ietf.org>; Wed, 5 Jan 2022 16:01:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1641394886; bh=4vu5YvqvvjVg4QljSIHR/4XpS2YKtI+J0FhauNxhhDY=; h=Date:From:To:Subject:In-Reply-To:References; b=BIVwg7cRcr9sKqMHd74RAL1G+folqfb90I+DmeSOw8TssHObbABDxq0egez48SImJ Q6nhLTqM23n+/GQqAyQtGWqCcKum7VWYZcf3rGHofLQHoPoIaGicwG3P+G+u37KKOX X1tLLpnp7NrvHLkXt+vCXvZJtBW+QKjYEchEgB1o=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id gkAA_cMaezwA for <ipsec@ietf.org>; Wed, 5 Jan 2022 16:01:24 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <ipsec@ietf.org>; Wed, 5 Jan 2022 16:01:24 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6CCDC1E95D1; Wed, 5 Jan 2022 10:01:23 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6B9CA1E95D0 for <ipsec@ietf.org>; Wed, 5 Jan 2022 10:01:23 -0500 (EST)
Date: Wed, 05 Jan 2022 10:01:23 -0500
From: Paul Wouters <paul@nohats.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
In-Reply-To: <93173a3f-4954-09b6-cca3-b7f984e7daa1@lounge.org>
Message-ID: <9679f119-378a-f750-f019-5b21388e1@nohats.ca>
References: <9fd1c9c7369d5635ad2187e30c9771ff.squirrel@www.rfc-editor.org> <f02be27d022120f967ea57479bb91ae5.squirrel@www.rfc-editor.org> <93173a3f-4954-09b6-cca3-b7f984e7daa1@lounge.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/-u8WwPcVGfse8d_UQnoYXmznx40>
Subject: Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jan 2022 15:01:34 -0000

On Tue, 4 Jan 2022, Dan Harkins wrote:

>   I agree with Tero here. This "tightening" is not necessary. There's no 
> security
> benefit by disallowing the RFC 7296 RECOMMENDED method of treating AEAD 
> ciphers.
> The only thing this will do is require pointless changes to existing RFC 7296
> compliant implementations.

I also agree. While I wish we had only one way of specifing an AEAD
without integrity algorithm instead of two, the ship sailed long ago
and code is there do deal with both of these. There is no gain from
restricting it.

Paul

v2.23.0 | Report a Bug | By Email