IETF Logo Mail Archive

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 29 November 2022 17:22 UTC

Return-Path: <mcr+ietf@sandelman.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 454C9C152572; Tue, 29 Nov 2022 09:22:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 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_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=sandelman.ca
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 iHjrcs9awQtY; Tue, 29 Nov 2022 09:21:58 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (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 EA8C1C1524DC; Tue, 29 Nov 2022 09:21:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D043B1800D; Tue, 29 Nov 2022 12:47:57 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EPfnAQtTS4Su; Tue, 29 Nov 2022 12:47:53 -0500 (EST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id A84281800C; Tue, 29 Nov 2022 12:47:53 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1669744073; bh=egyNnXRwt8J4DDUJzgdtN5VGC4UaO9gAGDsLsfekS+w=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=d2HNgM+gx8GLsGYR0XjfoBx094aSzusk2zZJmwU65j5EjShVvj8VKh3dOSprVL7ny WEghxHZyKKIWXSmW0dzpKd+aX4siD1cGllb1HDsQmjrCsRNI38b0D3A83RomTiCco8 56FKUyA5JJi6HWrZ48pyJgp0boE/qyPbDd6RE6aoIYcK3daKooE0DR76Pg6BmwXcXt TjIoTnD8kyfq6ZVFednzW+DVv/u2GPBMKDbqni9MURV5E1LXkJlj0gaHgKidfykq0P nDFLohZo5Ipax4dABmGYrbtRaWAThJTXFsmYI4p7tSxjU7v9wOcV2qiOAyQVrWn3vP 6gRq2wKC7m1ug==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EBB59B7C; Tue, 29 Nov 2022 12:21:50 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Paul Wouters <paul.wouters@aiven.io>
cc: The IESG <iesg@ietf.org>, draft-ietf-ipsecme-ikev2-multiple-ke@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, kivinen@iki.fi
In-Reply-To: <166966973968.20669.3414159618699952233@ietfa.amsl.com>
References: <166966973968.20669.3414159618699952233@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 29 Nov 2022 12:21:50 -0500
Message-ID: <1871.1669742510@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/OXmIrRR6TKH8V40wmFfk700jAog>
Subject: Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 29 Nov 2022 17:22:02 -0000

Paul Wouters via Datatracker <noreply@ietf.org> wrote:
    > Also RFC 5723 states: ``` The keys and cryptographic protection
    > algorithms should be at least 128 bits in strength.  ``` IF we live in
    > Grover universe, perhaps that should be 256 bits in strength? And since
    > we are making things quantum safe with this document, perhaps we should
    > then at least state session tickets should be 256 bits. Note if we do,
    > then this document must Update: RFC 5723. Perhaps this note on 5723 can
    > be added in the Security Considerations Section paragraph that talks
    > about Grover and Shor.

My understanding of this document is that it tells us how to do multiple KE
exchanges, as state in the abstrct:

   Another possible application is the
   ability to combine several key exchanges in situations when no single
   key exchange algorithm is trusted by both initiator and responder.

It seems that if one wants a particular safety against a Grover universe,
that we should update RFC8247, or create a companion document.
I don't think that we should embed everything in this document.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email