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

From: Martin Fredriksson <[email-masked]>
Date: Wed, 24 Oct 2001 02:06:57 +0200

--On m=E5ndag 22 oktober 2001 14.39 -0400 Derek Atkins <[email-masked]>=20
wrote:

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

This is a BIG difference.  I have seen a lot of cases where "public keys"=20
are being confused with "certificates".   They are different entities, and=20
I support all means for keeping that difference clear and obvious.  I think =

Jakob expressed it very well in a previous mail in this thread:

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

I think it is a distinct advantage in making it clear where DNSSEC provides =

the basic security infrastructure (APPKEY) and where it does not (CERT).

/m

--
--------------------------------------------------------------
Martin Fredriksson                     Email: [email-masked]
Carlstedt Research & Technology AB     Phone:  +46 31 7014200
Stora Badhusgatan 18-20                Direct: +46 31 7014237
SE-41121  GOTEBORG                     Mobile: +46 70 5208339
SWEDEN                                 W3: http://www.crt.se/

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

---

From: Derek Atkins <[email-masked]>
Date: 24 Oct 2001 09:49:06 -0400

> I support all means for keeping that difference clear and obvious.  I think =

No, it's a small difference, and that difference is ONLY a difference
to the application.  As far as DNS itself is concerned, there is no
difference.

The application needs to know whether to check DNSSec.  It can tell
that based upon the data it received from the response.  Keep in mind
that a security application SHOULD NOT depend upon DNSSec verification
outside the local resolver.  This means that the application itself
should get a "DNSSec verified" flag (and potentially even access to
the KEY/SIG records).

As far as DNS is concerned, there is no difference.  If you're trying
to save yourself trouble by only partially signing a zone (so you can
avoid signing CERT records), I believe you are doing yourself a
disservice.

-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: Martin Fredriksson <[email-masked]>
Date: Wed, 24 Oct 2001 16:52:16 +0200

--On onsdag 24 oktober 2001 09.49 -0400 Derek Atkins <[email-masked]> 
wrote:

>> This is a BIG difference.  I have seen a lot of cases where "public
>> keys"=20 are being confused with "certificates".   They are different
>> entities, and=20 I support all means for keeping that difference clear
>> and obvious.  I think =
>

I agree about the latter.  I strongly disagree about the former.  There is 
no ONLY about this difference, at least not in my experience.

> avoid signing CERT records), I believe you are doing yourself a

I agree.

/m

---

From: Martin Fredriksson <[email-masked]>
Date: Wed, 24 Oct 2001 16:52:06 +0200

--On onsdag 24 oktober 2001 12.10 +0200 Simon Josefsson=20
<[email-masked]> wrote:

>> --On m=E5ndag 22 oktober 2001 14.39 -0400 Derek Atkins <[email-masked]>
>> wrote:
>>
>> keys" are being confused with "certificates".   They are different
>> entities, and I support all means for keeping that difference clear
>> and obvious.
>
> From a DNS point of view: Why?  How would DNS software handle "public
> keys" and "certificates" differently?

It would not.  I was talking from an application/user perspective.

> If DNS software does not have to treat CERT and APPKEY differently,
> why should DNS software (and DNS administrators) need to be aware of
> the difference?
>
> The purpose of APPKEY/CERT is to provide applications with some kind
> of security related data, maybe the distinction between public keys,
> certificates and whatnot should be in the application instead of DNS.

It should.  My argument for APPKEY is that it helps to keep the distinction =

more obvious.

> Also, we have only talked about "certificates" and "public keys" so
> far but there will likely be other information that applications may
> wish to store in DNS, such as:
>
> * Pointer to CA roots for use within a domain
> * Kerberos Realm (this is already being stored in DNS but is a good
>   example of this kind of data)
> * Realm for SASL mechanisms
> * ... other realmlike information, or CA root like information
>
> Having a application-independent RR for each of these purposes,
> APPREALM and APPCAROOT etc, seems complex and unnecessary to me.
>
> The two extremes are one RR per application, or one RR for all
> application security related information.  I vote for the latter since
> it is probably easier to deploy within DNS.

