Re: [Cfrg] Adoption call for draft-boneh-bls-signature

Dan Brown <danibrown@blackberry.com> Mon, 29 April 2019 18:16 UTC

Return-Path: <danibrown@blackberry.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 19BC7120658 for <cfrg@ietfa.amsl.com>; Mon, 29 Apr 2019 11:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 zkI0fCjfacbd for <cfrg@ietfa.amsl.com>; Mon, 29 Apr 2019 11:16:52 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (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 A9FB5120655 for <cfrg@irtf.org>; Mon, 29 Apr 2019 11:16:52 -0700 (PDT)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2019 14:16:51 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0415.000; Mon, 29 Apr 2019 14:16:50 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Paterson Kenneth <kenny.paterson@inf.ethz.ch>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: Adoption call for draft-boneh-bls-signature
Thread-Index: AQHU/Adg89v6SkyA9UWRRs4G9l5IuqZTcA3Q
Date: Mon, 29 Apr 2019 18:16:50 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501DCEEE2@XMB116CNC.rim.net>
References: <0B1B320B-B358-4796-8822-DDB222204F77@inf.ethz.ch>
In-Reply-To: <0B1B320B-B358-4796-8822-DDB222204F77@inf.ethz.ch>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.251]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_007C_01D4FE96.2F2F8560"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/iZQC06jmlY6f9lT6EjzCAOUAtEM>
Subject: Re: [Cfrg] Adoption call for draft-boneh-bls-signature
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, 29 Apr 2019 18:16:55 -0000

> -----Original Message (abbreviated) -----
> From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Paterson Kenneth
> 
> This email starts a 2-week adoption call for:
> 
> BLS Signature Scheme
> 

I support adoption, but with some minor reservations.

1. A clear-as-possible problem statement is needed. What problem does BLS
solve? How does it add value compared to alternatives?  At the moment, it is
a little unclear to me (see below), but maybe more reading will help me.

2. Aggregation is a feature that does not hold for conventional signatures
(RSA, [E[Cd]]DSA).  Therefore, one has to sure that applications of
signatures do not somehow rely on the non-aggregation feature.   For
example, can I defeat proof-of-possession (PoP) by making an aggregate
signature for an aggregate public key (surreptitiously), without actually
knowing the private key?  If so, then how is this bad?  How advantageous to
me is a small aggregate signature if I need to check the revocation online
for each signer in the set?  In what sense is an aggregate signature
non-repudiable, etc. (and if not at all, then can some non-signature
authentication technology be used instead)? Some conventional signatures
allow batch verification, how much value does aggregation add over batch
verification?

3.  A similar level certification chain compression might be possible using
implicit certificates, which uses more conventional ECC.  If correct, then
two questions are reasonable.  Does BLS adds any extra value in certificate
compression compared to implicit certifcates? Is certificate compression is
important enough for CFRG to adopt implicit certificates?

4. Curves with pairings introduce new assumptions upon which security
relies, and thus new risks.  It is extremely difficult to compare these
risks to the added value of BLS, but such a comparison should be attempted,
at least by making both the upside and downside as clear as possible.

5. A catastrophe affecting most of EC and DL groups is possible, though very
unlikely by now.  Even less likely, is that pairing-base curves are the sole
survivors of such a catastrophe.  The best mitigation against such a
catastrophe seems to be multiple-defense, e.g. RSA+E[Cd]DSA+BLS+[and perhaps
XMSS/LMS] ... signature.  This is costly, but some implementations can
support it, so I would support this application of BLS (and other
pairing-base crypto).

6. An estimate the cost/benefit of using BLS in light of the quantum
computer threat is important here.  (This was discussed a little on another
CFRG thread on a pairing curves draft.)