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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 27 February 2023 16:27 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 26F49C14CF1F for <pqc@ietfa.amsl.com>; Mon, 27 Feb 2023 08:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level:
X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 p1ik8FjozGl8 for <pqc@ietfa.amsl.com>; Mon, 27 Feb 2023 08:27:16 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 79026C14F74F for <pqc@ietf.org>; Mon, 27 Feb 2023 08:27:16 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 31RGRDW2036483 for <pqc@ietf.org>; Mon, 27 Feb 2023 17:27:13 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E3194206AD0 for <pqc@ietf.org>; Mon, 27 Feb 2023 17:27:13 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D826F203E53 for <pqc@ietf.org>; Mon, 27 Feb 2023 17:27:13 +0100 (CET)
Received: from [10.11.240.3] ([10.11.240.3]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 31RGRDYM026308 for <pqc@ietf.org>; Mon, 27 Feb 2023 17:27:13 +0100
Message-ID: <6db90caa-44de-c1e6-4676-7ed1a2943503@gmail.com>
Date: Mon, 27 Feb 2023 17:27:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
Content-Language: fr
To: pqc@ietf.org
References: <667bd090-1a3e-82d0-f663-8950fcd6dd38@riseup.net> <16A23C37-93BD-4F72-BCF9-3E3C689A0591@icann.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <16A23C37-93BD-4F72-BCF9-3E3C689A0591@icann.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pqc/CaAiompFusZJ2_1YP5_14SL0W9g>
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 16:27:18 -0000


Le 27/02/2023 à 16:58, Paul Hoffman a écrit :
> On Feb 27, 2023, at 7:46 AM, Sofía Celi <cherenkov@riseup.net> 
> wrote:
>> We have started work on mapping the state of PQC (if any draft or 
>> RFC exists) in the different IETF protocols/WG and IRTF groups: 
>> https://github.com/ietf-wg-pquip/state-of-protocols-and-pqc to
>> keep track of where everything is at. Feel free to contribute by
>> sending a PR. We hope this list is useful to many.
> 
> Or, if you're not comfortable with opening GitHub pull requests,
> feel free to open an issue on the tracker or just post something here
> on the list!

Thanks for the list of drafts and RFC about PQC at IETF - impressive,
already 19 documents.

I am not a crypto expert, sorry if I say naive things.

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.

Would there be any risk in LISP using these CGAs, and thus would there
be a need to migrate to quantum-resistant algorithms?

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).  Would they be at risk in that randomness (risk of
duplicates), currently, or not.  Would they need to be migrated to
quantum resistance; would these new algos be better at generating
uniqueness?

This question of need - is there any need of quantum-resistance in this
or that particular context - is very important in many places.  Without
more definite agreements there would be no migration in the immediate.

It might that there is no currently perceived need, but would rather
need to move to quantum resistance because all others do, if one wants
to stay interoperable.

It might be that there is no currently perceived need, and one should
not move to quantum resistance currently because that involves too much
energy and compute consumption.

Alex

> 
> --Paul Hoffman
>