Subject: Admitting more documents: application keys in DNS

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 16 Oct 2001 14:35:31 -0400

These two documents take a different approach on how applications can
store key information in DNS, one uses generic key protocol value, the
other one proposes a new RR type.
If admitted it is expected that at most one of these documents will advance.
Is there any objection to adding the documents to the working group plate?

draft-schlyter-appkey-00.txt
draft-lewis-dnsext-key-genprot-00.txt

	Olafur

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Oct 2001 23:38:29 +0200

=D3lafur Gu=F0mundsson <[email-masked]> writes:

> If admitted it is expected that at most one of these documents will advan=
ce.
>=20

For the record I'd like to mention two alternative approaches:

    * Specifying new RR types for each application
    * Using CERT RR (RFC 2538) for this purpose

Both of the drafts above, and the two alternative approaches,
accomplish the same goal: Separating DNSSEC keying material from
non-DNS, application specific, keying material.  This is good, hence
one of the ideas should be recommended.  (Some people argue that
application keys should not be present in DNS at all, but I haven't
seen much in the area of technical arguments for that opinion.)

The first draft, APPKEY, introduces a new RR for this, which makes
things nice and clean.  I think the draft would require changes to DNS
software though, and neglects experience with the CERT RR (see below).

The second draft suggests using the DNSSEC KEY RR combined with owner
name guidelines.  It solves the problem of separating DNSSEC and
non-DNSSEC keying material, and the large RRset problem.  However,
IMHO it is a kludge, and draft-schlyter-appkey seem to agree (sorry if
I'm putting words in people's mouths):

        Although this would indeed solve the problem with large RR
   sets when querying for an application key, it could also make the
   protocol field lose its value in practice as new applications would
   not require a new protocol value.  The author believes that
   combining unique protocol values with SRV-like encode of protocol
   would be a better solution solving both the issue with large RR
   sets and a large number of possible applications.

Using a new RR for each application avoids sub-typing RR and solves
all problems.  However, this is probably only a academic idea since
new RRs seem to take ages to happen, and application designers will
probably not want to go through that effort.

The fourth idea, using the CERT record has the same advantages of the
proposed APPKEY but it is also implemented by DNS software, as well as
applications.  It also fulfills the requirements in the quotation
above.

As far as I have been able to understand, the only disadvantage of the
fourth idea is that some people feel that the CERT RR is intended to
only carry "certificates" according to some strict definition that
would only match X.509 or similar, and exclude "raw" keys such as
those used for e.g. SSH.  I think this is wrong, the CERT RR can be
regarded as a RR intended to support key material for applications.
If you step out of the box, a raw key (stored in a CERT RR) which has
a binding to a name which is guaranteed by DNSSEC _is_ a "certificate"
in the abstract definition, so it is fine to store it in the CERT RR.

If it hasn't been obvious, I'd like to see the CERT RR updated with
owner name guidelines as the solution to the problem of application
keying material in DNS.

PS. These ideas has been discussed on http://www.cafax.se/dnssec/
previously.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 17 Oct 2001 11:28:25 -0400

>PS. These ideas has been discussed on http://www.cafax.se/dnssec/

...but no one has written drafts defining the alternate proposals.  That's
the second step (the first being the discussion on the list above).

I think the two drafts are admittable - we do need to define a generic way
in which DNS will handle application keys (at least a framework for the
support).

I'm not saying that the two drafts proposed are the solution - but they are
the only documented approaches available.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Simon Josefsson <[email-masked]>
Date: Wed, 17 Oct 2001 18:10:10 +0200 (CEST)

> the second step (the first being the discussion on the list above).

The first idea, using one RR for each application, cannot be written
generically so we have to wait for SSH, S/MIME, IPSEC, PGP etc to write
each spec.  I assume a brief document saying that DNSEXT would support the
approach could be written, but I haven't seen anyone seriously advocating
this idea so maybe noone will write it.

The second alternative, to use CERT with RR owner name guidelines, has
been written for S/MIME, SSL, IPSEC and CRL distribution in:

http://www.ietf.org/internet-drafts/draft-josefsson-pkix-dns-00.txt [1]

As such the draft has nothing to do with DNSEXT, but I guess I could
take on re-drafting this for a DNSEXT point of view (if someone wants to
help, please do :)) unless a resolution can't be reached by discussing the
alternatives only.

[1] It seems it expire tomorrow, how appropriate.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 17 Oct 2001 14:46:38 -0400

>http://www.ietf.org/internet-drafts/draft-josefsson-pkix-dns-00.txt [1]

You bring up a interesting point.
Some applications have CERT usage defined and should use CERT records.

The question is more for applications that do NOT have certificates
defined how can they advertise public keys ?

I do not think this is one shoe fits all situation.

>[1] It seems it expire tomorrow, how appropriate.

The only DNS issue in your draft is the selection of the names.
For SSL for example you say use the host name of the SSL server.
This is fine for dedicated servers, what about servers that service
multiple storefronts, do they use the same SSL cert for all?

         Olafur

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 18 Oct 2001 12:16:10 +0200 (MEST)

> software though, and neglects experience with the CERT RR (see below).

yes, the draft requires that DNS software adds support for APPKEY although
new server software should handle unknown RR-types transparently.

regarding the experience with the CERT the draft says:

  "The APPKEY RR is not intended for storage of certificates and a
   separate certificate RR, defined in RFC 2538, has been developed
   for that purpose."

> applications.  It also fulfills the requirements in the quotation

whether a raw public key is a certificate or not has been discussed many
times and we have reached no consensus on this. because of this, I still
think that separating these two (i.e. having both CERT and APPKEY) are a
good thing.

currently installed base of applications is not an issue, except for
various experimental software. I do not think that I exaggerate if I say
that the total number of applications supporting KEY or CERT for non-DNS
use is less than ten.

> in the abstract definition, so it is fine to store it in the CERT RR.

the primary issue here is that a CERT carries its own security,
independently of DNSSEC - APPKEY does not, but APPKEY+SIG(APPKEY) does.

	jakob

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Oct 2001 09:47:19 -0400

>new server software should handle unknown RR-types transparently.

BTW, there is an effort underway to do a prototype implementation of APPKEY
in BIND 9.2.0rc$i {$i in 0..7}.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Oct 2001 17:49:37 +0200 (CEST)

On Thu, 18 Oct 2001, Bill Manning wrote:

> % currently installed base of applications is not an issue, except for
> % various experimental software. I do not think that I exaggerate if I say
> % that the total number of applications supporting KEY or CERT for non-DNS
> % use is less than ten.
>
> 	Quick dump of stats on b.root-servers.net
>
> 	KEY: 2202
> 	CERT: 2
>
> I'd say ten is agressive. :)

FWIW there seem to be IPSEC implementations that uses TXT as well:

http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-02.txt

---

From: Bill Manning <[email-masked]>
Date: Thu, 18 Oct 2001 08:26:48 -0700 (PDT)

KEY: 2202
	CERT: 2

--bill

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Oct 2001 09:22:54 -0700

At 11:35 AM 10/16/2001, Ólafur Guðmundsson wrote:
>store key information in DNS,

The DNS has long been appealing, for discussion as a venue for a wide 
variety of lookup services.  Notably, few have actually gained much 
traction, though the appeal is serious and legitimate.

Recently, the email protocol folks separated initial posting from later 
relaying, by "copying" SMTP for use on a separate mail submission TCP port, 
and permitting divergent specification of the protocol, over time.

This approach could be very helpful for DNS.

The core DNS function is so massively integral to Internet infrastructure 
operations, it would be wise to pursue other uses of the protocol on a 
separate port, as a separate service.

At a minimum, this permits a) independent administration of core DNS data 
from value-added services, and b) separation of reliability concerns.

Thoughts?

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: John Schnizlein <[email-masked]>
Date: Thu, 18 Oct 2001 12:42:01 -0400

>from value-added services, and b) separation of reliability concerns.

Good idea.

This would work well with the normal firewall treatment of port 53,
requiring changes to opt-in for the value-added services.

It would also provide a good environment to experiment with Randy's
encouragement to make better use (more values) of the class field of a RR.

John

---

From: Michael Mealling <[email-masked]>
Date: Thu, 18 Oct 2001 13:12:02 -0400

> from value-added services, and b) separation of reliability concerns.

I've often thought of this and the conclusion I've come to is that
the reason people want to use the DNS often has more to do with
the APIs that are available to them and the fact that policies and
procedures ensure that its a somewhat stable namespace.

The problem I ran into when I thought about replicating the protocol
to another port was that just about none of the APIs support the
ability to ask DNS questions on another port. BIND derived APIs
allow it but these days that's become a small subset.

So, even if you were to run a special purpose nameserver on another port
the applications developer would have no pre-defined way of getting
at it (short of including their own DNS client software). The problem
with that is you then bypass the OS's policy and configuration options
for network directories...

IMHO, dns-ext could help the world if it would at least define a set of
requirements on DNS APIs. My minimum set would be:

1) any query must be able to define a port and server
2) all responses and queries must have a method for dealing with 
   unknown resource records (usually by passing the caller the raw packet)

So, yes, its an option, but if it could have been easily done it would have
been done already...

-MM

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Oct 2001 10:22:37 -0700

>procedures ensure that its a somewhat stable namespace.

1.  Whether to diverge the namespace would be an open question.  My own 
(rather strong) opinion is that there should be only one namespace.  It is 
the RR's that could/should/would diverge.

2.  Whether to diverge any of the technology, including APIs, is another 
open question.  I don't see the need to diverge, but perhaps others do.

3.  Same for basic administration policies and procedures.

In other words, I agree with you, and therefore am only suggesting a 
separation of the databases of "values" being looked up.

>ability to ask DNS questions on another port.

given that it would be new applications (given that we are talking about 
new uses of the DNS) then having to make that small a change to an API 
seems... a small matter.

>requirements on DNS APIs. My minimum set would be:

The IETF has always been reluctant to specify APIs.  They are platform 
dependent and the IETF does platform INdependent work.  And its 
transgressions into that space have not been met with spectacular success.

d/

----------

---

From: Greg Hudson <[email-masked]>
Date: Thu, 18 Oct 2001 13:19:49 -0400

> The core DNS function is so massively integral to Internet
> infrastructure operations, it would be wise to pursue other uses of
> the protocol on a separate port, as a separate service.

> At a minimum, this permits a) independent administration of core DNS
> data from value-added services, and b) separation of reliability
> concerns.

I think this is a bad idea.  By changing the port number, you force
these other lookup services to recreate the entire DNS hierarchy
before they can achieve any kind of traction.  The benefits you cite
are easily achieved through zone delegation.  (Well, the delegated
value-added service will depend on the reliabiliy of the core service,
but that's okay.)  In essence, you're saying "let's not define any new
record types, and tell people who want to define them to go play in
this little ghetto where they are guaranteed never to get anywhere."

The designers of the MIT Hesiod service made the same mistake, except
they thought they wanted a separate query class instead of a separate
port.  They, too, thought a different mode of operation was necessary
in order to achieve independent administration and separation of
reliability concerns, but those benefits were already trivially
achieved because Hesiod data lived under ns.athena.mit.edu instead of
mit.edu.  So the benefit of the separate query class was illusory, but
the cost was great: a separate global root was required for the HS
tree, and every recursive resolver needed special configuration to
know about it.

In addition, BIND 8 lost the ability to act as a recursive resolver
for query classes other than IN.  Luckily, we had already made a
transition back to the IN class before that became an issue, but
otherwise we would have lost due to having marginalized ourselves by
using a slightly different mode of operation than the rest of the DNS.
Such marginalization is exactly what you're proposing value-added
services start doing.

---

From: Michael Mealling <[email-masked]>
Date: Thu, 18 Oct 2001 13:30:42 -0400

> separation of the databases of "values" being looked up.

Sure... just a slightly different take on John's "new class" approach...

> new uses of the DNS) then having to make that small a change to an API 

It depends on how you deploy it. Do you setup a whole new set of root
nameservers on another port or do you use the existing port 53
delegation process and then only switch ports when you get to the
'last' nameserver? How much of the OS' native DNS implementation do you
use? If its none then you have to get all of the delegating nameservers
upgraded to run a listener on those other ports. If its some then
you have existing API issues.

I've looked at just about every single DNS client side implementation
and for about 80% of the machines on today's internet it would be 
a hard thing to deploy. I'm not saying its a show stopper, just that
if you do decide you want to do it you should make it clear to 
client developers how they should deal with it.

> transgressions into that space have not been met with spectacular success.

I wasn't suggesting that we specify the actual API. I'm suggesting
we create some guidance for API developers so they are aware that the 
DNS has moved beyond the old gethostbyname() and they should as well...
I.e. there's a disconnect between what we think of as 'DNS' and what 
developers think it is. Their view causes them to create APIs that make it
next to impossible to deploy DNS enhancements...

-MM

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Oct 2001 10:56:32 -0700

At 10:30 AM 10/18/2001, Michael Mealling wrote:
>'last' nameserver?

This is a really excellent point for discussion, as would be others about 
making the idea practical.

First reaction, to the specific point you raise:  Using the same namespace 
lookup sequence -- ie, only making the leaf query be on a different port -- 
ensures that the namespace administration -- and operation -- is consistent 
and shared.

>client developers how they should deal with it.

My simplistic view is that having the DNS client module switch ports based 
on the RR being sought would be sufficient.  And there is nothing wrong 
with having the responding "value-add DNS" server continue the friendly 
pattern of including additional, related-but-unrequested RRs, including 
relevant ones from the core DNS.

d/

----------

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Oct 2001 14:09:19 -0700

> just a slightly different take on John's "new class" approach...

actually, i'll take the blame for that one sick part of idea.

randy

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 18 Oct 2001 21:16:34 -0500

From: "Dave Crocker" <[email-masked]>

> First reaction, to the specific point you raise:  Using the same
> namespace  lookup sequence -- ie, only making the leaf query be on a
> different port --  ensures that the namespace administration -- and
> operation -- is consistent  and shared.

If the namespace is the same, why do you need another port?

---

From: Michael Mealling <[email-masked]>
Date: Fri, 19 Oct 2001 08:58:32 -0400

> If the namespace is the same, why do you need another port?

Think of the new port as a protocol version number on the entire DNS
system itself. By moving stuff to another port you can effectively say
that DNS as we know it right now is frozen.

In order to use the current delegation system on port 53 you'd need
some way to tell a client where along the path the break to the other
port is going to be. Sort of like an NS record but add a port number...

-MM

---

From: Andrew Brown <[email-masked]>
Date: Fri, 19 Oct 2001 12:42:39 -0400

>port is going to be. Sort of like an NS record but add a port number...

sounds like an srv record to me.  :)

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."

---

From: Michael Mealling <[email-masked]>
Date: Fri, 19 Oct 2001 12:44:55 -0400

> sounds like an srv record to me.  :)

Yea, but an SRV in the middle of the delegation path. I guess it
would be a cross between DNAME and SRV. And you really wouldn't want
the weight and preference part of the SRV here either....

-MM

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 20 Oct 2001 00:39:55 +0200 (MEST)

> http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-02.txt

