Re: [saag] PQC in ZRTP (RFC6189) and hybrid KEM

Colin Perkins <csp@csperkins.org> Mon, 22 November 2021 22:24 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2F3A087B for <saag@ietfa.amsl.com>; Mon, 22 Nov 2021 14:24:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
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 7D-wAe1Xe5jq for <saag@ietfa.amsl.com>; Mon, 22 Nov 2021 14:24:42 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 8D7463A087E for <saag@ietf.org>; Mon, 22 Nov 2021 14:24:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=+Djhy2043VXsGlpD4G6kVwslBKoTKXoG2iuZniF2Z8g=; b=h4k3TlSpHQM6f6TNhhA36aM3dY m6d+QE9E3xB7STo659mtvJBPNgX5C8gg0CpkC90b0hsRjepF3ft6bx3kSOmENxTAXb+Ri/7/uyWf3 bBN+wAnyo6D+U7pNz7M0xDjfuYlZGCatB8WtIbUg9eZxnfP4y64LueM/A/IXHDVAeRtWrw+IifAzF LBFf9MiEBhH1IKfDPvSEAcbCYW23xROsD2thVXkrUbZ5ttmHK7LMklroZZnWGkmNS4SSvFP/CllZj 1Xs1DVlfguES2rZBCWK5EZAPLlNPz4C6HDSVVSh4ABLuYhcEHxAzhbBDn7hQuEhWmQFH2g2EnJRBV 0sMQWDOw==;
Received: from [81.187.2.149] (port=39137 helo=[192.168.0.67]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1mpHjn-0002fX-6U; Mon, 22 Nov 2021 22:24:39 +0000
From: Colin Perkins <csp@csperkins.org>
Message-Id: <07B3853F-906A-4A68-B7B1-D1FF699AA83B@csperkins.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95F7D844-2052-424F-81E8-B15A7D2F15FC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Mon, 22 Nov 2021 22:24:27 +0000
In-Reply-To: <f0aaeb33-0bf7-c5e0-5df3-d251a4c24b9f@linphone.org>
Cc: Eric Rescorla <ekr@rtfm.com>, IETF SAAG <saag@ietf.org>
To: Johan Pascal <johan.pascal@linphone.org>
References: <0c359a65-386e-8c09-4c8f-9cefb066cffc@linphone.org> <CABcZeBPME1Eos8SFQdmAGRP5smn=bfAdPVOTrxF10nU3wkEbeA@mail.gmail.com> <B8A00186-3F5E-4075-8244-B4B9F069BD5B@csperkins.org> <f0aaeb33-0bf7-c5e0-5df3-d251a4c24b9f@linphone.org>
X-Mailer: Apple Mail (2.3445.104.21)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/IW9V51yyqw4W_rH06ZuHpIJ9RjA>
Subject: Re: [saag] PQC in ZRTP (RFC6189) and hybrid KEM
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Nov 2021 22:24:49 -0000

It would be useful to get review from AVTCORE, if only to (try to) ensure the thinking about post-quantum crypto for SRTP aligns with ZRTP, to the extent possible.

Colin



> On 22 Nov 2021, at 17:28, Johan Pascal <johan.pascal@linphone.org> wrote:
> 
> Hi,
> 
> thanks for your suggestions. I know the work on hybrid design is already done in TLS and others . While looking for some documentation on that specific problem I found several protocols addressing it, each of them with specific details related to the protocol and that is mainly what led me to think that a document dedicated to hybrid scheme might make sense: it would save the next person trying to achieve exactly what I'm trying to do for ZRTP the work of reading the different specifications, parting what is protocol related and what is not. But the hybrid mechanism can be described in the PQC-ZRTP I-D itself.
> 
> Colin, as the problem of updating ZRTP to a PQ-KEM scheme is mostly security related it made more sense to me to post it on Saag. The perfect list to discuss it would be the potential "PQC Agility" WG if it is charted at some point (https://mailarchive.ietf.org/arch/msg/saag/5uV72m80X9PTGFWFyDY5VrNyK-c/ <https://mailarchive.ietf.org/arch/msg/saag/5uV72m80X9PTGFWFyDY5VrNyK-c/>). Is there any update on this?
> 
> Regards,
> 
> Johan
> 
> On 18/11/2021 23:43, Colin Perkins wrote:
>> Hi Johan,
>> 
>> ZRTP was never adopted as a working group item, but the draft was presented several times in the AVT working group. You might get useful feedback from AVTCORE.
>> 
>> Colin
>> 
>> 
>> 
>>> On 16 Nov 2021, at 21:51, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:
>>> 
>>> Hi Johann,
>>> 
>>> As you say, there are some common design questions with any protocol which wants to graft PQ onto DH in a hybrid mode. There is already a fair amount of work in this in TLS (https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>), though it looks less like making ECDH act like a KEM and more often making the KEMs act like ECDH. I'm honestly not sure how much new work there is to do here; over in TLS we're mostly waiting for NIST. I do think it would be helpful to have CFRG or the like specific a PQ algorithm but I'm not sure a generic algorithm describing hybrid will help that much, as opposed to having that last mile be protocol specific
>>> 
>>> Process-wise, the IETF is not maintaining ZRTP, so you would probably need to do an individual submission or send it to the ISE if you want to update it.
>>> 
>>> -Ekr
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Nov 16, 2021 at 1:32 PM Johan Pascal <johan.pascal@linphone.org <mailto:johan.pascal@linphone.org>> wrote:
>>> Dear Saag,
>>> 
>>> on Roman's advice, I post on this list to mention the                           need for an update to ZRTP in order to support Post-Quantum Crytography. RFC6189 was an individual submission and as far as I know no active WG is maintaining this protocol.
>>> 
>>> ZRTP is based on (EC)DH and requires a deep rework to                           support the KEM interface used by the NIST PQ key exchange algorithms. I started working on this topic, my next step would be to submit am I-D updating RFC6189 but I'm far from it so if someone is interested let me know and I can share the preliminary analysis to start a discussion.
>>> 
>>> 
>>> 
>>> Side note: The PQC version of ZRTP should actually use an hybrid key exchange using both (EC)DH and PQ-KEM in parallel. Every protocol using key exchange/encapsulation algorithm and willing to transition toward PQC have to deal with this problem so I think it would be more effective to address it in a specific document that would describe:
>>> 
>>> - how to implement a KEM from X25519/X448 or others (EC)DH algorithms
>>> 
>>> - how to combine the output of two or more KEMs to provide an hybrid one that would be seen from the protocol level (like ZRTP for example) as a single KEM.
>>> 
>>> Some combiners suggestions can be found for example in this publication https://eprint.iacr.org/2018/903.pdf <https://eprint.iacr.org/2018/903.pdf>
>>> The idea would be to avoid repeating the hybrid KEM description in various documents and focus the discussions on that specific matter in one central point.
>>> 
>>> Regards,
>>> 
>>> Johan
>>> 
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org <mailto:saag@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/saag <https://www.ietf.org/mailman/listinfo/saag>
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org <mailto:saag@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/saag <https://www.ietf.org/mailman/listinfo/saag>