Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt

From: [email-masked]
Date: Mon, 07 Aug 2017 07:11:16 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the CURves, Deprecating and a Little more Encryption WG of the IETF.

        Title           : Ed25519 public key algorithm for the Secure Shell (SSH) protocol
        Authors         : Ben Harris
                          Loganaden Velvindron
	Filename        : draft-ietf-curdle-ssh-ed25519-01.txt
	Pages           : 5
	Date            : 2017-08-06

Abstract:
   This document describes the use of the Ed25519 digital signature
   algorithm in the Secure Shell (SSH) protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ed25519/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-01
https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ed25519-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ed25519-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Aug 2017 12:29:00 -0400

Hi,

Thank you for updating the draft. I am wondering if there are any reason
for not having ed448 in the draft, and if not I would suggest we extend the
draft to ed448 as well.

Yours,
Daniel

On Mon, Aug 7, 2017 at 10:11 AM, <[email-masked]> wrote:

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 11 Aug 2017 07:33:56 +0400

On Mon, Aug 7, 2017 at 8:29 PM, Daniel Migault
<[email-masked]> wrote:
> Hi,
>
> Thank you for updating the draft. I am wondering if there are any reason for
> not having ed448 in the draft, and if not I would suggest we extend the
> draft to ed448 as well.
>

Dear Daniel,

ED448 is not currently a target for implementations like OpenSSH.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 11 Aug 2017 13:07:46 +0000

Are there any reasons that would prevent us to specify it ? This would document how to implement it on Openssh or other implementation. 
Yours, 
Daniel

-----Original Message-----
From: Loganaden Velvindron [mailto:[email-masked]] 
Sent: Thursday, August 10, 2017 11:34 PM
To: Daniel Migault <[email-masked]>
Cc: curdle <[email-masked]>
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt

On Mon, Aug 7, 2017 at 8:29 PM, Daniel Migault <[email-masked]> wrote:
> Hi,
>
> Thank you for updating the draft. I am wondering if there are any 
> reason for not having ed448 in the draft, and if not I would suggest 
> we extend the draft to ed448 as well.
>

Dear Daniel,

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 11 Aug 2017 09:02:25 -0700

Hi Daniel & Loganaden,

I see no reason not to specify ed448. The draft-ietf-curdle-ssh-curves-06
draft specifies both Curve25519 and Curve448 even though only Curve25519
has been implemented by OpenSSH.

	-- Mark

---

From: denis bider <[email-masked]>
Date: Fri, 11 Aug 2017 10:56:22 -0600

I would also like to see it specified, but for a standards track document,
the main obstacle I see is the need for 2 implementations.

I generally loathe to implement something before OpenSSH, because my
installed base is maybe 1% of theirs, so even if I follow the spec, and
they implement it later but make a deviation, chances are that (1) they
won't care about compatibility with my implementation, (2) they will not
test against my implementation, and (3) I will be adapting to their
implementation, and not the other way around.

For these reasons, I am hesitant to implement something OpenSSH has not yet
implemented, but might implement in the future, until they have actually
done so. If I go first, then what they do will override my effort if/when
they implement it.

denis

---

From: Daniel Migault <[email-masked]>
Date: Fri, 11 Aug 2017 13:33:54 -0400

On a protocol specification I believe that defining later Ed448 will
duplicate the effort make for Ed25519 while we can take advantage of the
specification of Ed25519 now. In addition, the purpose of the specification
is also expected to prevent such issues. That I completely understand the
point made by Denis.

I wondering if maintaining a record of implementation and RFC would be
considered helpful. That might be something we could work on with the
codestand initiative [1]. Happy to heard from your feed backs.

Yours,
Daniel

On Fri, Aug 11, 2017 at 12:56 PM, denis bider <[email-masked]>
wrote:

> For these reasons, I am hesitant to implement something OpenSSH has not
> yet implemented, but might implement in the future, until they have
> actually done so. If I go first, then what they do will override my effort
> if/when they implement it.
>
> denis
>
>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 11 Aug 2017 11:19:40 -0700

Hi denis,

Yes, the lack of two implementations is a potential problem.

