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

"Joseph Salowey (jsalowey)" <> Fri, 30 May 2014 16:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D8E21A03BE; Fri, 30 May 2014 09:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0A8p_aujBRnd; Fri, 30 May 2014 09:52:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E88A1A6F6E; Fri, 30 May 2014 09:52:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2876; q=dns/txt; s=iport; t=1401468723; x=1402678323; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DhJQ2k6+VHJC0uCWNv/jtRqQWhJZJRm5L2W/TgHV5Qo=; b=FNX5eCtf52R5MbrfR2b2LTGakQSKHcNu24GPLiwc7KkxtzwE9C2VCLOl 9k6PzR/01zS4oQBUc2kw0wttimD4OgBuEUkjH4VwLVCexSSA277qRtLZy PiktTtywrqt2L3i7VdjGxAtHQeZh7CbzsKseNTrenF7S11mBhRdJeH6m2 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.98,942,1392163200"; d="scan'208";a="329191875"
Received: from ([]) by with ESMTP; 30 May 2014 16:52:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s4UGq2f2032679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 16:52:02 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Fri, 30 May 2014 11:52:02 -0500
From: "Joseph Salowey (jsalowey)" <>
To: S Moonesamy <>
Thread-Topic: secdir review of draft-moonesamy-sshfp-ed25519-01
Thread-Index: AQHPeWUfo5K1BZN1JUqd29NR7Q9teZtZWecAgABWFIA=
Date: Fri, 30 May 2014 16:52:01 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 May 2014 16:52:10 -0000

On May 30, 2014, at 4:43 AM, S Moonesamy <> 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 ( ).  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 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