Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers

From: Derek Atkins <[email-masked]>
Date: Wed, 06 Jul 2016 19:36:28 -0400

Hi,

Now that we've accepted the draft, I'd like to re-open this proposal to
reserve two public-key algorithm protocol numbers.  Note (again) that
this is *JUST A RESERVATION* of these numbers, and if you read the patch
and still think that you *have* to implement these algorithms then I'd
like to hear your wording suggestion for how to fix that misconception.

I've re-attached this patch (although I haven't rebased it).  My
original message is included below.

Thanks,

-derek

> Hi,
>
> The attached patch to RFC4880bis reserves two public-key parameters.
> They are specified as "reserved" and I've added text to 13.8 as well
> documenting that they are underspecified.
>
> Note that these are NOT "MTI" algorithms in any way, shape, or form!
>
> Thanks,
>
> -derek

>From b2ffaf54bac27ed59a836e0588cfed8d0097d584 Mon Sep 17 00:00:00 2001
From: Derek Atkins <[email-masked]>
Date: Thu, 14 Apr 2016 16:06:49 -0400
Subject: [PATCH] Add AEDH and AEDSA protocol number reservations

---
 middle.mkd | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/middle.mkd b/middle.mkd
index 033f11f..0fa9efd 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -2890,6 +2890,8 @@ algorithms.
        21  Reserved for Diffie-Hellman
                       (X9.42, as defined for IETF-S/MIME)
        22  EdDSA  [](#I-D.irtf-cfrg-eddsa)
+       23  Reserved for AEDH
+       24  Reserved for AEDSA
  100--110  Private/Experimental algorithm
 
 Implementations MUST implement DSA and ECDSA for signatures, and
@@ -3182,6 +3184,8 @@ This document requests IANA register the following public-key algorithm:
    ID    Algorithm                   Reference
    --    --------------------------  ---------
    22    EdDSA public key algorithm  This doc
+   23    Reserved for AEDH           This doc
+   24    Reserved for AEDSA          This doc
 
    [Notes to RFC-Editor: Please remove the table above on publication.
     It is desirable not to reuse old or reserved algorithms because
@@ -3950,7 +3954,9 @@ algorithm.  These are marked in Section 9.1, "Public-Key Algorithms",
 as "reserved for".
 
 The reserved public-key algorithm X9.42 (21) does not have the
-necessary parameters, parameter order, or semantics defined.
+necessary parameters, parameter order, or semantics defined.  The same
+is currently true for reserved public-key algorithms AEDH (23) and
+AEDSA (24).
 
 Previous versions of OpenPGP permitted Elgamal [](#ELGAMAL) signatures
 with a public-key identifier of 20.  These are no longer permitted.  An
-- 
2.5.0

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

---

From: Werner Koch <[email-masked]>
Date: Thu, 07 Jul 2016 08:24:18 +0200

> reserve two public-key algorithm protocol numbers.  Note (again) that

I opened an issue to track this proposal:
 https://gitlab.com/openpgp-wg/rfc4880bis/issues/1

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Jul 2016 10:23:37 +0100

Hiya,

>  https://gitlab.com/openpgp-wg/rfc4880bis/issues/1

I forget if this cfrg posting [1] on AE was made visible here
or not. Apologies if this is repetitive but that posting from
Kenny Paterson on 20151113 seems quite relevant as it says:

"
My colleague Simon Blackburn and his collaborators have just
published an attack on the Algebraic Eraser scheme, breaking the
scheme at the designers' claimed 128-bit security level. Their
attack recovers the shared key using 8 CPU hours and 64MB of
memory. Their paper is here:

   http://arxiv.org/abs/1511.03870
"

With no hats, I'd be against adding an algorithm, even as an
option, if there are current serious questions about it's real
security level. I do get the arguments for and against, but in
such cases am against adding codepoints where there is no way
to flag the codepoint as "likely dangerous" or some other
similarly negative/scary warning. And while it's good to go to
the effort to deprecate old codepoints that are now likely
dangerous, I don't see that it's a good idea to add new ones
"born" in that state.

But maybe there's an update on the state of cryptanalysis of
AE? If so, I guess posting to cfrg and then reflecting that
back here might be best, as the cfrg list has folks who're
better qualified to argue those merits. As far as I can see
there was no follow-up to [1] on the cfrg list, but I might
have missed it. There does seem to have been an update to
the paper on arxiv last month, but I didn't check to see what
changed - the abstract still claims the break anyway.

Putting my AD hat back on: if the WG do reach consensus to
add such codepoints, then when it comes time to publish, I'll
be looking back to the list to ensure that consensus was very
clear on the list. For the AE ones, that's clearly happening
via this thread which is fine process-wise, assuming more folks
opine and the chairs declare consensus. I'm just noting that
so we ensure the same clarify if there are other similarly
contentious codepoint requests in order to avoid having to
revisit stuff at publication time.

S.

[1] https://www.ietf.org/mail-archive/web/cfrg/current/msg07609.html

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 7 Jul 2016 07:21:28 -0400

Hi,

On Thu, July 7, 2016 5:23 am, Stephen Farrell wrote:
[snip]
>    http://arxiv.org/abs/1511.03870

And there was a paper published in response to this:

http://arxiv.org/abs/1601.04780

> dangerous, I don't see that it's a good idea to add new ones

Note again that it's just reserving the number; it's completely
underspecified.

[snip]

> revisit stuff at publication time.

Frankly, we are already using code point 23 in production. I grabbed that
point years ago when I wrote the original I-D and posted it here (in
coordination with Werner, who grabbed 22 for EdDSA), well before this WG
reopened.  I doubt there will be a large contingent looking to implement
it, which is fine.  But I'd like to make sure nobody else uses that code
point.

-derek

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Jul 2016 12:33:22 +0100

Hi Derek,

> http://arxiv.org/abs/1601.04780

The discussion of the relative merits of those would be better
on cfrg. (I don't recall the latter having been posted there
for example, but I do recall hearing about/seeing it before
somewhere.)

> Note again that it's just reserving the number; it's completely

The patch mentioned AE methods explicitly. Allocating codepoints
for underspecified algorithms would seem pretty odd.

> it, which is fine.  But I'd like to make sure nobody else uses that code

So I've no clue how this WG or the openpgp community regard
squatting but if codepoints aren't scarce marking some as
reserved could be an option. (FWIW, I'm not fussed about doing
such things if codepoints aren't scarce.)

Marking some codepoints as being reserved for an undespecified
algorithm with an uncertain strength however is not something
I'd support.

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jul 2016 11:49:45 +0000

I am in favor of the reservation, but would like to see all IANA registry stuff in a separate document.

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 7 Jul 2016 08:33:45 -0400

Hi Stephen,

[snip]
> for example, but I do recall hearing about/seeing it before

You brought up a paper showing a weak key/keyset and said there was no
response, I pointed out a response.  I wasn't trying to discuss relative
merits and agree this is not the place to do so.  But you started it ;)

[snip]
> for underspecified algorithms would seem pretty odd.

There are other "reserved for.." code points.  And there are other
"underspecified" code points, too.  So there is already precedent.  C.f.
X9.42 (code point 21).
[snip]
> such things if codepoints aren't scarce.)

It's an 8-bit field.  There are currently 21 allocated, with #22 in line
for EdDSA, and me asking for 23 and 24.  So still under 10% utilized.  I'm
not sure if you consider this scarce or not.  I don't; I don't expect
there to be a ton of new public key algorithms out there.  Even if we
expect another two dozen in the *next* 30 years, that would still put us
only to 20% utilized.

-derek

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Jul 2016 13:43:24 +0100

> merits and agree this is not the place to do so.  But you started it ;)

Well, no - 'twas you guys started proposing AE I think:-)

Seriously though, if you're interested in AE being used
in Internet protocols, the cfrg list is the place to do
that I'd say, and at present the BBT paper is what's in
that archive uncontested. Up to you though of course.

S.

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 7 Jul 2016 10:09:00 -0400

> Well, no - 'twas you guys started proposing AE I think:-)

No, I just asked to reserve some code points.  I suppose I could have
called them "Fred" and "George" if that makes you feel any better?  But
back to the technical side of things:

I chose OpenPGP because I feel it is the better fit for our company use
cases.  I had a lot of pushback at the time about why not use X.509? 
Indeed, looking back X.509 would have certainly been an easier route to
take; we just need an OID (gee, that was easy to acquire) and plug it in
and we're done.  But the arguments against X.509 (data size, code size,
strictness, etc) outweighed what I believed to be the "battle" of
obtaining OpenPGP code points.

Frankly, given the history of OpenPGP I thought it would be pretty easy. 
There's historically been very little pushback -- someone wants to get a
code point for their use, okay, let's give it to them.  This way everyone
else, when they see a message, knows *what* it is (even if they can't
actually decode it).

So yeah, mea culpa for bringing in the AE baggage.  Let's call them Fred
and George and move on?  Or do you have something against the Fred and
George algorithms having code points?  ;-)  Seriously, though, let me ask
you the same question that was posed the other week:  what is the *harm*
in defining these code points in the registry?  There is no harm in
thinking someone might use it unknowingly, because that's technically not
feasible.  There's no harm in someone being able to decipher a packet and
know "oh, this is a Fred packet".  Now, what is the harm of NOT defining
these in the registry?  Well, there is the possibility that down the road
it might get re-defined and used by some other algorihtm and now there are
two different things in the wild.  (c.f. historical openness of accepting
code point requests).

So let's look at this from a protocol/registry standpoint and not a
cryptographic standpoint, since that's what this request is really about.

Thanks,

-derek

---

From: Jon Callas <[email-masked]>
Date: Thu, 07 Jul 2016 12:08:27 -0700

> On Jul 7, 2016, at 4:49 AM, Salz, Rich <[email-masked]> wrote:
> 

I concur with Rich.

As most people know, I am an inclusivist in these matters. OpenPGP has as one of its implicit design goals the ability to support communities within the user base who have radically different opinions about algorithms. It's been a key feature of OpenPGP.

That the registry is in the document is an artifact of the way that we did things back in the 1900s. I think it makes sense to allow for more agility.

	Jon