Subject: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 27 May 2014 04:35:44 +0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document defines an SSHFP DNS record for ED25519 signature algorithm.  The document is ready with issues:

1)  This document describes how to store the fingerprint of a public key that can be used with the ed25519 signature algorithm.  I do not see any reference as to how to use the ed25519 signature algorithm in SSH.  Perhaps I am missing a reference somewhere, but it really seems that the use of the signature algorithm in SSH should be defined somewhere, preferably in an IETF document.  I so not see the point of publishing the SSHFP record document without some reference as to how it will be used. 

2)  The examples in RFC 6594 include the OpenSSH formatted key that is decoded and hashed to obtain the resulting fingerprint.  It would be better if the draft followed this aspect of 6594 and included the key used to generate the fingerprint.  

Joe

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 27 May 2014 04:37:45 +0000

<resending to include the IESG>

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 May 2014 04:43:56 -0700

Hi Joe,

Thanks for the review.  I'll comment below.

At 21:35 26-05-2014, Joseph Salowey (jsalowey) wrote:
>This document defines an SSHFP DNS record for ED25519 signature 
>algorithm.  The document is ready with issues:
>
>1)  This document describes how to store the fingerprint of a public 
>key that can be used with the ed25519 signature algorithm.  I do not 
>see any reference as to how to use the ed25519 signature algorithm 
>in SSH.  Perhaps I am missing a reference somewhere, but it really 
>seems that the use of the signature algorithm in SSH should be 
>defined somewhere, preferably in an IETF document.  I so not see the 
>point of publishing the SSHFP record document without some reference 
>as to how it will be used.

OpenSSH used the following reference to implement the ed25519 
signature algorithm:

   Bernstein, D. J., Lange T., Schwabe P., Yang B-Y., High-
   Speed High-Security Signatures, Journal of Cryptographic
   Engineering, Vol. 2, September 26, 2011

TeraTerm also implemented that ( 
http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 
).  In my opinion that passes the "running code" test.  I'll 
highlight that the intended status of the document is 
Informational.  The reason was to have documentation about the code 
point assignment and to determine IETF Consensus for the 
assignment.  The point in publishing the document is to fulfill RFC 
4255 requirements.

>2)  The examples in RFC 6594 include the OpenSSH formatted key that 
>is decoded and hashed to obtain the resulting fingerprint.  It would 
>be better if the draft followed this aspect of 6594 and included the 
>key used to generate the fingerprint.

Stephen Farrell raised that question during the AD Review (the 
message was on the [email-masked] mailing list).  I mentioned 
that the public key fingerprint used for ED25519 in the SSHFP 
Resource Record relies on an undocumented OpenSSH public key format 
and I did not follow the examples in RFC 6594 because of that.

Regards,
S. Moonesamy

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 30 May 2014 16:52:01 +0000

On May 30, 2014, at 4:43 AM, S Moonesamy <[email-masked]> wrote:

> OpenSSH used the following reference to implement the ed25519 signature algorithm:
> 
> TeraTerm also implemented that ( http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 ).  In my opinion that passes the "running code" test.  I'll highlight that the intended status of the document is Informational.  The reason was to have documentation about the code point assignment and to determine IETF Consensus for the assignment.  The point in publishing the document is to fulfill RFC 4255 requirements.
> 

[Joe] Running code is certainly good, but I don't think the ed25519 paper by itself provides enough information to create an interoperable implementation.   Without this information I'm not sure its possible to implement the draft.  For example, as you mention below the format for the key is undocumented is it well enough understood what the format of the data to be hashed in the fingerprint is from the draft and its references?  It seems the only documentation of the protocol is in the source code.  I'm not sure if there is a precedent for referencing a source code, but if it is source controlled perhaps it is acceptable. 

> Stephen Farrell raised that question during the AD Review (the message was on the [email-masked] mailing list).  I mentioned that the public key fingerprint used for ED25519 in the SSHFP Resource Record relies on an undocumented OpenSSH public key format and I did not follow the examples in RFC 6594 because of that.
> 
> Regards,
> S. Moonesamy

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 30 May 2014 14:16:18 -0400

I personally would not accept source code as the sole specification. IETF
tradition has always been providing both the "verbal" description in English
(or as close to it as practical) *plus* a reference implementation, preferably
more than one.

Mere existence of an implementation has never been an excuse to weasel out of
actually documenting the protocol.

My $0.02.

Quoting "Joseph Salowey (jsalowey)" <[email-masked]>:
>>> 1)  This document describes how to store the fingerprint of a 
>>> public key that can be used with the ed25519 signature algorithm.  
>>> I do not see any reference as to how to use the ed25519 signature 
>>> algorithm in SSH.  Perhaps I am missing a reference somewhere, but 
>>> it really seems that the use of the signature algorithm in SSH 
>>> should be defined somewhere, preferably in an IETF document.  I so 
>>> not see the point of publishing the SSHFP record document without 
>>> some reference as to how it will be used.
>>
>> http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 ).  
>> In my opinion that passes the "running code" test.  I'll highlight 
>> that the intended status of the document is Informational.  The 
>> reason was to have documentation about the code point assignment and 
>> to determine IETF Consensus for the assignment.  The point in 
>> publishing the document is to fulfill RFC 4255 requirements.
>>
>
> [Joe] Running code is certainly good, but I don't think the ed25519 
> paper by itself provides enough information to create an 
> interoperable implementation.   Without this information I'm not sure 
> its possible to implement the draft.  For example, as you mention 
> below the format for the key is undocumented is it well enough 
> understood what the format of the data to be hashed in the 
> fingerprint is from the draft and its references?  It seems the only 
> documentation of the protocol is in the source code.  I'm not sure if 
> there is a precedent for referencing a source code, but if it is 
> source controlled perhaps it is acceptable.
>
>>> is decoded and hashed to obtain the resulting fingerprint.  It 
>>> would be better if the draft followed this aspect of 6594 and 
>>> included the key used to generate the fingerprint.
>>
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 May 2014 11:44:30 -0700

