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

From: Jakob Schlyter <[email-masked]>
Date: Fri, 26 Oct 2001 15:14:48 +0200 (MEST)

On Fri, 26 Oct 2001, James Seng/Personal wrote:

> Therefore, putting a digital cert or public key into DNS does sound
> excess to me. Putting a reference to a digital cert on the other hand
> seem reasonable. And that can be done somewhat using the existing
> NAPTR RR.

storing the data outside dns would give you a large bootstrap problem. how
do you securly fetch the data referenced?

I believe this is one of the most important reasons for storing public
keys and certificates in dns and secured by dnssec.

	jakob

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

---

From: Michael Mealling <[email-masked]>
Date: Fri, 26 Oct 2001 09:16:23 -0400

> do you securly fetch the data referenced?

Currently any modern operating system plus nearly all embedded ones have
support for one and probably two application layer protocols (http and 
possibly LDAP). I don't know of any OS or device that simply has _only_
DNS and no other available protocols. I don't understand the bootstrapping
issue here. You use DNS to get a NAPTR and/or SRV record to find out where
the server is that has the CERT/KEY and then you use one of those 
other protocols to contact it. I have yet to run across a platform that
can't do that just about out of the box with existing APIs.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: Randy Bush <[email-masked]>
Date: Fri, 26 Oct 2001 07:33:38 -0700

what is really being asked is how much are we willing to stuff in the
dns to make up for the apps folk's inability to field usable directory
services and the security folk's inability to field a usable pki?

as the dns is not ideally structured for either, is bending dns to
compensate for apps's and security's shortcomings.  not good
architecture and hence likely to result in unpleasant surprises.

so what lessons have we learned in dns-land that might help apps and
security do their job?

randy

---

From: Edward Lewis <[email-masked]>
Date: Fri, 26 Oct 2001 10:32:06 -0400

It seems to be that we are arguing over points to which we won't be able to
come to an agreement on.

On the one one hand, DNS is a very important piece of the infrastructure so
it should be as simple and fast as possible.  We don't want software
meltdowns and we don't want it to be a bottleneck.  Any additional services
should be shunted off to other processes - essentially compartmentalizing
and simplifying the code, etc.

On the other hand, extending the types held by DNS does not alter the
software (outside of the text-to-binary conversions) and doesn't exactly
add much to the server load - as any lookup for data in another service
requires the use of DNS to locate the service.  In addition, there is no
other scaleable alternative to DNS for the distribution of information.

Personally, I side with adding new types to DNS (so long as there is no
extra processing needed).  I can't see how this is a technical problem for
DNS.  However, I can't see anyway of "proving" that the addition of new
types is superior to the alternative approach.

While it is fine to have protracted threads arguing this again and again
(;)), it might be time if the WG sought an opinion from a higher power
(IESG/IAB) on what the criteria for new types are.  Perhaps the answer is
to just propose the new types and see what progresses through the standards
process.  Perhaps the answer is to develop a statement on the future
directions of name service.  I don't know - but I do know that we waste a
lot of bandwith on this topic.

I would like to hear from folks who want to limit the growth of type
definitions on this question.  While I realize there is an alternative to
adding a new type (say APPKEY), what technical problems are created by it?
Do you object to 1) exhaustion of the type space, 2) an increased load on
servers (queries, data), 3) more documents to process?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Greg Hudson <[email-masked]>
Date: Fri, 26 Oct 2001 10:59:10 -0400

> what is really being asked is how much are we willing to stuff in
> the dns to make up for the apps folk's inability to field usable
> directory services and the security folk's inability to field a
> usable pki?

Uh, when did directory services come up?  I haven't seen the APPKEY
people asking for anything more than simple lookup.

> as the dns is not ideally structured for either

A few people often say that as if it's true by inspection (as applied
to pki).  I think DNS makes a fine online PKI, with many nicer
properties than the offline X.509 infrastructure currently used for
the web.  For instance, the certificate revocation problem can be
sidestepped by providing keys which expire after a relatively short
people of time (an hour, or a day, depending on how well you can
handle the load), and having people re-query for them whenever they
expire.  With sufficient application support, you can also accomplish
smooth key rollover by providing multiple APPKEY RRs at the same
domain.

If you see problems with the use of APPKEY, make specific arguments,
not vague generalities.

---

From: Randy Bush <[email-masked]>
Date: Fri, 26 Oct 2001 08:13:17 -0700

> the web.

the pki i use today, the public pgp keyring, is not a hierarchic name space.

randy

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Oct 2001 17:32:56 +0200

