Subject: Re: Admitting more documents: application keys in DNS

From: Jeffrey Altman <[email-masked]>
Date: Fri, 26 Oct 2001 14:09:29 EDT

> > I'm completely ambivalent on the RR or usage, other than I have a general
> > belief that this kind of stuff does not fit well within a lookup service like
> > DNS anymore than it would fit well within ARP.
> 
> I think we are going to have to agree to disagree on this one.
> If SSH is already looking up the A record to connect to a host,
> why not lookup the CERT/APPKEY record to connect securely to
> that host?
> 
> -derek

I can think of one reason.  If you do not have a copy of the SSH key
in your possession from some trusted source, the copy of a key that
you receive from untrusted DNS is of no more value than the copy of
the key you will receive from the server you are attempting to connect
to.  If you trust the DNS entry to say that the host is the one you
want to connect to, you might as well get the host key from the SSH
server.

All that putting the SSH key in untrusted DNS does is increase the
amount of administration that must be performed when a host key must
be changed for legitimate reasons.

- Jeff

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 26 Oct 2001 15:16:08 -0500

Derek Atkins wrote:

> Nothing in the DNS Spec says that you MUST cache data, and nothing
> says that you MUST keep it as long as the TTL.  The TTL is a MAXIMUM
> length, not an exact length.  If your cache gets too big, flush
> entries.

Nothing to do with size of the cache, and everything to do with old keys
hanging around in somebody's cache. Until the cache expires, the key you
have hoses your app. There are two options around this: don't cache it, or
let clients demand authoritative answers. Both suck for the cache-heavy,
lookup-centric DNS model.

> As for message size, you do realize that this is all end-node data,
> not in the core?  The core/root servers aren't storing the foo.com
> keys -- those are in the foo.com DNS servers.

If it will always overflow, then you will always need to fallback to TCP.
For infrequent operations that's not a big deal but for frequent uses it
adds up pretty quickly, especially on busy servers where TCP puts a much
larger burden on the system.

I'm not claiming that these issues are worthy of preventing the use of the
RR, but they are certainly valid considerations.

> why not lookup the CERT/APPKEY record to connect securely to

Equally, why would you want to do so? I mean, at that point, why not just
store SSH profiles in DNS as well?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Andy W. Barclay" <[email-masked]>
Date: Fri, 26 Oct 2001 13:41:00 -0700

I agree with Jeff with one possible change: "s/untrusted//g"

If I get an ssh key from DNS, even if that key has been signed
by DNSSec, then I still can't trust it. Why? Because I can be pretty
sure that the user generated his/her own key pair, then forwarded
the public key to the admin for inclusion to the DNS.
The admin has just included the key in the zone and signed it.

All I can be sure of is that the key has not been changed in transit.
Without a CERT, I can't be sure of the identity of the user. 

--
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

"So she went into the garden to cut a cabbage leaf to make an
apple pie; and at the same time a great she-bear, coming up 
the street pops its head into the shop. 'What! no soap?'
So he died, and she very imprudently married the barber; and 
they all fell to playing the game of catch as catch can; til
the gunpowder ran out at the heels of their boots.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 31 Oct 2001 08:44:26 -0800

As you say, SSH is solving a closed loop problem.

Why involve DNS at all? Why not extend the yellow pages system? Why not use
the SRV or NAPTR mechanism to connect to a protocol designed to deliver
authenticated keys?

Any facility that is put into DNS will be assumed to be for general use.

	Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 11:56 AM
> To: namedroppers
> Cc: [email-masked]
> Subject: RE: Admitting more documents: application keys in DNS
> 
> 
> At 10:49 AM -0500 10/30/01, Hallam-Baker, Phillip wrote:
> >* The idea that we can turn the DNS system into a key distribution
> >	center is a very, very very bad one.
> 
> I understand your sentiment, but I think this is overstated.
> 
> >* The idea that we can use DNS to help locate key distribution
> >	centers is a good one.
> 
> For example, take SSH (as has been done repeatedly).
> 
> Assuming we use APPKEY, the risk is that the admin of the 
> host incorrectly
> interfaces with the admin of the zone.  The result is that at 
> sometime, the
> wrong key may be entered into DNS.
> 
> Assuming SSH derives a key distribution mechanism (other than 
> the server
> just sending the key), the first question SSH will have to 
> answer is "how
> will a server host key be validated?"  Once that is answered, the same
> issue arrives - will the practice of this be compromised?  The second
> question is how will SSH tell the client where to get the 
> key?  If DNS is
> used, the referral is as suspect as the key above.
> 
> SSH also has some other properties that make this issue 
> interesting.  One
> is that SSH is generally a closed-set protocol - the client 
> and server have
> preexisting relationships (accounts).  It doesn't seem 
> worthwhile to set up
> a large scale key management mechanism when given the option of DNS.
> (Everytime I've discussed this locally, we keep arriving at 
> the conclusion
> that such a system would just be enriching to CA interests - each
> organization would need to certificate-signing certificate, 
> and those are
> quite expensive.)
> 
> Looking at email and web security is a different matter.  In 
> these cases,
> the open-community nature is more ameanable to the higher 
> overhead (because
> of scaling problems).  In those instances, certificates make much more
> sense.
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
> 
> You fly too often when ... the airport taxi is on speed-dial.
> 
> Opinions expressed are property of my evil twin, not my employer.
> 
> 
> 
> 

------_=_NextPart_000_01C1622B.4D595360
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:(781) 245-6996 x227
EMAIL;PREF;INTERNET:[email-masked]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C1622B.4D595360--