Re: Evaluation: draft-ietf-secsh-dns - Using DNS to securely publish SSH key fingerprints

["Steven M. Bellovin" <smb@research.att.com>]

In message <20030807163809.2402218E3@thrintun.hactrn.net>, Rob Austein writes:
>At Thu, 07 Aug 2003 12:13:24 -0400, Thomas Narten wrote:
>> 
>> >                       Yes  No-Objection  Discuss  Abstain
>> > Thomas Narten        [   ]     [   ]     [ X  ]     [   ]
>> 
>>    The approach suggested here shifts the burden of key checking from
>>    each user of a machine to the key checking performed by the
>>    administrator of the DNS recursive server used to resolve the host
>>    information.  Hopefully, by reducing the number of times that keys
>> 
>> Don't understand. Key checking is performed by software, not the
>> administrator...
>
>i don't seem to have received the message to which thomas's message
>was a response, so i don't know to whom i'm speaking, but:
>
>a) the main point of the secsh thing is to piggyback on the (as yet
>   nonexistant) dnssec infrastructure; there may be certain limited
>   scenrios in which one could use it without dnssec, but i'd prefer
>   not to go there
>
>b) dnssec validation is performed by software, and that software is
>   not necessarily performed by a recursive name server, in fact there
>   are trust model issues with doing it that way.  see
>   draft-ietf-dnsext-dns-threats-03.txt (blush)
>
>c) checking the ssh key itself is presumably performed by whoever
>   inserted the ssh key into the dns in the first place (zone admin,
>   or secure dynamic update user, or ...)
>
>i suspect that the original comment was thinking about (c).
>
Yah.  Today, the user is supposed to check the key fingerprint manually 
on first use.  This allows the administrator to put the fingerprint in 
a trustable repository, to wit a dnssec-protected RR.  So yes, it 
really does move the burden to software from the user.


		--Steve Bellovin, http://www.research.att.com/~smb