Hi Joe,
At 09:52 30-05-2014, Joseph Salowey (jsalowey) wrote:
>interoperable implementation.   Without this information I'm not 
>sure its possible to implement the draft.  For example, as you 
>mention below the format for the key is undocumented is it well 
>enough understood what the format of the data to be hashed in the 
>documentation of the protocol is in the source code.  I'm not sure 
>if there is a precedent for referencing a source code, but if it is 

According to http://www.openssh.com/ OpenSSH is used by "companies 
like NetApp, NETFLIX, EMC, Juniper, Cisco, Apple, Red Hat, and 
Novell; but probably includes almost all router, switch or unix-like 
operating system vendors".  The source code has been under revision 
control since over 10 years and it is publicly accessible.  The 
source code is distributed under a liberal license.  I could have 
argued for "Proposed Standard".  I thought that it was better to go 
for "Informational" to document what has been implemented as I would 
have raised arguments similar to the ones quoted above is a review 
about a "Proposed Standard".

There was a comment from Rene Struik during the Last Call about the 
hash and the ed25519 paper ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg87894.html ).  I 
think that he understood how it works.  The well understood test 
happens after publication as it depends on the unknown reader.

There is a precedent for referencing source code.  In my opinion it 
is better not to do that unless it is really necessary.  I prefer not 
to use the precedent argument.

I'll note that this draft does not break anything on the internet.

Please let me know whether the above addresses the issues in the review.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 May 2014 11:56:58 -0700

Hi Uri,
>actually documenting the protocol.

IETF tradition is not to copy SecDir reviews to [email-masked].  I 
agree that it is good to have a verbal description of a specification 
in English.  It helps to have an implementation.

The draft documents a code point assignment; it is not about a protocol.

Regards,
S. Moonesamy

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 30 May 2014 20:42:31 +0000

On May 30, 2014, at 11:56 AM, S Moonesamy <[email-masked]> wrote:

> IETF tradition is not to copy SecDir reviews to [email-masked].  I agree that it is good to have a verbal description of a specification in English.  It helps to have an implementation.
> 

[Joe] My concern is that there is not enough information in the draft to know what goes into the hash that is the subject of the code point assignment.  Perhaps it is obvious to someone who implemented the SSH code that is not documented in this draft, but it is not obvious to me as a reader of the draft.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 May 2014 15:22:26 -0700

Hi Joe,
At 13:42 30-05-2014, Joseph Salowey (jsalowey) wrote:
>[Joe] My concern is that there is not enough information in the 
>draft to know what goes into the hash that is the subject of the 
>code point assignment.  Perhaps it is obvious to someone who 
>implemented the SSH code that is not documented in this draft, but 
>it is not obvious to me as a reader of the draft.

That's a fair point.  I propose adding the following text in Section 
2 as a warning to the reader:

   The format of the ED25519 public key with SHA-256 fingerprint is
   not documented in an authoritative specification.

Regards,
S. Moonesamy

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 May 2014 23:42:31 +0100

On 30/05/14 23:22, S Moonesamy wrote:
>> [Joe] My concern is that there is not enough information in the draft
>> to know what goes into the hash that is the subject of the code point
>> assignment.  Perhaps it is obvious to someone who implemented the SSH
>> code that is not documented in this draft, but it is not obvious to me
>> as a reader of the draft.
> 
> That's a fair point.  I propose adding the following text in Section 2
> as a warning to the reader:
> 

Why? Why not just look at the code and write down what that does
in terms of formatting the input.

If >1 implementation interoperates it can't be that hard.

S.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 May 2014 17:18:37 -0700

Hi Stephen,
>If >1 implementation interoperates it can't be that hard.

I had some private discussions about what the source code does to see 
how to turn that into a specification.  The conclusion was that it 
would be non-trivial to write down something acceptable to the 
IETF.  If it was not that hard everybody would be able to do it. :-)

Regards,
S. Moonesamy

---

From: Dick Franks <[email-masked]>
Date: Sat, 31 May 2014 02:27:56 +0100

On 31 May 2014 01:18, S Moonesamy <[email-masked]> wrote:

> I had some private discussions about what the source code does to see how
> to turn that into a specification.  The conclusion was that it would be
> non-trivial to write down something acceptable to the IETF.

If it is non-trivial to extract the data format from the code, it is
essential that it be included here or incorporated by reference to a freely
available public document.

 If it was not that hard everybody would be able to do it. :-)

:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(
:-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(  :-(

---

From: Uri Blumenthal <[email-masked]>
Date: Sat, 31 May 2014 22:53:06 -0400

I reject S. Moonesamy's proposal, and strongly support Stephen's recommendation.

Sent from my iPad

> On May 30, 2014, at 18:42, Stephen Farrell <[email-masked]> wrote:
> 
> 
>