[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [resend] Use of DNS to distribute keys


From:  atkinson@itd.nrl.navy.mil (Ran Atkinson)
To:  ipsec@ans.net, namedroppers@nic.ddn.mil
>	For several years now I've been thinking that the DNS is
>probably a really good way to distribute keys (or key certificates).
>For example, if each host had a public key accessible via the DNS, one
>could more easily setup a secure session key between oneself and the
>remote host that one wished to communicate with.  Also, one might be
>able to encrypt UDP packets using asymmetric encryption for the odd
>case where one only wanted to send one or two packets and thereby
>avoid the overhead of setting up a session key for extremely brief
>sessions.

This is a great idea I have also had myself.  Key certificates are
generally too big and clunky to be in DNS but public keys would work
fine.  There is no reason for the keys stored in DNS to be embedded in
a certificate because you can use secure communication with the DNS
server based on the key from the next highest level in the DNS
hierarchy.  Caching these keys is kind of like caching IP address
info.  All you need to complete the picture is to magicly know (or get
via an e-mailed certificate or something) the public keys of the root
DNS servers.

Its not clear to me that UDP and similar datagram protocols are so
rare and some such packets (consider ICMP, IGMP, etc) are very
important to be able to at least authenticate..  Furthermore, it would
be very useful to authenticate the source of multicast messages where
a negotiated "session" key is impractical.  The most obvious extention
to encrypting multicast traffic would require putting the multicast IP
address in DNS (are number are in there already) and all the receivers
authorized to get the traffic knowing the private key.

Assume you have an IP security protocol with SAIDs (security
association IDs).  Mostly these would be for negotiated TCP like
exchanges with a session key, etc.  But you should permantently
allocate some "global" SAIDs to mean a particular algorithm family
with particular non-negotiated keys such as from DNS.  Note that you
might even want to use such global SAID authenticated/encrypted
packects as the initial packets in setting up a negoitated SAID so
that *none* of your packets are in the clear.

>...

>Thanks,
>Ran
>atkinson@itd.nrl.navy.mil

>To: atkinson@itd.nrl.navy.mil (Ran Atkinson)
>Subject: Re: Use of DNS to distribute keys 
>Date: Tue, 07 Sep 93 09:56:59 -0700
>From: Dave Crocker <dcrocker@Mordor.Stanford.EDU>
>
>    ---- Included message:
>
>    	For several years now I've been thinking that the DNS is
>    probably a really good way to distribute keys (or key certificates).
>
>Let me ask a related question:
>
>One of the marks of distinction about the DNS, relative to X.500, DEC's
>Name Service, OSF's Cell Directory Service, and most discussions about
>network use of directory service, is that is is used in very, very
>limited ways.  I suspect that limiting the use to name/address
>mapping has been instrumental in making it feasible to rely on
>DNS access as part of the operational infrastructure.

It is also used for name/name mapping but I agree entirely that the
success of DNS, like many IETF protocols, is based on aiming at a
relatively narrow goal.  But it seems to me that for secure
host-to-host communications via a public key system, DNS is on target.
A 1024 bit RSA key, which most people consider secure, is only 128
bytes.  An appropriate RSA digital signature is going to be about the
same size.  I guess I should do the detailed arithmetic but it seems
to me like a public key containing DNS response should fit into the
DNS 512 bytes UDP limit.

>...

>Dave

>To: Dave Crocker <dcrocker@mordor.stanford.edu>
>Cc: atkinson@itd.nrl.navy.mil (Ran Atkinson), namedroppers@nic.ddn.mil,
>        ipsec@ans.net
>Subject: Re: Use of DNS to distribute keys 
>Date: Tue, 07 Sep 1993 12:33:49 -0600
>From: Brad Huntting <huntting@glarp.com>
>
>I dont see anything wrong with putting more "host related information"
>in DNS.  What's dangerous is to try to extend the idea "domain
>name" to include more than just "things with IP addresses", "things
>that appear after the @ in email addresses", and "administrative
>breakpoints".
>
>In other words, it might be risky to add PEM information to DNS,
>but it would probably not be risky to ad IP security information
>to DNS.

I agree.

>brad


Donald
Follow-Ups: References: