IETF Logo Mail Archive

Re: [lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 23 April 2022 17:06 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7E53A1821 for <spasm@ietfa.amsl.com>; Sat, 23 Apr 2022 10:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 YTm84Ai3oigS for <spasm@ietfa.amsl.com>; Sat, 23 Apr 2022 10:06:19 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2593A181F for <spasm@ietf.org>; Sat, 23 Apr 2022 10:06:18 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [75.98.19.153]) by relay.sandelman.ca (Postfix) with ESMTPS id E168C1F456 for <spasm@ietf.org>; Sat, 23 Apr 2022 17:06:15 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 0D6BE1A0291; Sat, 23 Apr 2022 13:06:13 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: LAMPS <spasm@ietf.org>
In-reply-to: <DM6PR11MB38025338B4FA3AED0AA99E3196F79@DM6PR11MB3802.namprd11.prod.outlook.com>
References: <f2fb2b2459fe42818348838eb14cc2ac@EX13D01ANC003.ant.amazon.com> <29E39FB1-D8E5-40E9-AFC0-5A8EBBB705DF@vigilsec.com> <DM6PR11MB38025338B4FA3AED0AA99E3196F79@DM6PR11MB3802.namprd11.prod.outlook.com>
Comments: In-reply-to Serge Mister <Serge.Mister=40entrust.com@dmarc.ietf.org> message dated "Fri, 22 Apr 2022 18:23:41 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 23 Apr 2022 13:06:13 -0400
Message-ID: <1312783.1650733573@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/14Z-d_mDdlFp6RSHbXzCih5cijo>
Subject: Re: [lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2022 17:06:23 -0000

Serge Mister <Serge.Mister=40entrust.com@dmarc.ietf.org> wrote:
    > As I mentioned on the call, I'm not fully convinced that deciding which
    > signatures a relying party must verify is entirely a decision for the
    > relying party.  When an entity obtains a certificate from a CA,
    > signatures verifiable with the certificate are attributed to the entity
    > named in the certificate.  The certificate holder then wouldn't want a
    > weak key bound to their identity.  If a composite key can be used in
    > "OR" mode, the key is weakened when any of the algorithms is weakened.

Yeah, but we need this OR mode to operationally be able to deploy.

Yes, it true it could be subject to a bid-down attack against the weaker
algorithm.  But, this is where the verify policy does matter.  Bid-down
attacks only work when both parties have open policies.
Until there is there is a clear attack, there isn't a weak algorithm.
But, when an attack becomes known, verifies have to change their policies.

Without the OR mechanism, we wind up with a flag day where all signers and
all verifiers have to upgrade within a renewal/CRL-signing epoch.  That's
just not practical.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email