On May 30, 2014, at 4:43 AM, S Moonesamy <sm+ietf(_at_)elandsys(_dot_)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(_at_)netbsd(_dot_)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