> architecture and hence likely to result in unpleasant surprises.

I'm not sure this is entirely the whole truth -- I think what we are
seeing is that a fundamental requirement to achieve a secure Internet
is that the same entity that provides "name" to "address" mapping
(DNS, that is) provides the "name" to "security material" mapping.

In the old times, all you need to talk with someone was the address of
that someone.  Today you need the address and some keying material so
that you can talk to the someone securely.  I don't believe decoupling
the name->address mapping (DNS) and name->key mapping (e.g. LDAP,
possibly via DNS referrals) cannot work reliably in a scalable way.
(Of course, please prove me wrong, I'd even like to work on proving
this wrong.)

I believe solving this problem outside of DNS would require replacing
DNS with something else that can map names to addresses.  Which might
be a good thing in itself, but I guess that would be less trivial.

---

From: Derek Atkins <[email-masked]>
Date: 26 Oct 2001 11:35:01 -0400

> the pki i use today, the public pgp keyring, is not a hierarchic name space.

The signatures certainly don't follow a hierachy, but the lookup
mechanism, the userID, most certainly does (for any real-world usable
key).  When you look up my PGP key, you look it up via
"[email-masked]".  I look up yours via "[email-masked]".  Those
lookups are EXTREMELY hierarchical, in the same way my mailer has to
lookup the MX/A record for psg.com and yours needs to lookup the MX/A
records for MIT.EDU.

> randy

-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: Randy Bush <[email-masked]>
Date: Fri, 26 Oct 2001 08:38:26 -0700

> I think what we are seeing is that a fundamental requirement to
> achieve a secure Internet is that the same entity that provides
> "name" to "address" mapping (DNS, that is) provides the "name" to
> "security material" mapping.

a hidden and suspect assumption, the name space of security material is
the same as the dns name space.  i suspect that, as time passes, a
smaller and smaller proportion of interesting security material will be
about domains and hosts.

> that you can talk to the someone securely.

where in the dns space does my pgp key fit so naturally and elegantly?
(note the From: and that my key is Randy Bush <[email-masked]>)

randy

---

From: Michael Mealling <[email-masked]>
Date: Fri, 26 Oct 2001 11:30:07 -0400

> other scaleable alternative to DNS for the distribution of information.

I'm not arguing that we should limit the number of RR types in the DNS.... 

> servers (queries, data), 3) more documents to process?

My objection isn't that a new RR is added, but that the usage profile
of new functionality that requires that RR is inconsistent with previous ones. 
By putting keys/certs in the DNS you've turned the DNS into a data store
for end point information, not a pointer to that information. It changes
the ratio of the amount/number of queries in/to a nameserver to 
the members of an administrative domain from 1:<very many> to 1:1.

I.e. its no the RR that's the problem. Its the increase in the usage profile
that's the problem....

-MM

---

From: Randy Bush <[email-masked]>
Date: Fri, 26 Oct 2001 08:48:58 -0700

> key).

useful pgp is not restricted to email addresses as ids.

randy

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Oct 2001 18:07:36 +0200

> smaller and smaller proportion of interesting security material will be

I don't believe so, people will continue to use tools to communicate,
and they need to trust those the machines.  (What would the larger
proportion of interesting security material be about?  Persons?)

> (note the From: and that my key is Randy Bush <[email-masked]>)

It belongs in the same domain as the MX record used to find your mail
server, which is found via the address you give to someone in order
for that someone to be able to contact you.  E.g., if your business
card contains X@Y the security data should be at X._mail.Y.  I fail to
see how the From: line has anything to do with anything (you don't
need to send mail from the same address you receive it to).

(This is probably of little technical value, I'm sorry I started this
part of thread.)

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 26 Oct 2001 11:14:45 -0500

> If you see problems with the use of APPKEY, make specific arguments,

Looking at it in the context of my list of considerations for DNS data, the
two concerns that immediately jump out are message size and cache integrity.
It seems that overflow will likely be common. Controlling the expiration of
cached keys is a bit trickier. TTLs would have to be very tightly managed in
order to ensure the veracity of the RRs in caches, which would likely be
required if the original key was changed for some reason. I'm not sure how
much of a problem either of those really are, they just jump out as probable
concerns.

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.

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 26 Oct 2001 09:25:43 -0700

> server

no problem.  dear dns admin of att.com, please insert my pgp key for
[email-masked] (and 100,000 others and shrinking) in the dns for att.com.
and pigs will fly.

and email addresses have an lhs.  you can twist and turn all day, but this
is not a clear mapping.

randy

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Oct 2001 18:46:41 +0200

> [email-masked] (and 100,000 others and shrinking) in the dns for att.com.

If the DNS administrator do not publish their users' certificates it
is not going to work.

But I don't see how it would be easier to get the LDAP admins of
att.com to enter the PGP key for [email-masked] in the directory AND
the DNS admins to insert SRV glue in DNS to point at this server?  The
latter is even less secure (where do I get the keys used to talk with
the LDAP server securely?).

> and email addresses have an lhs. you can twist and turn all day, but
> this is not a clear mapping.

What about the SOA mapping?  It is supposedly used by some registries
to contact hostmaster in a automated fashion.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 26 Oct 2001 12:04:21 -0400

>I.e. its no the RR that's the problem. Its the increase in the usage profile

I would like a little more specific information on this.  How does the
usage profile differ between an MX record and the proposed APPKEY record?
In both cases I know where I want to send mail/where I want to get a key
and I ask for the information.  In the MX case, I use the result for the
email MTA application, in the other I use the result for validating an SSH
key offerering.

I applogize for seeming to be argumentative, but perhaps I am
misinterpreting the phrase "usage profile."

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Oct 2001 19:11:30 +0200 (CEST)

On Fri, 26 Oct 2001, Eric A. Hall wrote:

> Looking at it in the context of my list of considerations for DNS data, 
> the two concerns that immediately jump out are message size and cache 
> integrity.

Thank you for providing technical arguments against the approach.

> It seems that overflow will likely be common.

When I investigated it, I came to the conclusion that overflow will almost 
always happen -- X.509 certificates used for email purposes seem to be 
around 600-1200 bytes (of course exceptions exists), larger than the IPv4 
UDP limit.

I believe draft-ietf-dnsext-message-size-04.txt addresses this concern 
though.

> Controlling the expiration of cached keys is a bit trickier. TTLs
> would have to be very tightly managed in order to ensure the veracity
> of the RRs in caches, which would likely be required if the original
> key was changed for some reason.

For certificates: Revocation is not handled by DNS at all.  I believe the 
TTL can in fact be _much_ longer than usual, since it is known at time 
when you enter the certificate into DNS how long it will be valid 
(expirytime).

For raw application keys: This is a problem.  However, if this is a real 
problem for the application, it can use certificate based key distribution 
instead.  It isn't necessarily a problem for all applications.

> I'm not sure how much of a problem either of those really are, they
> just jump out as probable concerns.

IMHO it would be good to have the set of concerns people have written 
down so it is possible to address them, your list is a good start.

---

From: Mark Gritter <[email-masked]>
Date: Fri, 26 Oct 2001 10:31:20 -0700

I'm afraid I don't follow the reasoning here.  You seem to be making the
assumption that one lookup of NAPTR (or whatever other pointer-to-where-
you-should-go-to-get-keys exists) is shared among many key lookups.

Is this a realistic assumption?  What sort of mapping from key ID -->
domain name are you imagining?  If different keys map to different domain
names, then there is no reduction in queries other than that provided
by caching.  For example, if we want to store SSH keys, then it is
not possible to assume that a key pointer at "dsg.stanford.edu"
is the right place to look for keys for "erdos.dsg.stanford.edu".
So there are at least some circumstances in which the extra level of
indirection provides _no_ savings.

Further, I think that the increased usage profile is only a problem if
you look at just DNS.  _Something_ is going to have to handle the load
of key lookups, so I can't imagine there will be much benefit in handing
the server side off to another process--- in many sites it would just be
the same machine.  The load on recursive name servers is an issue, and
I agree that any proposal would have to examine it, but I don't believe
it to be a show-stopper--- particularly if the "real" key-distribution
protocol uses any intermediate agents (like HTTP caches...)

Mark Gritter

-- 
Mark Gritter <[email-masked]>
http://www-cs-students.stanford.edu/~mgritter/

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 26 Oct 2001 12:33:11 -0500

Simon Josefsson wrote:

> the DNS admins to insert SRV glue in DNS to point at this server?

The "easier" part is that LDAP has a notion of ACLs, meaning that the
users can be given permission to enter their own keys, rather than
requiring administrators do it for them. An equivalent in DNS would be to
define ACL RRs and pass them as mandatory data in all queries.

---

From: Michael Mealling <[email-masked]>
Date: Fri, 26 Oct 2001 13:40:57 -0400

> you-should-go-to-get-keys exists) is shared among many key lookups.

Yes it is. This is what the NAPTR based DDDS algorithm was designed to do.

> indirection provides _no_ savings.

The NAPTR record handles this by providing a rewrite function set that
allows you to say that "erdos.dsg.stanford.edu" has behavior 'x' and
'dsg.stanford.edu' has behavior 'y' without having to have records for
foo.stanford.edu. Its a much more robust delegation model than DNS since 
it can take into account more than just DNS labels.

> protocol uses any intermediate agents (like HTTP caches...)

Yes and no. Some protocols are better at handling mirros than others.
Just from our experience (I'm with VeriSign's research group) adding
to much to DNS nameservers causes huge issues with the roots...

To me it makes much more sense to leave the DNS at its current loading
and moving new, possibly very busy services to other protocols so that
you don't have to deal with more than one usage profile for the service.

-MM

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Oct 2001 19:54:40 +0200

"Eric A. Hall" <[email-masked]> writes:

> requiring administrators do it for them. 

Do users commonly want (and know how to) update their own keys in LDAP
servers?  (I don't know the answer, but my limited experience is that
administrators generally manage this.)

> An equivalent in DNS would be to define ACL RRs and pass them as
> mandatory data in all queries.

Or simply allowing users to update their own DNS data via mail, HTTP,
LDAP or similar.

Being able to do it via the DNS protocol is not necessary, I think,
and even if Dynamic DNS was used you don't need to have the ACL data
available in DNS.

---

From: Derek Atkins <[email-masked]>
Date: 26 Oct 2001 13:52:15 -0400

Michael Mealling <[email-masked]> writes:

> My objection isn't that a new RR is added, but that the usage
> profile of new functionality that requires that RR is inconsistent
> with previous ones.  By putting keys/certs in the DNS you've turned
> the DNS into a data store for end point information, not a pointer
> to that information. It changes the ratio of the amount/number of
> queries in/to a nameserver to the members of an administrative
> domain from 1:<very many> to 1:1.

As many have already pointed out, the DNS is already a data store for
end-point information, at least as far as hosts are concerned.

Perhaps we should limit this discussion to host-based keying material
as opposed to user-based keying material.  Not that this changes the
discussion -- we were already talking about IPsec and SSH -- but
perhaps that can scope us into a point where your arguments are
invalid.

We already have A record information for how to contact a host.  Why
not CERT/APPKEY information for how to contact that host securely?

> I.e. its no the RR that's the problem. Its the increase in the usage profile

I think this is a red herring.  All of this extra information is out
on the fringes; it's not in the core.

-derek

---

From: Derek Atkins <[email-masked]>
Date: 26 Oct 2001 13:55:11 -0400

> useful pgp is not restricted to email addresses as ids.

Sure it is.  Go send a message to Abdullah Oblongata.  Go ahead.  Go
find his key and send him an email?  Doesn't work very well, does it?
Whereas if I said, "send a message to [email-masked]", you
could do that.

I still maintain that useful pgp is restricted to email addresses.
Perhaps I should qualify that as "useful PGP for random
communication."  PGP in a closed environment can work without email
addresses, but in that case you're not going to use a directory to
lookup keys.

-derek

PS: I maintain that the current PGP Keyserver design is broken, and
has always been broken.  But back when there _were_ only 1000 keys in
the database, it made sense to do it that way.  But we've ALWAYS said
we need a DNS-like key distribution mechanism.

---

From: Derek Atkins <[email-masked]>
Date: 26 Oct 2001 13:59:46 -0400

> much of a problem either of those really are, they just jump out as probable

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.

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.

Also, CERT/APPKEY messages wont be any bigger than 2535 SIG/KEY
records.  Are you saying that we should just scrap all of DNSsec
because it's too big?  If not, then why are SIG/KEY record sizes ok
but CERT/APPKEY message sizes too big?  If anything, I'd expect
SIG/KEY records to be LARGER than CERT/APPKEY records.

> 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

---

From: Michael Mealling <[email-masked]>
Date: Fri, 26 Oct 2001 14:00:26 -0400

> not CERT/APPKEY information for how to contact that host securely?

That I don't have a problem with. After thinking about this I would 
do something like this:

Take the existing KEY RR and deprecate the use of anything other than
a zone. The NAPTR record is signed with that key. That NAPTR record points
to a server that runs various protocols that can answer various questions
about the thing the client is trying to do. Contact with that host via 
those protocols is authenticated via TLS using the same key that signed
the NAPTR record.

If its bad juju to use the zone key in the TLS session then I guess I
could be ok with both a host key and a zone key. 

I just have objections to keys for individual users/entities/documents, etc.

> on the fringes; it's not in the core.

But the number of total queries goes up because you don't agregate things at
the host level anymore...

-MM