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

"Kampanakis, Panos" <kpanos@amazon.com> Sun, 24 April 2022 01:48 UTC

Return-Path: <prvs=1065e48d6=kpanos@amazon.com>
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 082013A11C2 for <spasm@ietfa.amsl.com>; Sat, 23 Apr 2022 18:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.609
X-Spam-Level:
X-Spam-Status: No, score=-9.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
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 WkzHdoRw84xg for <spasm@ietfa.amsl.com>; Sat, 23 Apr 2022 18:48:21 -0700 (PDT)
Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 258573A11BD for <spasm@ietf.org>; Sat, 23 Apr 2022 18:48:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1650764901; x=1682300901; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=fT+48YBmDd3uLk5Hi2bapQvbFwLV1yPgtW4jtnpPwhc=; b=Y+uu8u5EXyYKD33gSdXbmS4NjOWMxg3J9/0t7D5Yw4CExmj2u/wtlynI Khtv59vg2VgCQJAoSKBTf5gGE+o7130xiS5BN+eCylZRlxOzIhRkfvpIs T8zbz6eOR4V9nx3rSZD3u98wZJ4z/wU81U97kIs05fqc8TFOiKoJKum7K U=;
X-IronPort-AV: E=Sophos;i="5.90,285,1643673600"; d="scan'208";a="190539321"
Thread-Topic: [lamps] Re: PQ-composite OR or K-of-N logic
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-iad-1d-9a235a16.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-33001.sea14.amazon.com with ESMTP; 24 Apr 2022 01:48:05 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1d-9a235a16.us-east-1.amazon.com (Postfix) with ESMTPS id 7278181484; Sun, 24 Apr 2022 01:48:04 +0000 (UTC)
Received: from EX13D01ANC002.ant.amazon.com (10.43.157.162) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Sun, 24 Apr 2022 01:48:03 +0000
Received: from EX13D01ANC003.ant.amazon.com (10.43.157.68) by EX13D01ANC002.ant.amazon.com (10.43.157.162) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Sun, 24 Apr 2022 01:48:02 +0000
Received: from EX13D01ANC003.ant.amazon.com ([10.43.157.68]) by EX13D01ANC003.ant.amazon.com ([10.43.157.68]) with mapi id 15.00.1497.033; Sun, 24 Apr 2022 01:48:02 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, LAMPS <spasm@ietf.org>
Thread-Index: AQHYVzSc6Z1FPQA7gUmVWY35xrznTKz+SxOw
Date: Sun, 24 Apr 2022 01:48:02 +0000
Message-ID: <423419504256427b83c889f9b5c607b7@EX13D01ANC003.ant.amazon.com>
References: <f2fb2b2459fe42818348838eb14cc2ac@EX13D01ANC003.ant.amazon.com> <29E39FB1-D8E5-40E9-AFC0-5A8EBBB705DF@vigilsec.com> <DM6PR11MB38025338B4FA3AED0AA99E3196F79@DM6PR11MB3802.namprd11.prod.outlook.com> <1312783.1650733573@dooku>
In-Reply-To: <1312783.1650733573@dooku>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.157.194]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/YQYrZZkoJ4h2madVaXePmDWsBns>
Subject: Re: [lamps] 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: Sun, 24 Apr 2022 01:48:26 -0000

Hi Michael, 

Both OR or AND are not backwards compatible. The new OID (regardless of OR or AND logic) will not be understood by verifiers that have not been upgraded. Not to mention that verifiers that don't understand composite will not want to see the extra data which could slow down their communications. 

The only way to avoid a flag day is to negotiate; if the verifier understands the composite signature give it to it, otherwise just give the classical. 







-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Saturday, April 23, 2022 1:06 PM
To: LAMPS <spasm@ietf.org>
Subject: RE: [EXTERNAL][lamps] [EXTERNAL] Re: PQ-composite OR or K-of-N logic

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



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 =-