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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 03 April 2014 15:45 UTC

Message-ID: <533C1190.2070901@fifthhorseman.net>
Date: Wed, 02 Apr 2014 09:33:04 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: Alyssa Rowan <akr@akr.io>, cfrg@irtf.org
References: <533AFA44.3070208@akr.io> <533AFF0F.6070705@akr.io>
In-Reply-To: <533AFF0F.6070705@akr.io>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="N4U92SRXJQ9ktqo1G659bh8fQlaqAhmgB"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/HvGvqd8VOh-qGpGHxVFOebhfRa4
Subject: Re: [Cfrg] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-01
Precedence: list

On 04/01/2014 02:01 PM, Alyssa Rowan wrote:
> 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.

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

Attachment: signature.asc

Re: [Cfrg] Using ED25519 in SSHFP Resource Record… Alyssa Rowan
Re: [Cfrg] Using ED25519 in SSHFP Resource Record… S Moonesamy
Re: [Cfrg] Using ED25519 in SSHFP Resource Record… S Moonesamy
Re: [Cfrg] Using ED25519 in SSHFP Resource Record… Nico Williams
Re: [Cfrg] Using ED25519 in SSHFP Resource Record… Daniel Kahn Gillmor
Re: [Cfrg] Using ED25519 in SSHFP Resource Record… S Moonesamy

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

Attachment: signature.asc