Subject: Re: [Curdle] new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Jul 2019 16:34:18 -0500

Cycling back on this, my reading of the archive suggests that we want an
-09 to include Daniel's suggested text to clarify on (1), and we need to
hear from Ben about (3).

Does that sound right to everyone or am I missing something?

Thanks,

Ben

On Fri, Jun 07, 2019 at 05:26:11PM -0500, Benjamin Kaduk wrote:
> On Thu, Jun 06, 2019 at 02:56:46PM +0000, Daniel Migault wrote:
> > This is correct, for some reasons I reviewed version 07. So version 08 is solving the opsdir issue. I will close the thread on the mailing list.
> 
> Ah, thank you.  Thanks also to Loganaden for the updates in the -08, and
> sorry for not having confirmed that they did address the opsdir review
> comment.
> 
> > The SSHF Record includes the algorithm used for the public key, the type of the fingerprint. The current draft only adds a registry for the algorithm. I believe the confusion might be that the current text  seems to indicate some additional changes for example in the generation of the finger print.  Maybe the text below around the following lines clarifies the purpose of the changes.
> 
> That seems likely.
> 
> > If so, the only remaining point is the IPR declaration.
> 
> [adding Ben to the To: list to try to answer this question.]
> 
> -Ben
> 
> > OLD:
> > The generation of SSHFP resource records for "ssh-ed25519" keys is
> >    described in [RFC7479].
> > 
> >    The generation of SSHFP resource records for "ssh-ed448" keys is
> >    described as follows.
> > 
> >    the SSHFP Resource Record for the Ed448 public key with SHA-256
> >    fingerprint would be example be:
> > 
> >    example.com.  IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f2826723
> >    34d90ed316d2b818ca9580ea384d924 01 )
> > 
> >    The 2 here indicates SHA-256 [RFC6594].
> > 
> > NEW:
> > 
> > The generation of SSHFP resource records for "ssh-ed25519" keys is
> >    described in [RFC7479].
> > 
> > The SSHFP resource records for "ssh-ed448" keys is generated similarly,
> > with the algorithm field indicating a Ed448 public key.
> > 
> > The SSHFP Resource Record for the Ed448 public key with SHA-256
> > fingerprint would be example be:
> > 
> > example.com.  IN SSHFP TBD 2 ( a87f1b687ac0e57d2a081a2f2826723
> > 34d90ed316d2b818ca9580ea384d924 01 )
> > 
> > The 2 here indicates SHA-256 [RFC6594].
> > 
> > From: Loganaden Velvindron <[email-masked]>
> > Sent: Thursday, June 06, 2019 3:02 AM
> > To: Daniel Migault <[email-masked]>
> > Cc: Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]
> > Subject: Re: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08
> > 
> > I already published rev08 to address those issues:
> > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-curdle-ssh-ed25519-ed448-08.txt
> > 
> > On Wed, Jun 5, 2019 at 5:52 PM Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
> > Thanks Ben for the follow-up, please see my responses inline for (2) and (4). I believe a version 08 is needed to address (1) and (2).
> > Yours,
> > Daniel
> > 
> > -----Original Message-----
> > From: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
> > Sent: Tuesday, June 04, 2019 1:41 PM
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > Subject: new AD review comments on draft-ietf-curdle-ssh-ed25519-ed448-08
> > 
> > Hi all,
> > 
> > I'm just about ready to send this to the IESG, but there seems to be a few things to fix, first:
> > 
> > (1) In Section 8 we say "The generation of SSHFP resource records for "ssh-ed448" keys is described as follows." but then give only an example and not a description of what to do.  We need to say more about this procedure
> > 
> > (2) I'm not sure if the chain on the opsdir review got fully resolved; see https://mailarchive.ietf.org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uPhaCk
> > <mglt>
> > The current version has not accordingly been updated.
> > </mglt>
> > 
> > (3) The shepherd writeup says that Ben did not confirm IPR (non)disclosure per BCPs 78 and 79 -- Ben, can you please do so now?
> > 
> > (4) Daniel, can you please update the shepherd writeup to reflect the discussions with the directorate reviewers about document status?  I'm sure that some IESG members will ask "why not Informational?" if we don't forestall them.
> > 
> > <mglt>
> > I have update the shepherd as follows:
> > 
> > (1) What type of RFC is being requested (BCP, Proposed Standard,
> > Internet Standard, Informational, Experimental, or Historic)?  Why
> > is this the proper type of RFC?  Is this type of RFC indicated in the
> > title page header?
> > 
> > The requested status is Standard Track. This is necessary for
> > inter-operability  and as such the Standard Track seems the
> > most appropriated status.
> > 
> > The OPS Directorate wondered why version 07 was a Standard Track
> > document and not an informational document as no normative 2119 words.
> > 
> > The reason for being a standard track is that we expect the implementation
> > that implement SSH to follow these recommendations. The consensus was
> > to explicitly mention it in the document around the lines:
> > 
> > "Standard implementations of SSH SHOULD implement these signature algorithms."
> > </mglt>
> > Thanks,
> > 
> > Ben

---

From: Daniel Migault <[email-masked]>
Date: Tue, 30 Jul 2019 19:56:08 -0400

Hi Ben,

