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

Jon Callas <> Mon, 27 June 2016 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E158012D62C for <>; Mon, 27 Jun 2016 10:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XYXA2B_RqZFz for <>; Mon, 27 Jun 2016 10:41:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F6CF12D0E4 for <>; Mon, 27 Jun 2016 10:41:39 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Sep 8 2015)) id <> for; Mon, 27 Jun 2016 17:41:38 +0000 (GMT)
Received: from [] ( []) by (Oracle Communications Messaging Server 64bit (built Sep 8 2015)) with ESMTPSA id <>; Mon, 27 Jun 2016 17:41:38 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-27_12:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1606270181
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jon Callas <>
In-reply-to: <>
Date: Mon, 27 Jun 2016 10:41:35 -0700
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <> <>
To: Kristian Fiskerstrand <>
X-Mailer: Apple Mail (2.3124)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=4d515a; t=1467049298; bh=g0XGGveAYp1Bri8hZSke8277Y+6sNHbiD99rCyWs03k=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=nnYp4yXFMI4ZG9r+uAQbx+LNCd3CvRnsGa8n/qgi1nhDRgtLkMCd/i8R5HjaGQutM dXip8YZjuPZQ7BFmyDzBtkY3dwCx+2FGmo+bYn9voWlC6hXfj+cyfMNHmozc4QFjjM 0uq2TZxuUnWxvFkFN68Rl8rsHJIg5tHhOwy82tSuerDh+nazeEM0MrKxmJPwvB5WEg ElTs1zIp9iRi5wpU+LAxSghRWjJnSg31YGvZmm7FvO2r87B9A3g8lc1h5feZvYBtlh tkjfFFEIomqs3kkVq7PhK+12cdwRdU9hHWLnrOJGpeCGEVsI+vkLffjUdL04FaFuHH m7j2/gS1ea2Ew==
Archived-At: <>
Cc: IETF OpenPGP <>, Derek Atkins <>, Jon Callas <>
Subject: Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2016 17:41:41 -0000

> On Jun 27, 2016, at 9:45 AM, Kristian Fiskerstrand <> wrote:
> 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?

Let me give two answers -- one a crypto answer and the other a standards answer.

Crypto-wise, Algebraic Eraser is a bit out there, but the issues with it are far more issues with the ways it can be used badly than fundamental ways it is horrible. Every major crypto mechanism we have, particularly public-key ones, has major failure modes -- encoding and padding, parameter selection, and many of those are nuanced as well. (Like using an RSA exponent of 3, which you can do either wrong or right.) It is outre in some ways, but it's also fascinating and useful.

Standards-wise, to quote Jeff Schiller from long ago, the purpose of a standard is interoperability. A standard exists so that you know what an object *means*, so you can quickly accept things you like and reject things you don't like. Ironically, if you don't like Algebraic Eraser, you *want* it to get an identifier so you can quickly reject its use in an implementation.

Yes, on the one hand, you don't want your standard to be cluttered, but on the other hand you want to encourage its use. You can give pejorative terms to either side of it, but I think it's worse for a standard to be overly-restrictive than overly-inclusive. 

Traditionally in OpenPGP, we've gone towards being inclusive because we didn't want people to either (1) just grab an identifier in the experimental/private region or out in IANA space or (2) go use some other standard where all they need is an OID.

We've put in identifiers for controversial hash functions, Elgamal signatures, X9.42 DH, symmetric crypto, and in many cases gone and removed them later. Look at the differences between section 9 of 2440 and section 9 of 4880. It's an interesting commentary on where thought was in 1998 and 2007.

Moreover, we survived! Nothing bad happened. We learned that OpenPGP is amazingly resilient to the downsides of being inclusive. The worst issue we had to deal with was Elgamal signatures -- controversial from the start, tetchy to use, and there were flawed implementations. But it ended up being retired because its proponents moved on.

There is little risk to giving Derek what he wants. It's just an identifier. In fact, the biggest risk in my opinion is that we tell him no, he goes off and is successful using X.509.