Re: [CFRG] NSA vs. hybrid

Jeff Burdges <burdges@gnunet.org> Sun, 14 November 2021 21:49 UTC

Return-Path: <burdges@gnunet.org>
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 00CB33A0966 for <cfrg@ietfa.amsl.com>; Sun, 14 Nov 2021 13:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 CnF4cLJUFjDi for <cfrg@ietfa.amsl.com>; Sun, 14 Nov 2021 13:49:34 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430C43A0965 for <cfrg@irtf.org>; Sun, 14 Nov 2021 13:49:33 -0800 (PST)
Received: from mailrelay1.rbg.tum.de (mailrelay1.in.tum.de [131.159.254.14]) by mail-out1.informatik.tu-muenchen.de (Postfix) with ESMTP id 0BC252400AD; Sun, 14 Nov 2021 22:49:31 +0100 (CET)
Received: by mailrelay1.rbg.tum.de (Postfix, from userid 112) id 0941F44B; Sun, 14 Nov 2021 22:49:31 +0100 (CET)
Received: from mailrelay1.rbg.tum.de (localhost [127.0.0.1]) by mailrelay1.rbg.tum.de (Postfix) with ESMTP id 8A8F6449; Sun, 14 Nov 2021 22:49:30 +0100 (CET)
Received: from sam.net.in.tum.de (gnunet.in.tum.de [131.159.74.67]) by mailrelay1.rbg.tum.de (Postfix) with ESMTP id 86E0F194; Sun, 14 Nov 2021 22:49:30 +0100 (CET)
Received: from [127.0.0.1] (sam.net.in.tum.de [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by sam.net.in.tum.de (Postfix) with ESMTP id ED91C1C00D8; Sun, 14 Nov 2021 22:54:11 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Jeff Burdges <burdges@gnunet.org>
In-Reply-To: <20211112120349.636988.qmail@cr.yp.to>
Date: Sun, 14 Nov 2021 22:49:29 +0100
Cc: "D. J. Bernstein" <djb@cr.yp.to>
Content-Transfer-Encoding: quoted-printable
Message-Id: <46B5E229-0BB2-46D7-BFD3-98C10C6105EE@gnunet.org>
References: <20211112120349.636988.qmail@cr.yp.to>
To: CFRG <cfrg@irtf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/99rddFtgh9MwghxeamPrJPhtyO0>
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: Sun, 14 Nov 2021 21:49:39 -0000

I agree with Dan here..  

It should become standard best practices that certificates for relatively young unproven primitives pair them with older proven primitives, and specify a correct hybrid protocol.  There exist exceptions of course, like protocols that intentionally tolerate a lower security level, but default best practice should be exactly what Dan describes.

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.  

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.

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.  

Best,
Jeff