Subject: [Curdle] Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07

From: Sheng Jiang <[email-masked]>
Date: Wed, 02 Jan 2019 02:01:31 -0800

Reviewer: Sheng Jiang
Review result: Has Issues

Reviewer: Sheng Jiang
Review result: Has Issues

Hi, OPS-DIR, Authors,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

This standard track document describes the use of the Ed25519 and Ed448 digital
signature algorithm in the Secure Shell (SSH) protocol.  This document is one
of the shortest documents I have ever seen. It is clear and well written.
However, I have a fundamental issue regarding to its Intended status "Standards
Track", describe below. Therefore, it has issues for publication although I
think it is easy to fixed - changing the Intended status.

Major issue: this document has Intended status for Standards Track. However,
neither this document fails to quota RFC 2119 or has any normative words.
Consistently, I don't think the description in this document has any mandatory
requirements for any implementations of protocols. Actually, the most important
quota of this document, RFC8032, is Informational, which is a Downref in this
document. Therefore, I think it is more proper this document intends for
Informational status.

Minor issue: no.

Regards,

Sheng

---

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Jan 2019 15:43:23 +0000

Hi Sheng,

Thanks for the comment and the suggestion. I agree that it may sound strange to have a standard Track category without any reference to RFC2119. In addition, while the document provides IANA registry updates, the IANA registration does not require a Standard Track. So *technically* the informational category could be fine. 

The motivation for a Standard Track document was to have these algorithms as part of the SSH protocol. In other words, we expect that SSH will come with these algorithms in the future. For that reason we requested the status to be "Standard Track" to remain coherent with RFC425{1-4}.

(RFC4250 and) RFC4253 provided the initial values for the Public Key registry. While the protocol comes with some registry values, my understanding is that updating the registry by adding a new value is not considered as an update the RFC. For that reason we did not provide RFC4253 or RFC4250 in the update status. While the update does not concern the RFC, it affects the protocol and should - in my opinion be associated to the same status as the protocol. 

As a side note, all RFCs that have updated the Public Key Algorithm Names are Standard Track documents. On the other hand, they seem to reference and use the RFC2119 terms. 

I believe that the Standard Track category is the most appropriated, however, I am happy to be wrong and have misunderstood something. Feel free to let me know your opinion on the category, as well as if there are any clarification we should add in the text. I suggest that we add a sentence around the lines: 
""" These signature algorithms are expected to be integrated into the standard implementations of SSH. """
 
Any feed back is welcome!

Yours, 
Daniel
-----Original Message-----
From: Sheng Jiang <[email-masked]> 
Sent: Wednesday, January 02, 2019 5:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07

Reviewer: Sheng Jiang

Reviewer: Sheng Jiang

Hi, OPS-DIR, Authors,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.

This standard track document describes the use of the Ed25519 and Ed448 digital signature algorithm in the Secure Shell (SSH) protocol.  This document is one of the shortest documents I have ever seen. It is clear and well written.
However, I have a fundamental issue regarding to its Intended status "Standards Track", describe below. Therefore, it has issues for publication although I think it is easy to fixed - changing the Intended status.

Major issue: this document has Intended status for Standards Track. However, neither this document fails to quota RFC 2119 or has any normative words.
Consistently, I don't think the description in this document has any mandatory requirements for any implementations of protocols. Actually, the most important quota of this document, RFC8032, is Informational, which is a Downref in this document. Therefore, I think it is more proper this document intends for Informational status.

Minor issue: no.

Regards,

Sheng

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 2 Jan 2019 18:12:18 +0000

Why not just reference RFC 2119 and say "Standard implementations of SSH
SHOULD implement these signature algorithms." ?

-Tim

