openssh unix dev - Nov 2011 - ssh-keygen -r should support SSHFP records for ECDSA (or at least return non-zero error code on failure)

hi folks:

it looks like ssh-keygen -r can''t export SSHFP records for ECDSA keys:

0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P
''''
0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub
export_dns_rr: unsupported algorithm
0 dkg@pip:/tmp/cdtemp.oiRYAS$

the first number in my prompt is the return code of the last command;
note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it returns 0.

at the least, it should return non-zero on failure.


I note that the relevant RFC doesn''t include an enumeration for ECDSA:

 https://tools.ietf.org/html/rfc4255#section-3.1.1

Could anyone on this list kick off the IETF process for allocating a new
ID in that registry for ECDSA?  I''m not currently involved in the
IETF''s
Network Working Group so i don''t really know the political landscape
there.

Regards,

	--dkg



_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi Daniel,

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> hi folks:
> 
> it looks like ssh-keygen -r can''t export SSHFP records for ECDSA
keys:
> 
> 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P
''''
> 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub
> export_dns_rr: unsupported algorithm
> 0 dkg at pip:/tmp/cdtemp.oiRYAS$
> 
> the first number in my prompt is the return code of the last command;
> note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it returns 0.
> 
> at the least, it should return non-zero on failure.
> 
> 
> I note that the relevant RFC doesn''t include an enumeration for
ECDSA:
> 
>  https://tools.ietf.org/html/rfc4255#section-3.1.1
> 
> Could anyone on this list kick off the IETF process for allocating a new
> ID in that registry for ECDSA?  I''m not currently involved in the
IETF''s
> Network Working Group so i don''t really know the political
landscape there.
I believe that the SSH development community will need to support this
effort:

  http://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2-00

which specifies values for both the ECDSA algorithm and a SHA-256
fingerprint algorithm.

RFC 4255 enumerates the RSA and DSS algorithms and the SHA-1 fingerprint
type.

draft-os-ietf-sshfp-ecdsa-sha2-00 authored by O. Sury has a typo in the
draft suggesting that they update RFC 4225 which is wrong, but it seems
to be a simple typo as the body of the draft referecnes RFC 4255.

However, it does add ECDSA to the SSHFP RR types and SHA-256 to the
fingerprint types.

The draft expires on Dec 18, 2011.

This draft was sent to saag at ietf.org and the author also wrote a patch
for OpenSSH (portable) in

https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/ssh-sshfp-ecdsa.patch

See the message thread here:

  http://www.ietf.org/mail-archive/web/saag/current/msg03326.html
  http://www.ietf.org/mail-archive/web/saag/current/msg03327.html

Stephen Farrell <stephen.farrell at cs.tcd.ie> says that the author is
asking the AD to sponsor the work. And Warren Kumari <warren at
kumari.net>
has added his support.

This seems like something that should be raised on the
ietf-ssh at NetBSD.org list with a CC to saag at ietf.org, so
I have added these to lists to my response to this message.

For the record, my vote is +1 for this draft.

	-- Mark

Thanks Mark,

Yes, I''m happy to AD sponsor. No one objected when I asked
before and it seems quite reasonable.

Ond?ej - I''ll start an IETF LC since there only seem to be
typos to be fixed.

Cheers,
S.

