Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis

"Derek Atkins" <derek@ihtfp.com> Mon, 27 June 2016 16:56 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BE812D82C for <openpgp@ietfa.amsl.com>; Mon, 27 Jun 2016 09:56:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 Lo3CsNxnbqRD for <openpgp@ietfa.amsl.com>; Mon, 27 Jun 2016 09:56:08 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECE212D858 for <openpgp@ietf.org>; Mon, 27 Jun 2016 09:56:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 03220E203F; Mon, 27 Jun 2016 12:55:35 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 21076-09; Mon, 27 Jun 2016 12:55:32 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 414AFE2040; Mon, 27 Jun 2016 12:55:32 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1467046532; bh=+WllKt3u0KYRYa2CBQUGqXsiXlYNlFM+Y2/od+nWhSA=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=dESuRcub8t2xU0Nl4R2W/mHUd4cWOMtdRqBUCMFLv2VYNrBhJ5/wdscwoQaCNjZ9z Hh/tTOQ0xTHuMLaBEyZMp9hRrPxLhpVfucqB4S95a6t0J27uTGGDoLNzWmuui7+F9f 5xMhH/+SPhL3xp1nMYp+QA9kxdYehjeyy6hRQFzc=
Received: from 192.168.248.159 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 27 Jun 2016 12:55:32 -0400
Message-ID: <899ea0af118daae68588bd79af729c72.squirrel@mail2.ihtfp.org>
In-Reply-To: <8b0200bf-16a9-76e6-71e7-b2fe445257d2@sumptuouscapital.com>
References: <878txtjnf6.fsf@alice.fifthhorseman.net> <sjmeg7ivbuu.fsf@securerf.ihtfp.org> <8b0200bf-16a9-76e6-71e7-b2fe445257d2@sumptuouscapital.com>
Date: Mon, 27 Jun 2016 12:55:32 -0400
From: Derek Atkins <derek@ihtfp.com>
To: Kristian Fiskerstrand <kristian.fiskerstrand@sumptuouscapital.com>
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/riCPpZ_vzFB5Hdoet4y6PsLiHm0>
Cc: IETF OpenPGP <openpgp@ietf.org>
Subject: Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2016 16:56:10 -0000

Hi,

On Mon, June 27, 2016 12:45 pm, Kristian Fiskerstrand wrote:
> On 06/27/2016 06:24 PM, Derek Atkins wrote:
>> Hi,
>>
>> I'm in favor of accepting this.
>>
>> I'll also point out that I had made another suggested update on April 14
>> (Subject: Proposed Patch to RFC4880bis to reserve two public key
>> numbers) which has not been incorporated into the document.
>
> There seems to be a lot of doubt about the security of Algebraic Eraser
> protocols (at least controversy) and little research compared to other
> key exchange methods,  without much gain from implementing it. What
> would be the rationale for adding it?

Then don't implement it.  I'm not asking for it to be mandatory to
implement, so if you don't trust it for some reason then you can choose
not to accept it.

The rationale for adding it is that it MAY be used by implementations who
want/need it.  If that happens to be only a single implementation (ours)
then so be it.

I'd pose the question in the opposite direction:  what HARM is there in
adding it to the list of known algorithms?

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant