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

From: Greg Hudson <[email-masked]>
Date: Fri, 26 Oct 2001 18:01:41 -0400

> 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.
[...]
> Without a CERT, I can't be sure of the identity of the user. 

So, let me get this straight:

  A DNS APPKEY record retrieved via secure DNS is a key signed by the
  next level up in the DNS hierarchy.  An APPKEY record must have been
  signed by an irresponsible DNS administrator who got the public key
  from some other person by an unauthenticated path.

  A certificate is a key signed by the next level up in the
  certification hierarchy.  A certificate key must have been signed
  by a responsible CA who generated the key pair and transmitted the
  private key to some other person by a secret path.

That's a pretty impressive level of prejudice, given that the
technical mechanisms are identical.

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

---

From: "Andy W. Barclay" <[email-masked]>
Date: Sun, 28 Oct 2001 12:36:40 -0800

Sorry, let me clarify.

> technical mechanisms are identical.

As an individual, I can contact a certificate authority (like verisign),
and
provide that CA with a copy of my passport and a signed letter, and
whatever else they require, and they will issue me a certificate. I am
pretty sure that a CERT is simply a public key, signed by a CA.

I have just started a new job this week. If I generate an ssh key pair
and
ask the local admin to stick the public key into DNS, then the zone gets
signed.

I do assert, in this case, that the former case offers MUCH more
reliability than the latter. DNSSec does a good job of authenticating
data that is DNS related, but authentication at the application level
should be left to a CA.

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

Real Programmers don't write specs -- users should
consider themselves lucky to get any programs at all
and take what they get...

---

From: Greg Hudson <[email-masked]>
Date: Mon, 29 Oct 2001 00:20:17 -0500

> As an individual, I can contact a certificate authority (like
> verisign), and provide that CA with a copy of my passport and a
> signed letter, and whatever else they require, and they will issue
> me a certificate. I am pretty sure that a CERT is simply a public
> key, signed by a CA.

They also have to give you the private key, or you can't do anything
with the certificate.  I don't know how CAs usually transport private
keys to customers without exposing them to packet-sniffing or
interception by intermediaries.

How is Verisign supposed to know that I am authorized to change the
host key of error-messages.mit.edu (my laptop) but not www.mit.edu?

How can you justify the expense of performing a business transaction
with a third party for every host key created within an organization?
(This is more of a technology decision than a policy decision,
although the X.509 usage I know about has typically followed your
model where everyone transacts directly with the CA.)

> I have just started a new job this week. If I generate an ssh key
> pair and ask the local admin to stick the public key into DNS, then
> the zone gets signed.

First, this is an implementation issue.  No one says the ssh key pair
can't be generated by the DNS admin.

Second, this scenario seems perfectly secure in many circumstances,
e.g. at a small company where you just walked over to the DNS
administrator's desk and told him you were sending him your public
key.  That's much better authentication than anything you can give to
Verisign, and of course a DNS administrator can actually know who is
authorized to do what in the company.

---

From: Derek Atkins <[email-masked]>
Date: 29 Oct 2001 08:37:08 -0500

> interception by intermediaries.

Generally you generate the key pair yourself and send a "certificate
request" to the CA.  The CertReq contains your public key, your name
as _you_ think it should be, and some other information and self-signs
it (potentially along with a nonce or challenge value).  The CA then
somehow out-of-band verifies this CertReq against the meatspace
customer and then signs and returns the Certificate signed by the CA.

> host key of error-messages.mit.edu (my laptop) but not www.mit.edu?

This is indeed the problem -- c.f. Verisign signing a fake M$ Cert!

> > pair and ask the local admin to stick the public key into DNS, then

Andy, I don't understand what's wrong with this?  When I started my
last job I had to wait to get my new host into the DNS; I had to wait
to get my account into NIS; I had to wait to get my mail aliases into
sendmail's db.

I think you are blowing the onus of sending an SSH key to the DNS
admin out of proportion.  I think most enterprises already have
delegated administration to handle these things.  Certainly the last
three places I've worked (from 18 to 10,000 employees) would all have
been able to handle this without a problem.

