Subject: Re: [Cfrg] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-01

From: Alyssa Rowan <[email-masked]>
Date: Tue, 01 Apr 2014 19:01:51 +0100

On 01/04/2014 17:32, S Moonesamy wrote:

> It would help if I could get some feedback from CFRG about 
> draft-moonesamy-sshfp-ed25519-01

Not much to review, really. I see no problems; straightforward.

OpenSSH has already adopted Ed25519 independently (as in
djb/Duif/Lange/Schwabe/Yang, with SHA-512 as the hash).

While I could suggest (and have suggested) a small improvement (simply
swapping the SHA-512 for a newer, better, faster hash, from the SHA-3
competition finalists: e.g. SHA-3?), and CFRG may document a slightly
more generalised version capable of working with stronger curves,
I have no actual worries in practice about Ed25519 as drafted.

The SHA-3 final round candidates are all technically better, but SHA-2
[despite its progenitors' murky reputation] is absolutely fine right
now as far as I know (except for length-extension, which isn't a real
issue here afaik).

There's no real need to get a 256-bit fingerprint from a 256-bit
public blob: you could just as well include the public key verbatim.
But given an SHA-256 hash has about the same strength as Ed25519, and
it's a fingerprint so matches existing practice with other SSHFP
records, it does no harm.

My only suggestion: prohibit using (weaker, deprecated) SHA-1
fingerprints with these newest (stronger) keys. [Just in case someone
mistakenly thinks it'd be a good idea.]

Other than that, as far as I'm concerned, stick a fork in it: it's
done, go ahead and get its public key RR type allocated.

- -- 
/akr

---

From: S Moonesamy <[email-masked]>
Date: Tue, 01 Apr 2014 11:47:47 -0700

Hi Alyssa,

Thanks for the feedback.

>I have no actual worries in practice about Ed25519 as drafted.

The implementation currently does not use SHA-3.  It's better not to 
do the above in this draft as it might require more discussion.

>mistakenly thinks it'd be a good idea.]

SHA-1 was mentioned on the SAAG mailing list.  I'll do the above in 
another draft as it is also applicable for other algorithm numbers 
and follow up on the SHA-3 comment.

Regards,
S. Moonesamy

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Apr 2014 15:24:50 -0500

On Tue, Apr 1, 2014 at 1:47 PM, S Moonesamy <[email-masked]> wrote:
> The implementation currently does not use SHA-3.  It's better not to do the
> above in this draft as it might require more discussion.

Saying "SHA-512 is clearly good enough for now" is OK, but "might
require more discussion" is just inviting... more discussion.  Maybe
you're in a hurry and we can quickly agree that SHA-512 will do, but
the door is open now to that discussion.

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 02 Apr 2014 09:33:04 -0400

> records, it does no harm.

SHA-256 is probably fine, but is it optimal?  would it be better to just
represent the full 256-bit key directly?  As a user, i'd be happy to be
able to know the full key without the digest, particularly if there is
no additional cost in network traffic.

What is the goal of using a digest for SSHFP records?  one rationale
could be for traffic reduction.

another could be avoiding direct public key exposure (on the grounds
that an attacker who doesn't know your key can't start a cracking
process) but given that ssh servers' public keys are hardly secret, i'm
not convinced this is a meaningful rationale.

Are there other reasons for using a digest algorithm here?  it seems to
introduce an additional possible point of cryptographic failure in the
key verification scheme (e.g. when used with DNSSEC, an attack can be
made against the digest mechanism used to sign the DNS records *or*
against the digest mechanism used in the SSHFP record itself).

I'm not up on the history or the spec of SSHFP, but if it doesn't
already exist, perhaps SSHFP needs a new hash type NONE for keys that
would fit in a DNS UDP response packet?

While the network-engineering aspect of this suggestion is probably
out-of-scope of the CFRG, i think questions about the cryptographic
merit or risk of an SSHFP "hash type NONE" record are probably in-scope.

	--dkg

---

From: S Moonesamy <[email-masked]>
Date: Thu, 03 Apr 2014 10:52:14 -0700

Hi Daniel,
>could be for traffic reduction.

The specification (RFC 4255) says that:

   "The fingerprint type octet describes the message-digest algorithm
    used to calculate the fingerprint of the public key."

This draft is making a request which is aligned with the (IANA) 
conditions set by the IETF.  The over-simplified answer is that the 
conditions cannot be changed through an Informational RFC.

>would fit in a DNS UDP response packet?

I could not find any discussion about this from the DNS side.  The 
issue about DNS payload size is related to the deployment of EDNS0 
(see RFC 6891).

>merit or risk of an SSHFP "hash type NONE" record are probably in-scope.

Input from cryptography experts or anyone else is welcome.  The 
(IETF) Security Area Director explained the angle which would be 
useful to him ( 
http://www.ietf.org/mail-archive/web/cfrg/current/msg04410.html 
).  In my opinion it is good to ask questions.

Regards,
S. Moonesamy