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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 30 Oct 2001 07:23:10 -0800

> I don't believe I ever made that argument.  Perhaps someone else made
> that argument, or perhaps I unintentionally said something which
> sounded like that.  What I was trying to say is:
> 
>   * APPKEY is only about fetching keys out of DNS, not putting them
>     in.  There is lots of room to do either a good job or a bad job at
>     getting keys into the DNS; people should limit themselves to
>     imagine one particular procedure.
> 
>     At no point did I mean to imply that I was eminently qualified to
>     develop procedures to put keys into the DNS, or that the IETF
>     should try to standardize those procedures.

Excuse me? If you don't know what you are talking about why are you
taking our time arguing?

Your proposal introduces a whole new assumption into the security
architecture, that DNS is a secure key distribution center.

I don't think it is unreasonable to expect an explanation of how that
administrative state of affairs can be achieved.

		Phill 

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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 30 Oct 2001 10:42:27 -0500

> Excuse me? If you don't know what you are talking about why are you

This is getting downright abusive.  You've had some good points; you
should stick to them.

> architecture, that DNS is a secure key distribution center.

It's not my proposal.  (But perhaps you meant that term loosely.)

It's not a whole new assumption.  RFC 2535 states:

   The KEY resource record (RR) is used to store a public key that is
   associated with a Domain Name System (DNS) name.  This can be the  
   public key of a zone, a user, or a host or other end entity.

Other parts of RFC 2535 state that they definitely have applications
in mind beyond DNSSEC.  APPKEY merely extends the KEY RR to use 24
bits for the protocol (16 bits for the protocol name and 8 bits for a
version) instead of 8.

> I don't think it is unreasonable to expect an explanation of how
> that administrative state of affairs can be achieved.

I think it is sufficient to show that there is no technical obstacle
to developing good procedures.  Are you seriously arguing that there
can be no good way to get key information from individuals within an
organization to the organization's DNS server?

I can certainly give an example.  At MIT, we have a
Kerberos-authenticated database which is used to generate the zone
files for the DNS servers.  Users already have access to edit data
about hosts they control; they could have the privilege of editing the
(just for example) ssh public key of hosts they control.  Since
Kerberos and this database are both mission-critical, any compromise
of their security can already do more damage than compromising any
number of host keys.