as I understand, this is implemented in Linux FreeS/WAN and they use TXT
to combine a public key and the address of a security gateway.
surprisingly, I can not find any references to the key exchange delegation
record (RFC 2230) in this draft and they seem to accomplish almost the
same thing.

if APPKEY+KX is not enough for this need (which I believe it is), I'd like
to get more feedback so we can consider whether APPKEY is missing any
additional data or not.

	jakob

---

From: Derek Atkins <[email-masked]>
Date: 22 Oct 2001 14:39:28 -0400

> I do not think this is one shoe fits all situation.

Ignore the similarities between the word "Certificate" and the RR type
"CERT".  What we have/need is a generic means for applications to store
public keying, authenticating, and authorizing information within the DNS.
>From a DNS point of view, this key/auth data can be an opaque blob that
is handed to the relevant application.

There is absolutely no reason that a 'CERT' record cannot be used
for generic (non-self-verifying) public keys.  All that needs to
happen is the application needs to know the DNSSec validity of the
record.

Here are some examples:

1) PGP Keys are self-verifying.  A PGP Application can obtain a key
   from an untrusted source and verify the key using signatures that
   are stored with the key (Note: I am *NOT* calling this a
   certificate!).  If a PGP key is stored in a CERT record, the PGP
   Application can look up the key, ignore DNSSec, and validate the
   key by itself.  In this case, DNSSec is an added benefit, but not
   necessary for the application.

2) SSH Keys are currently not self-verifying.  They are raw keys.
   Currently an SSH application only verifies the linkability of keys.
   In other words, is the key I got from the host this time the same
   key that was presented the last time?  This key list is maintained
   by the client application (a way of "self-signing" certificates).
   Obviously, there is a potential for an attacker the first time you
   connect to a host.

   The question is how would SSH interact with DNS for keys?  If DNS
   is going to be used in lieu of the private key-cache, then it is
   absolutely vital for the client to authenticate the keys.  This
   means that an SSH applicatin would necessarily want to see the
   DNSSec validation of the key material.  However, note that this can
   STILL be done as a CERT record.

The only difference between how PGP and SSH would use keys in DNS is
whether the application needs to verify the DNSSec signature on the
key.  All that requires is that the lookup API provide that
information back to the application.  PGP can ignore it; SSH can use
it.

Nothing in these two examples say that PGP and SSH necessarily need
different record types.  CERT would work for both of them.  APPKEY
would work for both of them.

One thing to keep in mind if we have multiple key types: What if some
day SSH does provide optional X.509 or PGP support?  Would you require
SSH to use both key types, and maintainers to store keys in multiple
locations?

As a security person, I maintain that all (public) keys should be
treated equal, regardless of how they are encoded or what additional
information is contained alongside in the encoding.

-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: Tue, 23 Oct 2001 00:06:52 -0400

At 2:39 PM -0400 10/22/01, Derek Atkins wrote:
>for generic (non-self-verifying) public keys.

I can think of one reason - no one has submitted a draft defining how this
could be done. (;))

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Oct 2001 18:08:21 +0200

(Resent to the list only, because of subscription address problems)

> I can think of one reason - no one has submitted a draft defining how this

I promised to work on such a draft, but I find very little to write
about.  RFC 2538 contains most of it already.

In reviewing RFC 2538, I find that the only thing lacking are:

- A high-level description of the big picture as far as generic,
non-certificate based, application security goes.

- The removal of two sections that are probably better of in separate
documents. Namely section 3.1 (X.509 owner name guidelines, which are
poor) and section 3.2 (PGP owner name guidelines, which are good).

- The title should probably be changed to say "application specific
security material" (or similar) instead of "certificate" as well.

If people do not find RFC 2538 clear enough, and that there are no
real technical details that would fit into a separate draft, maybe a
Son-of-RFC2538 is the solution.  How do you all feel about that?  In
particular, perhaps, the authors of RFC 2538.