Re: [Cfrg] Obligations of Candor

Dan Brown <dbrown@certicom.com> Sun, 15 June 2014 14:39 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 1D3851B285A for <cfrg@ietfa.amsl.com>; Sun, 15 Jun 2014 07:39:51 -0700 (PDT)
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 tXX4MPr-cdBH for <cfrg@ietfa.amsl.com>; Sun, 15 Jun 2014 07:39:49 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4741B2854 for <cfrg@irtf.org>; Sun, 15 Jun 2014 07:39:48 -0700 (PDT)
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 15 Jun 2014 10:39:45 -0400
Received: from XCT116CNC.rim.net (10.65.161.216) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sun, 15 Jun 2014 10:39:45 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Sun, 15 Jun 2014 10:39:44 -0400
From: Dan Brown <dbrown@certicom.com>
To: Watson Ladd <watsonbladd@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Obligations of Candor
Thread-Index: Ac+Ip6WsllSeGQzX7Ui3W4w8gN2tjA==
Date: Sun, 15 Jun 2014 14:39:43 +0000
Message-ID: <20140615143943.6647957.27941.15443@certicom.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============0642679260=="
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/SSLZQU9p6TGEu8vOK2zMuyV6hE0
Subject: Re: [Cfrg] Obligations of Candor
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: Sun, 15 Jun 2014 14:39:51 -0000

Generally, I think that's a good policy, because it adds support to individuals.

I also think it should include guidance on the form of disclosure.

As the Certicom rep in the incident you cited, I recall telling ANSI X9F1 verbally  about the security issue, though I am not sure when.  I had thought my IACR eprint would serve a‎s adequate public disclosure: but that's where guidance may have helped me.

Best regards, 

-- Dan
  Original Message  
From: Watson Ladd
Sent: Sunday, June 15, 2014 9:25 AM
To: cfrg@irtf.org
Subject: [Cfrg] Obligations of Candor

Dear all,

I would like to see an addition to the IETF rules: participants must
fully disclose security issues with the standard they are aware of, in
all standards bodies they participate in, at the time of the Last Call
for a standard. Such disclosure must be to all members of the
committee developing the standard, and, in the event such a security
issue remains post-ratification, public.

This is motivated by the discovery that Certicom, in particular,
patented a backdoor in Dual EC, and proceeded not to tell anyone. No
doubt I have bumbled the above rule: but I would like to start
discussion of what sort of rule we require to ensure that participants
do not horde vulnerabilities, only to exploit them after the standard
is ratified.

Sincerely,
Watson Ladd

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg