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

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)" <jsalowey@cisco.com>:
> On May 30, 2014, at 4:43 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:
>
>> 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.
>>
>
> [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.
>
>>> 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 ietf-ssh@netbsd.org 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
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>