On 11/23/2011 06:06 AM, Mark D. Baushke wrote:
> Hi Daniel,
>
> Daniel Kahn Gillmor<dkg at fifthhorseman.net>  writes:
>
>> hi folks:
>>
>> it looks like ssh-keygen -r can''t export SSHFP records for
ECDSA keys:
>>
>> 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P
''''
>> 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub
>> export_dns_rr: unsupported algorithm
>> 0 dkg at pip:/tmp/cdtemp.oiRYAS$
>>
>> the first number in my prompt is the return code of the last command;
>> note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it
returns 0.
>>
>> at the least, it should return non-zero on failure.
>>
>>
>> I note that the relevant RFC doesn''t include an enumeration
for ECDSA:
>>
>>   https://tools.ietf.org/html/rfc4255#section-3.1.1
>>
>> Could anyone on this list kick off the IETF process for allocating a
new
>> ID in that registry for ECDSA?  I''m not currently involved in
the IETF''s
>> Network Working Group so i don''t really know the political
landscape there.
>
> I believe that the SSH development community will need to support this
> effort:
>
>    http://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2-00
>
> which specifies values for both the ECDSA algorithm and a SHA-256
> fingerprint algorithm.
>
> RFC 4255 enumerates the RSA and DSS algorithms and the SHA-1 fingerprint
> type.
>
> draft-os-ietf-sshfp-ecdsa-sha2-00 authored by O. Sury has a typo in the
> draft suggesting that they update RFC 4225 which is wrong, but it seems
> to be a simple typo as the body of the draft referecnes RFC 4255.
>
> However, it does add ECDSA to the SSHFP RR types and SHA-256 to the
> fingerprint types.
>
> The draft expires on Dec 18, 2011.
>
> This draft was sent to saag at ietf.org and the author also wrote a patch
> for OpenSSH (portable) in
>
>
https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/ssh-sshfp-ecdsa.patch
>
> See the message thread here:
>
>    http://www.ietf.org/mail-archive/web/saag/current/msg03326.html
>    http://www.ietf.org/mail-archive/web/saag/current/msg03327.html
>
> Stephen Farrell<stephen.farrell at cs.tcd.ie>  says that the author
is
> asking the AD to sponsor the work. And Warren Kumari<warren at
kumari.net>
> has added his support.
>
> This seems like something that should be raised on the
> ietf-ssh at NetBSD.org list with a CC to saag at ietf.org, so
> I have added these to lists to my response to this message.
>
> For the record, my vote is +1 for this draft.
>
> 	-- Mark
> _______________________________________________
> saag mailing list
> saag at ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

FYI, there is a patch for linux port of OpenSSH to support
draft-os-ietf-sshfp-ecdsa-sha2-02

https://github.com/oskar456/ietf/raw/master/ssh-sshfp-ecdsa.patch

This patch is created against OpenSSH 5.8p1, but can be applied, after
minor adjustments, even to latest snapshot openssh-SNAP-2011112, or
non-portable version of OpenSSH.

There is only one potential problem - if server offers a certificate and
key embedded in certificate match a SSHFP record, host is considered
authenticated without considering certificate. Maybe better would be to
do all checks with certificate first and then continue on all checks
with embedded key alone. But this would requre a major redesign of
sshconnect.c.

Also I think it would be nice to change default for option
VerifyHostKeyDNS to ask. This setting should be always safe, regardless
of local DNS resolver trustworthy.

Regards,
Ondrej Caletka


Dne 21.11.2011 16:29, Daniel Kahn Gillmor napsal(a):
> hi folks:
> 
> it looks like ssh-keygen -r can't export SSHFP records for ECDSA keys:
> 
> 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P
''
> 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub
> export_dns_rr: unsupported algorithm
> 0 dkg at pip:/tmp/cdtemp.oiRYAS$
> 
> the first number in my prompt is the return code of the last command;
> note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it returns 0.
> 
> at the least, it should return non-zero on failure.
> 
> 
> I note that the relevant RFC doesn't include an enumeration for ECDSA:
> 
>  https://tools.ietf.org/html/rfc4255#section-3.1.1
> 
> Could anyone on this list kick off the IETF process for allocating a new
> ID in that registry for ECDSA?  I'm not currently involved in the
IETF's
> Network Working Group so i don't really know the political landscape
there.
> 
> Regards,
> 
> 	--dkg
> 
> 
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4471 bytes
Desc: Elektronick?? podpis S/MIME
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20111129/6af854ee/attachment.bin>