To:
Derek Atkins <warlord@MIT.EDU>
cc:
Keith Moore <moore@cs.utk.edu>, Ted.Hardie@nominum.com, Edward Lewis <lewis@tislabs.com>, keydist@cafax.se
From:
Keith Moore <moore@cs.utk.edu>
Date:
Wed, 09 Jan 2002 17:11:11 -0500
In-reply-to:
Your message of "09 Jan 2002 16:49:30 EST." <sjmy9j7mbyt.fsf@indiana.mit.edu>
Sender:
owner-keydist@cafax.se
Subject:
Re: From whence we came...
> > While I wouldn't mind having the ability to verify ssh keys using > > DNSSEC, I wouldn't necessarily want DNSSEC verification axiomiatically > > treated as valid by ssh. > > This is an application/user decision. One would hope that the > application designer would give you this option. However that does > not invalidate the usefulness of DNSSec as stated. I have no doubt that DNSSec can be useful. I do doubt that DNSsec should be the only (or even primary) mechanism for verifying keys for DNS-based names. Just to give a (hopefully noncontroversial) example, I wouldn't be likely to trust a key for the UTK.EDU zone because the University has a difficult time keeping competent people on its payroll (this has something to do with substandard salaries and stressful working conditions being used by the legislature as a mechanism to encourage citizens to accept a state income tax). Even though competent people are sometimes assigned such duties, the responsibility for maintaining our DNS zones tends to shift arbitrarily and without regard for the security implications of such decisions. So I don't think it's likely that they'd adequately safeguard such keys against compromise. I'd trust a key for the CS.UTK.EDU zone only if I'd verified it out-of-band - not based on any signature from the UTK.EDU zone. Similar concerns could apply to any other zone. > > And this is still a different issue from putting ssh keys directly > > in DNS. > > Oh? Why? because of previously-stated limitations in the DNS protocol. (though since email doesn't preserve message ordering, you may not have received that message yet) Keith