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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 25 Jun 2016 11:30:53 -0400

hey OpenPGP folks--

We've had a slow start on 4880bis, but i'm hoping we can get things
moving again.  One of the things we need to do bureaucratically is to
officially adopt a specific draft as the basis of our ongoing work.

Werner Koch has prepared and submitted the beginnings of the new
revision of RFC 4880, the current version of which you can see here:

   https://tools.ietf.org/html/draft-koch-openpgp-rfc4880bis-02

This is a call for adoption of this draft by the OpenPGP WG.  Please
speak up soon if you have any concerns, or if you think this document
should not be adopted by the WG for some reason.  Please also speak up
if you are in favor of adoption.

A brief reminder of what adoption by the WG would mean:

 * this draft would become the *starting point* for RFC 4880bis; the
   draft is currently not complete, but it would be the basis upon which
   the group would build the new proposal.

 * Werner Koch would be the document editor, but the decisions about the
   draft would be made by the working group.  I want to thank Werner for
   his willingness to put in his time as the document editor.

 * Since our charter (https://datatracker.ietf.org/wg/openpgp/charter/)
   is aimed primarily at making a revision to RFC 4880, we would
   hopefully focus our efforts on contributing review and amendments to
   this draft, with a goal of driving it to IETF Last Call within the
   year.

Please give feedback on draft adoption!

   --dkg

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Sat, 25 Jun 2016 17:42:10 +0200

> if you are in favor of adoption.

I'm in favor of adopting this document as a starting point for the WG.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP certificate at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Nomina stultorum scribuntur ubique locorum
Fools have the habit of writing their names everywhere

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Sat, 25 Jun 2016 12:52:10 -0400

also in favor

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Tom Ritter <[email-masked]>
Date: Sun, 26 Jun 2016 21:32:49 -0500

+1

On 25 June 2016 at 11:52, Joseph Lorenzo Hall <[email-masked]> wrote:
> also in favor
>
>
> On Saturday, June 25, 2016, Kristian Fiskerstrand
> <[email-masked]> wrote:
>>
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Derek Atkins <[email-masked]>
Date: Mon, 27 Jun 2016 12:24:25 -0400

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.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Mon, 27 Jun 2016 18:45:39 +0200

> 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?

Aurum est Potestas
Gold is power

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 27 Jun 2016 12:55:32 -0400

Hi,

> 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

---

From: Jon Callas <[email-masked]>
Date: Mon, 27 Jun 2016 09:59:15 -0700

+1

Sounds great to me.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Mon, 27 Jun 2016 10:41:35 -0700

> On Jun 27, 2016, at 9:45 AM, Kristian Fiskerstrand <[email-masked]> wrote:
> 

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.

	Jon

---

From: "Robert J. Hansen" <[email-masked]>
Date: Mon, 27 Jun 2016 15:35:38 -0400

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

[de-lurks]

Jon, it seems like you're saying "since this is a purely normative
document we can be as extensive as we want, and there are good reasons
for purely normative documents to be extensive."

The presence of an algorithm in the spec tends to create pressure on
implementations to support that algorithm.  When RFC2440 had reserved
entries for TIGER192, there was a small but vocal crowd in the GnuPG
community crying out, "we need TIGER192, it's in the spec!"  And as soon
as TIGER192 was removed, those voices died out -- because hey, it's no
longer in the spec.

I am completely and vigorously in favor of OpenPGP retaining the ability
to be agile with respect to algorithms.  (In fact, I'd like to see more
work go into this.)  But with respect to adding new reserved numbers,
due to the tendency of users to see the spec as prescriptive rather than
normative, I'd like to see us be more conservative.

Also, on a somewhat tangential note -- for more than twenty years we've
been talking off and on about a prescriptive OpenPGP RFC, one that would
focus on what was a good idea as opposed to what was strictly legal.
We've never done it.  I'd like to see that change.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Jun 2016 19:39:57 +0000

> community crying out, "we need TIGER192, it's in the spec!"  And as soon as
> TIGER192 was removed, those voices died out -- because hey, it's no longer
> in the spec.

Separating maintenance of the registry from the spec should address this, right?

---

From: Jon Callas <[email-masked]>
Date: Mon, 27 Jun 2016 15:20:07 -0700

> On Jun 27, 2016, at 12:35 PM, Robert J. Hansen <[email-masked]> wrote:
> 

Well, no, that's not what I'm saying.

It seems to me that you're setting up a straw man. I realize you're probably not, but that's what I'm saying.

What I am saying is that in this *specific* case, the risks of adding it are low.

I recognize that options are good and options are bad. There's a cost to options, but there's a cost to not having them.

> as TIGER192 was removed, those voices died out -- because hey, it's no

I think I disagree, because one of the reasons Tiger and others were removed is that they essentially weren't being used.

But -- let me just concede the point. We made a mistake in removing Tiger, then. We removed it because there was no constituency. If there *was* a constituency and we didn't realize it, we made a mistake. 

However, let me address your larger point, the "pressure" to support an algorithm.

In 2440/4880 there were two reference implementations, PGP and GnuPG. For better or worse, PGP did not implement Blowfish (actually, it's more complex than that -- PGP would *decrypt* a message encrypted with Blowfish because some versions of GnuPG didn't do cipher negotiation properly, but it wasn't offered as a choice and never encrypted to it). It didn't implement SAFER nor DES/SK. It did not implement Elgamal signatures. It didn't implement Tiger nor Haval nor MD2. 

GnuPG took the admirable stand of implementing everything in the standard, but still didn't implement RSA until the patents expired. (But that is also something that's more complex than the simple preceding sentence.)

I know that today, there are a number of implementations that don't do Camellia. 

You are absolutely right that in some places implementers just go and implement whatever. The OpenPGP community hasn't ever been one of those places, it's been a raucous group of people with definite opinions and tastes. That has never been a problem here. OpenPGP is designed so that people can go play in their own sandbox with no detriment to the people who don't want to play.

Rich Salz brought up a great suggestion -- put the identifier registry outside the main document, which would help as well. That takes pressure off of the casual reader.

> We've never done it.  I'd like to see that change.

Okay. That gets to the core of it. If the standard is prescriptive with everything as MUST, then sure, you have to be difficult about what you allow.

If you don't want AE because it's an impediment to a prescriptive, that's a different discussion. We should have the discussion of a prescriptive standard on its own.

	Jon

---

From: Barry Leiba <[email-masked]>
Date: Tue, 28 Jun 2016 04:18:44 -0400

Folks, if you want to discuss the document itself, please change the
subject line appropriately, to start a new thread.  Please leave this
thread for comments about using this draft as the starting point for
the work.

Barry, as chair

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Jun 2016 04:20:13 -0400 (EDT)

> To: [email-masked]
> Subject: Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis

+1 for adoption.

Paul

---

From: Bill Frantz <[email-masked]>
Date: Wed, 29 Jun 2016 16:04:40 -0700

+1 for adoption.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | If you want total security, go to prison. There you're
408-356-8506       | fed, clothed, given medical care and so on. The only
www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower

---

From: David Shaw <[email-masked]>
Date: Wed, 29 Jun 2016 23:19:19 -0400

> if you are in favor of adoption.

I am in favor of adopting this draft.

David

---

From: Levi <[email-masked]>
Date: Thu, 30 Jun 2016 03:46:20 +0000

+1 :)

---

From: Dominik Schuermann <[email-masked]>
Date: Thu, 30 Jun 2016 09:31:47 +0200

+1 for adoption

Cheers
Dominik

---

From: James Cloos <[email-masked]>
Date: Thu, 30 Jun 2016 20:24:59 -0400

I haven't seen any objections, so we probably have consensus already.
Nonetheless, +1 for adoption.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6