Re: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API

Dan Brown <dbrown@certicom.com> Thu, 20 November 2014 20:12 UTC

Return-Path: <dbrown@certicom.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2890B1AC43D for <cfrg@ietfa.amsl.com>; Thu, 20 Nov 2014 12:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 pRnuTI7g40x8 for <cfrg@ietfa.amsl.com>; Thu, 20 Nov 2014 12:12:18 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id C9D6E1AC3E5 for <cfrg@irtf.org>; Thu, 20 Nov 2014 12:11:38 -0800 (PST)
Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 20 Nov 2014 15:11:33 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0174.001; Thu, 20 Nov 2014 15:11:33 -0500
From: Dan Brown <dbrown@certicom.com>
To: "'hhalpin@w3.org'" <hhalpin@w3.org>
Thread-Topic: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API
Thread-Index: AQHQBNgdANpERMBI5UKMAwsjS8vT9ZxqEFSAgAAX/wD//7xIAA==
Date: Thu, 20 Nov 2014 20:11:32 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5D0433C@XMB116CNC.rim.net>
References: <546E0AE5.3040601@w3.org> <B041D850-2A7D-4B0E-A234-27A4A9D5031B@vpnc.org> <546E31A8.3080909@w3.org>
In-Reply-To: <546E31A8.3080909@w3.org>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.249]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_013E_01D004D4.44829210"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/e3-yakCca9jNqRm3DFbBmEQXCAc
Cc: "'cfrg@irtf.org'" <cfrg@irtf.org>
Subject: Re: [Cfrg] Proposed Informational Note: Security Guidelines for Cryptographic Algorithms in the W3C Web Cryptography API
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Nov 2014 20:12:24 -0000

> -----Original Message-----
> From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Harry Halpin
> 
> We'll just watch the discussions on the preliminary version come in and
revise
> within a week or two unless there is serious disagreement between members
> of CFRG. If theres is more or less agreement, I'll make the edits and then
> formally submit this to be a CFRG edited draft.
> 

I disagree with the "NO" for ECDSA for future use..  The larger reason is
that only alternative signature algorithms in the document are RSA-based,
whereas, by contrast, TLS is moving from RSA to ECC.  The smaller reason is
that ECDSA seems, to me, quite secure for future use if used properly.

I disagree with the rationale against ECDSA about the "weakness" of the
provable security results. Here, I may be biased, being an author of such
works.  

I disagree with the claims regarding Vaudenay's domain parameter attack.
For prime fields: first, as Vaudenay himself writes, the attack is not known
to be effective in the case of prime fields; second, CFRG is now undertaking
a recommendation for new curves.  For binary fields: first, they are being
used much less; second, the usual representations are chosen from a rather
"rigid" list, rather than an arbitrary list as described in the attack.
Specifically, SEC1 defaults a unique representation per field, using
trinomial if possible, else pentanomial, with degrees of the middle terms of
minimized.  For conveying elliptic curve parameters using ASN.1, usually one
just uses an OID which requires the default representation, or alternatively
one can specify the curve details which requires a normal basis, a
trinomial, or a pentanomial.  It seems that ANSI X9.62-2005 now has similar
requirements for the field representations.  Therefore, I think the claim
that the field representation can be chosen maliciously is inconsistent with
the SECG and ANSI standards.

I can elaborate and discuss the points above further, if needed. I believe
that CFRG now has a focus on recommending a new elliptic curve, so I have
tried to be brief here.