In order to move the document forward, it would be helpful if you could
state if you are aware of any IPR related to the document.

Yours,
Daniel

On Tue, Jul 30, 2019 at 5:34 PM Benjamin Kaduk <[email-masked]> wrote:

> > > This is correct, for some reasons I reviewed version 07. So version 08
> is solving the opsdir issue. I will close the thread on the mailing list.
> >
> > > The SSHF Record includes the algorithm used for the public key, the
> type of the fingerprint. The current draft only adds a registry for the
> algorithm. I believe the confusion might be that the current text  seems to
> indicate some additional changes for example in the generation of the
> finger print.  Maybe the text below around the following lines clarifies
> the purpose of the changes.
> >
> > That seems likely.
> >
> > > Cc: Benjamin Kaduk <[email-masked]>;
> [email-masked]; [email-masked]
> > > On Wed, Jun 5, 2019 at 5:52 PM Daniel Migault <
> [email-masked]<mailto:[email-masked]>> wrote:
> > > Thanks Ben for the follow-up, please see my responses inline for (2)
> and (4). I believe a version 08 is needed to address (1) and (2).
> > > Yours,
> > > Daniel
> > >
> > > To: [email-masked]<mailto:
> [email-masked]>
> > > (1) In Section 8 we say "The generation of SSHFP resource records for
> "ssh-ed448" keys is described as follows." but then give only an example
> and not a description of what to do.  We need to say more about this
> procedure
> > >
> > > (2) I'm not sure if the chain on the opsdir review got fully resolved;
> see
> https://mailarchive.ietf.org/arch/msg/curdle/DZc2Sr19zJ71nnC3pSIF0uPhaCk
> > > <mglt>
> > > (3) The shepherd writeup says that Ben did not confirm IPR
> (non)disclosure per BCPs 78 and 79 -- Ben, can you please do so now?
> > >
> > > (4) Daniel, can you please update the shepherd writeup to reflect the
> discussions with the directorate reviewers about document status?  I'm sure
> that some IESG members will ask "why not Informational?" if we don't
> forestall them.
> > >
> > > <mglt>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 30 Jul 2019 19:57:34 -0400

Hi,

I believe that is all we need to do.

Yours,
Daniel

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 31 Jul 2019 10:33:39 +0400

> Does that sound right to everyone or am I missing something?
I would suggest standards track given that ed25519 is already public key is
already implemented by OpenSSH.

http://www.openssh.com/txt/release-6.5

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 31 Jul 2019 13:34:38 +0400

> I believe that is all we need to do.

Please find the diff with the changes including fixing a mistake:
114-octet signature for ed448.

https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ed25519-ed448-09

---

From: Daniel Migault <[email-masked]>
Date: Wed, 31 Jul 2019 07:57:22 -0400

Thanks Logan. I believe we are all set except for IPR disclosure from Ben.
Yours,
Daniel

On Wed, Jul 31, 2019 at 5:34 AM Loganaden Velvindron <[email-masked]>
wrote:

> >> > > This is correct, for some reasons I reviewed version 07. So version
> 08 is solving the opsdir issue. I will close the thread on the mailing list

---

From: denis bider <[email-masked]>
Date: Wed, 31 Jul 2019 18:19:10 -0500

> I would suggest standards track given that ed25519
> is already public key is already implemented by OpenSSH.

Just to confirm, there are other implementations too.

For example, Ed25519 was introduced in Bitvise SSH Server and SSH Client in
versions 7.21 (released end of 2016):

https://www.bitvise.com/ssh-server-version-history-7

denis

On Wed, Jul 31, 2019 at 1:34 AM Loganaden Velvindron <[email-masked]>
wrote:

> 08 is solving the opsdir issue. I will close the thread on the mailing list.
> > >
> > > > (1) In Section 8 we say "The generation of SSHFP resource records
> for "ssh-ed448" keys is described as follows." but then give only an
> example and not a description of what to do.  We need to say more about
> this procedure
> > > >
> > > > (2) I'm not sure if the chain on the opsdir review got fully
> resolved; see
> > > > (4) Daniel, can you please update the shepherd writeup to reflect
> the discussions with the directorate reviewers about document status?  I'm
> sure that some IESG members will ask "why not Informational?" if we don't
> forestall them.
> > > >
> > > > <mglt>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Ron Frederick <[email-masked]>
Date: Wed, 31 Jul 2019 21:27:59 -0700

On Jul 31, 2019, at 4:19 PM, denis bider <[email-masked]> wrote:
> For example, Ed25519 was introduced in Bitvise SSH Server and SSH Client in versions 7.21 (released end of 2016):
> 

AsyncSSH also has implementations of both ssh-ed25519 (in version 1.0.0 from April 2015) and ssh-ed448 (in version 1.16.0 from March 2019). See https://asyncssh.readthedocs.io/en/latest/changes.html for details. I tested the AsyncSSH ssh-ed448 support against the Erlang SSH library, which supports both ssh-ed25519 and ssh-ed448. Other implementations of ssh-ed25519 are listed at https://ssh-comparison.quendi.de/comparison/hostkey.html.

> On Wed, Jul 31, 2019 at 1:34 AM Loganaden Velvindron <[email-masked]> wrote:
-- 
Ron Frederick
[email-masked]