> From: Curdle <[email-masked]> On Behalf Of Daniel Migault
> Sent: Wednesday, January 2, 2019 10:43 AM
> To: Sheng Jiang <[email-masked]>; [email-masked]
> Subject: Re: [Curdle] Opsdir last call review of
draft-ietf-curdle-ssh-ed25519-
> ed448-07
> 
> Hi Sheng,
> 
> Thanks for the comment and the suggestion. I agree that it may sound
> strange to have a standard Track category without any reference to
> RFC2119. In addition, while the document provides IANA registry updates,
> the IANA registration does not require a Standard Track. So *technically*
the
> informational category could be fine.
> 
> The motivation for a Standard Track document was to have these algorithms
> as part of the SSH protocol. In other words, we expect that SSH will come
> with these algorithms in the future. For that reason we requested the
status
> to be "Standard Track" to remain coherent with RFC425{1-4}.
> 
> (RFC4250 and) RFC4253 provided the initial values for the Public Key
registry.
> While the protocol comes with some registry values, my understanding is
> that updating the registry by adding a new value is not considered as an
> update the RFC. For that reason we did not provide RFC4253 or RFC4250 in
> the update status. While the update does not concern the RFC, it affects
the
> protocol and should - in my opinion be associated to the same status as
the
> protocol.
> 
> As a side note, all RFCs that have updated the Public Key Algorithm Names
> are Standard Track documents. On the other hand, they seem to reference
> and use the RFC2119 terms.
> 
> I believe that the Standard Track category is the most appropriated,
> however, I am happy to be wrong and have misunderstood something. Feel
> free to let me know your opinion on the category, as well as if there are
any
> clarification we should add in the text. I suggest that we add a sentence
> around the lines:
> I have reviewed this document as part of the Operational directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written with the intent of improving the operational
> aspects of the IETF drafts. Comments that are not addressed in last call
may
> be included in AD reviews during the IESG review. Document editors and WG
> chairs should treat these comments just like any other last call comments.
> 
> This standard track document describes the use of the Ed25519 and Ed448
> digital signature algorithm in the Secure Shell (SSH) protocol.  This
document
> is one of the shortest documents I have ever seen. It is clear and well
> written.
> However, I have a fundamental issue regarding to its Intended status
> "Standards Track", describe below. Therefore, it has issues for
publication
> although I think it is easy to fixed - changing the Intended status.
> 
> Major issue: this document has Intended status for Standards Track.
> However, neither this document fails to quota RFC 2119 or has any
> normative words.
> Consistently, I don't think the description in this document has any
> mandatory requirements for any implementations of protocols. Actually, the
> most important quota of this document, RFC8032, is Informational, which is
> a Downref in this document. Therefore, I think it is more proper this
> document intends for Informational status.
> 
> Minor issue: no.
> 
> Regards,
> 
> Sheng
> 
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Jan 2019 18:56:42 +0000

Thanks for the suggestion Tim. That works for me. 
Yours, 
Daniel

-----Original Message-----
From: Tim Hollebeek <[email-masked]> 
Sent: Wednesday, January 02, 2019 1:12 PM
To: Daniel Migault <[email-masked]>; Sheng Jiang
<[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: Opsdir last call review of
draft-ietf-curdle-ssh-ed25519-ed448-07

-Tim

the
status
registry.
the
the
any
may
document
publication

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Jan 2019 19:08:25 +0000

Agreed, that's a good wording.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 3 Jan 2019 13:58:50 +0000

Hi, Daniel,

The suggestion from Tim is a good improvement. However, it would be even better for a "standard track" document, if it gave a little bit more detailed guidance "where" and "how" a SSH implement should quota the key format that defined in this document.

Regards,

Sheng

-----Original Message-----
From: Tim Hollebeek <[email-masked]> 
Sent: Wednesday, January 02, 2019 1:12 PM
To: Daniel Migault <[email-masked]>; Sheng Jiang

-Tim

the
status
registry.
the
the
any
may
document
publication

---

From: Daniel Migault <[email-masked]>
Date: Thu, 3 Jan 2019 16:23:22 +0000

Hi Sheng, 

Thanks for the comment. It should be easily addressed in the next version.

Yours, 
Daniel

-----Original Message-----
From: Sheng Jiang <[email-masked]> 
Sent: Thursday, January 03, 2019 8:59 AM
To: Daniel Migault <[email-masked]>; Tim Hollebeek <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07

Hi, Daniel,

Regards,

Sheng

-----Original Message-----
From: Tim Hollebeek <[email-masked]>
Sent: Wednesday, January 02, 2019 1:12 PM
To: Daniel Migault <[email-masked]>; Sheng Jiang <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Opsdir last call review of

Why not just reference RFC 2119 and say "Standard implementations of SSH SHOULD implement these signature algorithms." ?

-Tim

> RFC2119. In addition, while the document provides IANA registry 
> updates, the IANA registration does not require a Standard Track. So 
> *technically*
the
> The motivation for a Standard Track document was to have these 
> algorithms as part of the SSH protocol. In other words, we expect that 
> SSH will come with these algorithms in the future. For that reason we 
> requested the
status
registry.
> While the protocol comes with some registry values, my understanding 
> is that updating the registry by adding a new value is not considered 
> as an update the RFC. For that reason we did not provide RFC4253 or 
> RFC4250 in the update status. While the update does not concern the 
> RFC, it affects
the
the
> protocol.
> 
> As a side note, all RFCs that have updated the Public Key Algorithm 
> Names are Standard Track documents. On the other hand, they seem to 
> reference and use the RFC2119 terms.
> 
any
> clarification we should add in the text. I suggest that we add a 
> sentence around the lines:
> These comments were written with the intent of improving the 
> operational aspects of the IETF drafts. Comments that are not 
> addressed in last call
may
> be included in AD reviews during the IESG review. Document editors and 
> WG chairs should treat these comments just like any other last call comments.
> 
> This standard track document describes the use of the Ed25519 and 
> Ed448 digital signature algorithm in the Secure Shell (SSH) protocol.  
> This
document
> is one of the shortest documents I have ever seen. It is clear and 
> well written.
publication
> mandatory requirements for any implementations of protocols. Actually, 
> the most important quota of this document, RFC8032, is Informational, 
> which is a Downref in this document. Therefore, I think it is more 
> proper this document intends for Informational status.
> 
> Minor issue: no.
> 
> Regards,
> 
> Sheng
> 
>