Re: [CFRG] NSA vs. hybrid

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 15 November 2021 16:14 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2134C3A0E14 for <cfrg@ietfa.amsl.com>; Mon, 15 Nov 2021 08:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 K0QsJD7MgLyE for <cfrg@ietfa.amsl.com>; Mon, 15 Nov 2021 08:14:31 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1A43A0E0F for <cfrg@irtf.org>; Mon, 15 Nov 2021 08:14:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B6BC867ACF for <cfrg@irtf.org>; Mon, 15 Nov 2021 18:14:27 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id BkxyawsxOwZD for <cfrg@irtf.org>; Mon, 15 Nov 2021 18:14:27 +0200 (EET)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 8B3F02320 for <cfrg@irtf.org>; Mon, 15 Nov 2021 18:14:26 +0200 (EET)
Date: Mon, 15 Nov 2021 18:14:25 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: CFRG <cfrg@irtf.org>
Message-ID: <YZKHYWJgJHNtLsuG@LK-Perkele-VII2.locald>
References: <20211112120349.636988.qmail@cr.yp.to> <46B5E229-0BB2-46D7-BFD3-98C10C6105EE@gnunet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <46B5E229-0BB2-46D7-BFD3-98C10C6105EE@gnunet.org>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/vtX7sVXJPb0mB2hUcrPc7G4tTgU>
Subject: Re: [CFRG] NSA vs. hybrid
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 16:14:33 -0000

On Sun, Nov 14, 2021 at 10:49:29PM +0100, Jeff Burdges wrote:
> 
> It’s always possible logic bugs arise in validation code of course,
> but test vectors can trivially catch these bugs, assuming the
> certificate format specifies both key types and the hybrid protocol.

Catching those bugs may be far from trivial. Buggy signature
verification code might have false accepts that are not trivial to
generate, but still greatly weaken the security. One can not
catch those with test vectors.

I have not looked at if there are easy-to-make mistakes in
signature verification of NISTPQC candidates that would behave in
that way (not be obviously broken but still exploitable).

> It’s fairly clear separate P and Q certificate chains obstruct test
> vectors from enforcing this and invite more opportunities for
> downgrade attacks, etc. too.

IMO, The complexity of separate P and Q chain verification is
absolutely terrifying. As for downgrade attacks, it is not clear how to
deal with that even in theory, let alone in practice.

> It’s all trickier if you want the extreme algorithm agility of TLS of
> course, but not any harder than making separate P and Q certificate
> chains work correctly.  

Actually, separate chains do not work in TLS. The problem is that
there can be only one handshake signature and only one end entity
certificate, and thus only one CA signature for end-entity
certificate. 


-Ilari