Given the libssh.org folks did the original work for curve25519,
I wonder if they will be the first to do curve448 and likewise eddsa448.

	-- Mark

---

From: Damien Miller <[email-masked]>
Date: Sun, 13 Aug 2017 19:38:15 +1000 (AEST)

> I wonder if they will be the first to do curve448 and likewise eddsa448.

I looked at adding ed448 to OpenSSH a while back and got stuck looking for
a standalone ed448 implementation that was as small, self-contained, clean
and suitably licensed as the ed25519 that we use (from Supercop).

Now, IMO our priority should be to choose a PQ KEX before another EC one.

-d

---

From: denis bider <[email-masked]>
Date: Sun, 13 Aug 2017 08:50:02 -0600

Aye, you're right. That is a concern for us as well. SUPERCOP has a
MIT-licensed implementation from Mike Hamburg, but this would be a problem
for us to, because it requires updating our license terms just for this
algorithm.

I have historically avoided any external code that has an impact on our
license terms. In the absence of a public domain implementation, I would
have to either change this policy, or implement my own. And I don't want to
subject anyone to crypto I implement on my own. :)

---

From: James Cloos <[email-masked]>
Date: Sun, 13 Aug 2017 17:13:22 -0400

>>>>> "DM" == Damien Miller <[email-masked]> writes:

DM> I looked at adding ed448 to OpenSSH a while back and got stuck looking for
DM> a standalone ed448 implementation that was as small, self-contained, clean
DM> and suitably licensed as the ed25519 that we use (from Supercop).

Powerdns uses Michael’s libdecaf¹ for 448.

It uses the mit license.  If you prefer, the x448 branch has an implementation
with one .c and one .h, also mit.  You could just grab those two files.

1] git://git.code.sf.net/p/ed448goldilocks/code.git

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Aug 2017 06:06:41 -0700

> the main obstacle I see is the need for 2 implementations.

AD here. Without taking a position on Ed448, there is no requirement for 2
implementations for Proposed Standard.

-Ekr

---

From: Daniel Migault <[email-masked]>
Date: Fri, 18 Aug 2017 13:25:35 +0000

Thanks for the information. I believe that there is a consensus in adding Ed448 in the document.  

If people are not currently working on it for openssh, maybe it would worth making a code request [1] with the necessary information so people can easily volunteer and contribute. I am happy to help if you have any question regarding codestand.

Yours, 
Daniel

[1] https://codestand.ietf.org/codestand/

-----Original Message-----
From: James Cloos [mailto:[email-masked]] 
Sent: Sunday, August 13, 2017 5:13 PM
To: Damien Miller <[email-masked]>
Cc: Mark D. Baushke <[email-masked]>; Daniel Migault <[email-masked]>; curdle <[email-masked]>; denis bider <[email-masked]>; Loganaden Velvindron <[email-masked]>
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt

>>>>> "DM" == Damien Miller <[email-masked]> writes:

DM> I looked at adding ed448 to OpenSSH a while back and got stuck 
DM> looking for a standalone ed448 implementation that was as small, 
DM> self-contained, clean and suitably licensed as the ed25519 that we use (from Supercop).

It uses the mit license.  If you prefer, the x448 branch has an implementation with one .c and one .h, also mit.  You could just grab those two files.

-JimC

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 18 Aug 2017 17:51:58 +0400

> Thanks for the information. I believe that there is a consensus in adding Ed448 in the document.
I will update the document to include ED 448.

> [1] https://codestand.ietf.org/codestand/

I'm registering on codestand.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 18 Aug 2017 13:56:45 +0000

Great!

-----Original Message-----
From: Loganaden Velvindron [mailto:[email-masked]] 
Sent: Friday, August 18, 2017 9:52 AM
To: Daniel Migault <[email-masked]>
Cc: James Cloos <[email-masked]>; Damien Miller <[email-masked]>; Mark D. Baushke <[email-masked]>; curdle <[email-masked]>; denis bider <[email-masked]>
Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt

> Cc: Mark D. Baushke <[email-masked]>; Daniel Migault 
> <[email-masked]>; curdle <[email-masked]>; denis bider 
> <[email-masked]>; Loganaden Velvindron <[email-masked]>