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

Benjamin Kaduk <kaduk@mit.edu> Tue, 23 November 2021 06:27 UTC

Return-Path: <kaduk@mit.edu>
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 99FA93A07E0 for <saag@ietfa.amsl.com>; Mon, 22 Nov 2021 22:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 27q39niqfGpU for <saag@ietfa.amsl.com>; Mon, 22 Nov 2021 22:27:19 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 40A053A07DD for <saag@ietf.org>; Mon, 22 Nov 2021 22:27:19 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1AN6RCUp024963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 01:27:16 -0500
Date: Mon, 22 Nov 2021 22:27:12 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Johan Pascal <johan.pascal@linphone.org>, IETF SAAG <saag@ietf.org>
Message-ID: <20211123062712.GB93060@kduck.mit.edu>
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> <CABcZeBNb4qEJscEHb44PjrHEQKs08R6vCZfFM0HWk67OLMZykA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBNb4qEJscEHb44PjrHEQKs08R6vCZfFM0HWk67OLMZykA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/AYh9ZUqXN3doVOH4bdJDEK_5la4>
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: Tue, 23 Nov 2021 06:27:25 -0000

On Mon, Nov 22, 2021 at 09:47:46PM -0800, Eric Rescorla wrote:
> On Mon, Nov 22, 2021 at 9:28 AM 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/).
> > Is there any update on this?
> >
> Well, discuss it, perhaps, but given that ZRTP is not an IETF protocol, we
> generally would not publish this document out of that group.

Sorry for splitting hairs, but RFC 6189 does have the "represents the
consensus of the IETF community" boilerplate, that would seem to  make it
an IETF protocol by at least some definitions.

-Ben