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

Uri Blumenthal <uri@MIT.EDU> Fri, 30 May 2014 18:16 UTC

Return-Path: <uri@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EB51A0982; Fri, 30 May 2014 11:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level:
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz0Uti7RqMSx; Fri, 30 May 2014 11:16:31 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200891A036A; Fri, 30 May 2014 11:16:31 -0700 (PDT)
X-AuditID: 1209190f-f790b6d000000c38-2a-5388caf9b37c
Received: from mailhub-2.mit.edu ( [18.7.62.30]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4A.4D.03128.9FAC8835; Fri, 30 May 2014 14:16:25 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-1.mit.edu [18.9.28.12]) by mailhub-2.mit.edu (8.13.8/8.9.2) with ESMTP id s4UIGNLl003370; Fri, 30 May 2014 14:16:24 -0400
Received: from webmail-3.mit.edu (webmail-3.mit.edu [18.9.23.13]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4UIGK56002108; Fri, 30 May 2014 14:16:20 -0400
Received: from webmail-3.mit.edu (localhost.localdomain [127.0.0.1]) by webmail-3.mit.edu (8.13.8) with ESMTP id s4UIGJuS004578; Fri, 30 May 2014 14:16:19 -0400
Received: (from nobody@localhost) by webmail-3.mit.edu (8.13.8/8.13.8/Submit) id s4UIGIGL004577; Fri, 30 May 2014 14:16:18 -0400
X-Authentication-Warning: webmail-3.mit.edu: nobody set sender to uri@mit.edu using -f
Received: from LLPROXY.LL.MIT.EDU (LLPROXY.LL.MIT.EDU [129.55.200.20]) (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Fri, 30 May 2014 14:16:18 -0400
Message-ID: <20140530141618.kgnw4u9b4gw80o4s@webmail.mit.edu>
X-Priority: 3 (Normal)
Date: Fri, 30 May 2014 14:16:18 -0400
From: Uri Blumenthal <uri@MIT.EDU>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <2ACBFFE4-BCEB-4F6D-A2D3-861BADF543DE@cisco.com> <6.2.5.6.2.20140530040300.0bb93070@elandnews.com> <D1342262-144C-4939-B005-5E042CAF7394@cisco.com>
In-Reply-To: <D1342262-144C-4939-B005-5E042CAF7394@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDKsWRmVeSWpSXmKPExsUixG4np/vzVEewwZn5NhYz7/pZzPgzkdni 2cb5LBZdR9eyW3xY+JDF4lX/TVYHNo8pvzeyetx785HJY8mSn0weXy5/ZgtgieKySUnNySxL LdK3S+DK6Nl9ga2gS6Zi9cXjjA2Mp8S6GDk5JARMJC59WMMOYYtJXLi3nq2LkYtDSGAak8S9 X+tZIJzljBI7P5xlgnBWM0osf/+KFcJZxCix7c9CqEwLo8SEdW2MEMPCJDZ232KGSJxilPg5 +T/YFl4BW4mWrivMMBsnrPsFZrMIqEos+r6UCcRmE1CSaG7ewgpiiwBdOPn9SrBBzAJdTBKX 3r1jAUkIC7hLnNg9AWrDYkaJX3NBLuTg4ATacPlMMcQyQYmTM5+A1TMLOEr87W1mAylhFpCW WP6PAyIsL7H97RywG0QFzCUe7N3BOIFRfBaS7llIumchdM9C0r2AkWUVo2xKbpVubmJmTnFq sm5xcmJeXmqRrolebmaJXmpK6SZGUKRySvLvYPx2UOkQowAHoxIPr8OMjmAh1sSy4srcQ4yS HExKorziJ4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHifHwHK8aYkVlalFuXDpKQ5WJTEed9a WwULCaQnlqRmp6YWpBbBZGU4OJQkeM+dBGoULEpNT61Iy8wpQUgzcXCCDOcBGj4TpIa3uCAx tzgzHSJ/ilFRSpw3FiQhAJLIKM2D64Ul0leM4kCvCPOuBqniASZhuO5XQIOZgAY/6WwFGVyS iJCSamCUuLeQs8/TZE2xi3iN83KvqZq3VkotW1Tw/8Szv0K3ApZ0aM+99+kUW0V/fp1vZMNz AfGeTs5nu+Tnp0vNYYhxjmU9OHGWbN7Vj82/vPasi/pdOyXnkEVMjfWdpjmWBqVz5saanHhW 9OULu0Pe96+dsc+ef7wlfFZK9sqG5W8sHpdLmJctfsunxFKckWioxVxUnAgAWSwHt38DAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/N6s2JTQqUBy93PsEM8e3nhTvctQ
Cc: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-moonesamy-sshfp-ed25519.all@tools.ietf.org" <draft-moonesamy-sshfp-ed25519.all@tools.ietf.org>, S Moonesamy <sm+ietf@elandsys.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [secdir] secdir review of draft-moonesamy-sshfp-ed25519-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2014 18:16:41 -0000

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>om>:
> 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
>