IETF Logo Mail Archive

Re: [Pqc] [Ext] Mapping the state of PQC and IETF

Paul Hoffman <paul.hoffman@icann.org> Mon, 27 February 2023 18:47 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: pqc@ietfa.amsl.com
Delivered-To: pqc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DB9C151709 for <pqc@ietfa.amsl.com>; Mon, 27 Feb 2023 10:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 lJkahqOa3ux6 for <pqc@ietfa.amsl.com>; Mon, 27 Feb 2023 10:47:14 -0800 (PST)
Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (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 2901EC14CE5F for <pqc@ietf.org>; Mon, 27 Feb 2023 10:47:14 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa5.dc.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 31RIlBx4027244 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Feb 2023 18:47:11 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.21; Mon, 27 Feb 2023 10:47:10 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.1118.021; Mon, 27 Feb 2023 10:47:10 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
CC: "pqc@ietf.org" <pqc@ietf.org>
Thread-Topic: [Pqc] [Ext] Mapping the state of PQC and IETF
Thread-Index: AQHZSshg/Fy5oOqRckiESoD8h7k6Gq7jqFaA
Date: Mon, 27 Feb 2023 18:47:10 +0000
Message-ID: <FF2B9EA8-A0EC-45CA-82AC-0C081C6785C5@icann.org>
References: <667bd090-1a3e-82d0-f663-8950fcd6dd38@riseup.net> <16A23C37-93BD-4F72-BCF9-3E3C689A0591@icann.org> <6db90caa-44de-c1e6-4676-7ed1a2943503@gmail.com>
In-Reply-To: <6db90caa-44de-c1e6-4676-7ed1a2943503@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A9263C04B6DC9144B36384DF76A1C6D0@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22 definitions=2023-02-27_15,2023-02-27_01,2023-02-09_01
Archived-At: <https://mailarchive.ietf.org/arch/msg/pqc/pOoHiEspPtT_d7mDft9Vo8mHtxY>
Subject: Re: [Pqc] [Ext] Mapping the state of PQC and IETF
X-BeenThere: pqc@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Post Quantum Cryptography discussion list <pqc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pqc>, <mailto:pqc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pqc/>
List-Post: <mailto:pqc@ietf.org>
List-Help: <mailto:pqc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pqc>, <mailto:pqc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2023 18:47:16 -0000

On Feb 27, 2023, at 8:27 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> One question that comes up in some discussions in other IETF groups is
> related to the need (or no need) to upgrade to quantum resistance some
> IETF methods that generate parts of an IP address.
> 
> For example, RFC3972 'CGAs' (crypto generated addresses) uses a lengthy
> algorithm involving SHA-1; this RFC is then further used by LISP RFC,
> among others.
> 
> . . .
> 
> The same kind of question applies to other RFCs for other protocols such
> as the return routability tests for MIP6, and others, perhaps HIP.
> 
> I am also wondering about the use of algorithms such as MD5 or SHAx to
> generate random - probably unique - numbers (e.g. ULA generation method
> in RFC4193).

Hash functions are not in the least bit threatened by cryptographically relevant quantum computers (CRQCs), so there is absolutely no concern for CGAs and the like even if CRQCs existed.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email