And note that you do NOT need to resign a complete zone when you make
one change; you only seen to sign the subset of the zone that actually
changed!  If you already have an A record and you add a CERT record,
then all you have to do is sign the CERT and re-issue the NXT.  That's
only two signatures you need to make to perform that change.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Oct 2001 12:59:16 -0500

It seems to me that the the important debate in this thread is whether or
not DNS is an appropriate mechanism for distributing security data
(specifically public keys).  Although there are no technical barriers to
the addition of data and data types to DNS (within constraints), there is a
division over whether the distribution of security data is within DNS
bounds or is an overextension of the original protocol.

I suspect the resistance to the development of new records for keys (APPKEY
for one) comes under the heading of "since key management is too difficult
for DNS operatrors, let's not give them a record (rope) to hang
themselves."  I can understand this attitude, even if the pro-new records
camp insists that the distribution of PKI output does not make DNS a PKI.

My suspicion is that issuing genuine PKI certificates (PGP, X.509) in DNS
is acceptable to even those who fear turning DNS into a PKI.  The trouble
is in trusting whether operators can be trusted to handle keys well enough
for other protocols.  (We assume they can be trained to at least secure
DNS.)

Whether or not an application can place its trust in DNS to handle raw
public keys is really an application-by-application issue.  The DNS issue
is whether or not to support applications that can live by DNS key
management rules.

As far as SSH is concerned - and perhaps this should really be discussed in
an SSH forum and not DNS - we need to determine the relationship between
the person responsible for deriving the hosts public key and registering it
(and the address record) in the DNS.  Cutting a long analysis short, I
think in the majority of instances, the relationship is close as the nature
of the data (host based) is close.  (Who would be the CA that would vouch
for the host public key?)

Perhaps in another application, one which is user based, the relationship
between the generator of the public key and the DNS administrator is
further apart.  In this case, DNS management of the public key is less wise
- and where the CERT record should hold the certificate that should be in
place.

Where do I expect to see go to next?  Deciding if we want to supply the
rope for applications, should they choose to hang themselves is the first
step.  It might be beneficial for SSH-interested folk to determine if
having the keys in DNS is a good thing, or it SSH would benefit more from a
true certificate system.  Perhaps others might want to suggest and study
this issue for other applications.

If DNS isn't the place to distribute public keys, perhaps the key
distribution people have to run off and work on a key distribution
mechanism.  This could be a schema in LDAP and NAPTR records, or it might
not.

If it comes down to adding more to DNS or keeping DNS simple and
complicating the lives of applications (say adding NAPTR and LDAP), what
choice should be made?  Is the (relative) simplicity of DNS important
enough to force more work on the applications?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.

---

From: "Andy W. Barclay" <[email-masked]>
Date: Mon, 29 Oct 2001 10:13:58 -0800

Let me see if I can bring this back on track a little.

> Greg Hudson <[email-masked]> writes:
.... snip derek's info on certs - its correct .....
> This is indeed the problem -- c.f. Verisign signing a fake M$ Cert!

Right, but I don't think this is a DNS issue.

..... snip stuff on waiting to get info into various name services....

> been able to handle this without a problem.

Thats not my point at all. Please see the note at the bottom.

> only two signatures you need to make to perform that change.

Right, but it doesn't affect what my argument is.

Its obvious that I didn't make my point clear. A while back, Jeffrey
Altman wrote:

> > 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?

I think this is completely do-able and its JUST as secure as what
happens
today (first time you connect, there is a key transfer). BUT, a pki
requires a strict process to be followed and its only as strong as its
weakest link. If you allow people to submit via an insecure channel,
then
you can sign that data to your hearts content, and you will get no more
security.

In summary, if I was an application developer, I would USE the key data
in DNS, and I would probably rely on it for privacy assurance, but not
for authentication.

Don't order a drink for the road, because the road is
already laid out.
   --Flip Wilson