I believe we should solve one problem at a time.  I do not think a generic=20
"security related information" RR is the solution.  We will never be able=20
to cover all cases anyway.  At least that is my gut feeling.

> The middle way of having several RRs to hold application security data
> is not perfect, I think.  Consder SSH.  Maybe SSH starts to support
> certificate-like public containers (X.509, PGP, SPKI etc) as well as
> raw keys, then the SSH client need to query for both APPKEY and CERT
> to find what the server uses.  Maybe SSH adds support for Kerberos,
> then it need to query for yet another RR to find the realm.  Maybe SSH
> adds support for SASL and some SASL mechanism need realm information.
> Maybe SSH adds support for other security stuff that needs some kind
> of data, then we're up to querying for 5 different RRs each time the
> client make a connection.  I don't think this scales well.

Hmm, this all depends on _when_ you do the lookup.  You of course need to=20
know what to ask for, and you won't know that until you have started=20
talking to the server.  I don't see the problem.

/m

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Oct 2001 12:09:29 +0200

Martin Fredriksson <[email-masked]> writes:

> I believe we should solve one problem at a time.  I do not think a generic
> "security related information" RR is the solution.  We will never be able

If the RR does not say anything about how it must be used by, I think
it would cover all cases because the interpretation of the RR would be
left to the application, so it can be used to store certificates,
keys, realms, ca root pointers and whatnot.

(If it is a good thing to store all that junk in DNS is a different
discussion, though.)

> Hmm, this all depends on _when_ you do the lookup.  You of course need to
> know what to ask for, and you won't know that until you have started
> talking to the server.

I don't think that is generic, there may well be protocols that
require you to know the public key of the recipient before you talk to
him (since, for example, the stuff you send should be encrypted to the
recipient).

Sending PKCS#7/CMS blobs via mail is an example of such protocol.

Hey, even IPSEC with oppurtunistic encryption is a example if I
understand draft-richardson-ipsec-opportunistic-02.txt correctly.

I don't know the SSH protocol so I couldn't say if this applies there
as well, but generically I wouldn't place much trust in what a
not-yet-authenticated server would tell me about where I should get
his public key.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 24 Oct 2001 12:10:06 +0200

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 25 Oct 2001 11:52:21 -0400

I think we are going in circles again.

We are talking about storing two kinds of information in DNS.

1) Certificates, which I understand to be structures that include a public
key and associate it with identity information and are usually, if not
always, signed by some agency.  (Personally I discount self-signed
certificates as I can't figure out what they prove.)

2) Public Keys, which I understand are numbers that interact with a Private
Key to do some magic.

A public key is an ingredient in a certificate (at least within the realm
of what I think it the discussion).

We are talking about a number of ways of storing these two things in DNS.

1) RFC 2538 (CERT) defines a structure to hold certificates.  The document
does go so far as to state that certificates are signed, etc., as described
in the first category above.  Some folks have gone on to state that this is
over restrictive and that the RFC doesn't mean what it states.

2) The KEY RR in RFC 2535 defines a means for holding public keys.

3) The APPKEY RR internet draft defines another mechanism for holding
public keys that is more ameanable to application use.  E.g., the KEY RR
does not have the ability to convey application version information that is
needed by, SSH when considering v1 and v2 public keys.

The "camps" of dicsussion fall into one group wanting to define a new key
record, the APPKEY, and keep the CERT record for its textually described
use.  Another camp wants to avoid the use of the APPKEY and reuse the CERT
record.

So much for the objective part of my message.

As far as reusing the CERT RR, a new document is needed.  The new document
must define a new certificate type (see 2.1 of RFC 2538), and a format for
the certificate/crl portion of the RDATA.  The new document may not have a
lot of text, but it must at least be a request that IANA allocate the
certificate type value.  (Both the APPKEY and CERT approaches require
standards action - neither is a lighter load on the WG process.)  The new
document should also attempt to restate the intended purpose of the CERT
RR, fixing whatever is perceived to be broken about the text in RFC2538's
security considerations.

Essentially the above approach is defining a *data structure* for a DNS
public key certificate - perhaps without defining a certificate handling
process.  Doing this could be taken as a step towards turning DNS into a
PKI.

I am in favor of the APPKEY.  The reason is because of the DNSSEC ramp-up
proposals (opt-in or no sig).  I can see the reason for avoiding the CERT
RR's but including APPKEY RR's.  The obvious reason is that certificates as
defined above have their own validation chain and don't need DNS to provice
the same.  The less obvious reason is that CERT RR's may have owner domain
names that reveal personnel employed in a company (for email certificates).
By omitting CERT RR's, the names aren't as exposed via an NXT walk.

In conclusion - if we are to continue to debate this, we do need a document
supporting the use of the CERT RR as a holder for a public key...

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Michael Mealling <[email-masked]>
Date: Thu, 25 Oct 2001 13:21:24 -0400

On Thu, Oct 25, 2001 at 11:52:21AM -0400, Edward Lewis wrote:
> 1) Certificates, 
> 2) Public Keys, 

The rule of thumb I've been using when I designed the NAPTR stuff was this:

The DNS is used to point to network level resources that actually have
the information you are after. You never put the actual information
itself in the DNS. With respect to URIs that means you use the DNS
to find the host that can answer questions about the URI. You never
put the the document or complete information about the URI (including
the path) in the DNS.

In other words, there should never be a 1:1 mapping between the number of 
DNS Resource Records and the number of entities being discussed. With
respect to the Web you would never have a single DNS RR for each and 
every URI. With respect to PKI you should never have an RR for every
certificate/key. With respect to IDN you should never have an RR for
every possible normalization method/character set. 

Its the _Domain_ Name System. The identifiers in it point to _domains_
of data, not the individual items in those domains...

Just my experience with doing this same "can I come up with a new RR that
doesn't completely break DNS" process...

-MM

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

---

From: Derek Atkins <[email-masked]>
Date: 25 Oct 2001 14:51:45 -0400

> of data, not the individual items in those domains...

Um, 'A' records?  'CNAME' records?  Sorry, I don't buy this argument.
While I agree that URIs are a good thing, at some level you need to
point to something.  It _IS_ possible to have too many levels of
indirection.

-derek

---

From: Greg Hudson <[email-masked]>
Date: Thu, 25 Oct 2001 14:57:04 -0400

> In other words, there should never be a 1:1 mapping between the
> number of DNS Resource Records and the number of entities being
> discussed.

Whyever not?  If the data in question are a good match for the
properties of the DNS, what's wrong with putting the data there?
Maybe application keys aren't a good fit; if so, people need to make
specific arguments to that effect, not vague general arguments about
all kinds of new data.

If currently DNS server implementations aren't good at entering new
kinds of data, then let's create new (or enhanced) implementations,
not new protocols.

If we're worried about impacting the existing DNS infrastructure, then
let's make sure that the domain names for the new data live in their
own little space like SRV records do, so that zone delegation can take
care of the necessary separation.

> Its the _Domain_ Name System. The identifiers in it point to
> _domains_ of data, not the individual items in those domains...

I'm not sure I've ever heard that interpretation of the name before.
And I'm not sure why that argument applies any less to hostname -> IP
address translations than it does to other kinds of data.

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 26 Oct 2001 13:20:43 +0800

I agree with Michael here.

While it is possible to engineer DNS to put all sort of data into it by
having multiples RR, we need to ask ourselves if the intention is to
build a mini-database. Heck, I could engineer DNS to serve HTML page by
define RR records for that and we can do away with HTTP.

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.

-James Seng