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

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

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

In the same way some other transport can securely fetch the data, over
IPsec, SSL etc. the reference could be LDAP, SHTTP, SCP or some other
secure transport protocol but should not be a concern for the DNS.

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

dnssec would ensure the network resource returned is accurate. That,
IMHO, is suffice.

We do not ask how the smtp servers going to send the mail after they got
the MX, nor do we ask how the browser how to obtain the html after they
got the IP. lets not ask how the apps going to retrieve the cert after
they got the reference from NAPTR too.

-James Seng

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

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 26 Oct 2001 12:42:25 +0200 (MEST)

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

> By bootstrap, do you mean the root key to start the whole chain of
> trust?

that is implemented in the policy of the resolver verifying the dns
answer.

> In the same way as what we are doing right now. The apps itself have
> the root key. Different apps have different root keys. Chaotic? Yes,
> but neither is one single authoritive root going to work in digital
> cert anyway given the different security practices and policy etc.

this will not scale. dns does scale.

> This question shouldnt even be ask in DNSEXT. AFAICS, so long the DNS
> is able to provide a accurate network reference, then its mission is
> accomplish. How you going to retrieve data securely after that is
> really none of the DNS business.

then we obviously have a large disagreement on the purpose of dns.

> Lets not make DNS more than what it is. It is *not* a database.

dns is a distributed database optimized for lookup operation.

> Please dont get me wrong. I support using DNS mechanism to lookup cert
> and its status etc. That is a good idea. But I do not support putting
> cert into DNS directly.

we're getting nowhere on this discussion. if we do not continue to provide
support for storing CERT and APP(KEY) in dns, people will do this anyway
using txt-records and I do not think we should go down that road.

	jakob

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 26 Oct 2001 18:14:51 +0800

In the same way as what we are doing right now. The apps itself have the
root key. Different apps have different root keys. Chaotic? Yes, but
neither is one single authoritive root going to work in digital cert
anyway given the different security practices and policy etc.

This question shouldnt even be ask in DNSEXT. AFAICS, so long the DNS is
able to provide a accurate network reference, then its mission is
accomplish. How you going to retrieve data securely after that is really
none of the DNS business.

-James Seng

> and how do we bootstrap these protocols?
>
>  - by using certificates in static files on disk? probably not.
>  - by using certificates and/or public keys published using dns and
>    verifiable using dnssec? yes.
>
> dns and dnssec enables us to bootstrap these protocols with security,
> performance and redundancy. we're not talking about storing the all
the
> information in the world in dns, only the data needed to bootstrap
> communication between machines and/or people.
>
>
> jakob
>

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 26 Oct 2001 11:58:00 +0200 (MEST)

dns and dnssec enables us to bootstrap these protocols with security,
performance and redundancy. we're not talking about storing the all the
information in the world in dns, only the data needed to bootstrap
communication between machines and/or people.

	jakob

---

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

This has been the number one argument/threat we see on justification for
a new RR. ;-)

I am not sure this old trick still work or not.

-James Seng

---

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

> using txt-records and I do not think we should go down that road.

They won't if we give them an alternative that works. But the question
is: even if we had one, would you implement it? I.e. are you willing
to investigate scalable/secure alternatives?

-MM

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

---

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

>  - by using certificates in static files on disk? probably not.

No. You write an application that publishes them. My personal
preference would be the work the RESCAP group is doing....

>    verifiable using dnssec? yes.

No.

> communication between machines and/or people.

You know as well as I do that whatever you use to bootstrap something
is exactly what ends up being used regardless of whether a much better
solution comes along. I'm sure Microsoft thought the 8.3 filename
limit was a fine bootstrap method but even in 2001 its the root of
many problems (viruses just being one of them).

IMHO, when you know something is wrong but you do it anyway just to
get a semi-solution out the door in the next week, that's bad engineering...

-MM

---

From: Greg Hudson <[email-masked]>
Date: Fri, 26 Oct 2001 10:00:45 -0400

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

> In the same way some other transport can securely fetch the data,
> over IPsec, SSL etc. the reference could be LDAP, SHTTP, SCP or some
> other secure transport protocol but should not be a concern for the
> DNS.

Although lots of protocols have security facilities, that doesn't mean
it is currently easy to establish trust between two parties who are
not within a single administrative domain.

Let's consider the application of an email-like service, where I want
to be able to verify that you are really [email-masked] and not
someone else.  Trusting the DNS is no problem since it is a DNS-based
identity which I am trying to verify.  Using an APPKEY approach, I can
securely (assuming this is a future day when we have DNSSEC) fetch a
key for pobox.org.sg and use it to verify a certificate used to sign
your messages.

Using your approach, the DNS can only tell me what server to contact
to get the key for pobox.org.sg.  When I contact that server, I have
to establish trust with it somehow, but because of your constraints,
pobox.org.sg's DNSSEC key can't be used to sign any application keys.
So I will have to use something else, probably an X.509 certificate,
to establish trust.  Two trust hierarchies more points of failure and
greater expense for pobox.org.sg.

---

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

> using txt-records and I do not think we should go down that road.

don't forget

   and if we don't standardize it in the ietf, the mpls forum will

:-)/2

randy

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 26 Oct 2001 16:33:12 +0200 (MEST)

> to investigate scalable/secure alternatives?

there are currently no scalable nor secure alternatives to dnssec for
doing large scale distribution of certificates and public keys.

	jakob

---

From: Michael Mealling <[email-masked]>
Date: Fri, 26 Oct 2001 10:37:21 -0400

> doing large scale distribution of certificates and public keys.

I've got one pretty much done:

Using DNSSEC you secure a NAPTR record that iteratively gets you to the
record that tells you what server has the information and then you contact
it via the given protocol and ask for the keys/certs. If you have to have
it working next week then you'd use HTTP as the final leg of the trip.
HTTP's security features are as good (or better) than DNSSEC if you use
the right authentication methods (which I would hope you would want).

I could probably have it done by the end of next week if you want to try
it out...

Now, why can't you use a solution like this? It doesn't even require
BIND to be upgraded to support a new RR type.... NAPTR support has
been in BIND since 4.9.5 so I'm willing to bet all DNSSEC capable nameservers
already have NAPTR support...

-MM

---

From: John Schnizlein <[email-masked]>
Date: Fri, 26 Oct 2001 10:47:22 -0400

Historical reality check:
When Microsoft chose limited file names at 8.3 characters, many
universities were teaching the error of such arbitrary limits
using an operating system that deliberately included only the
known best practices (no new ideas on purpose) of Operating
Systems (OSs). This OS was available at low distribution costs
as the result of research at Bell Labs. Its source code and
commentary from the University of South Wales facilitated
instruction, and its wide spread later facilitated the inclusion
of network protocols in an operating system (a new idea then) at
the Univeristy of California at Berkeley.

I am sure most people on this list know the facts, but I have 
learned the hard way that uncorrected historical references are
interpreted as true before very long.

John

At 09:01 AM 10/26/2001, Michael Mealling wrote:
>...

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 26 Oct 2001 16:58:07 +0200 (MEST)

On Fri, 26 Oct 2001, Michael Mealling wrote:

> Using DNSSEC you secure a NAPTR record that iteratively gets you to
> the record that tells you what server has the information and then you
> contact it via the given protocol and ask for the keys/certs. If you
> have to have it working next week then you'd use HTTP as the final leg
> of the trip.

in addition to just adding another level indirection, you still have the
problem of bootstrapping that other protocol.

> the right authentication methods (which I would hope you would want).

the mechanisms needed for distribution are already in dns & dnssec -
caching, replication, data integrity. why try create a parallel
infrastructure using http, ldap or what have you?

> been in BIND since 4.9.5 so I'm willing to bet all DNSSEC capable
> nameservers already have NAPTR support...

moving the problem over to other protocols doesn't improve the situation,
neither securitywise nor performancewise.

	jakob

---

From: "Andy W. Barclay" <[email-masked]>
Date: Fri, 26 Oct 2001 08:14:50 -0700

> greater expense for pobox.org.sg.

I am concerned that the person responsible for the DNS won't do
due-dilligence in validating the keys that are put in the DNS before
signing the zone.

Using your example, assume jseng sent an e-mail to his DNS administrator
asking him/her to add this APPKEY to the zone.... The admin will need
to go through all the validation that a certificate authority would -
like ask the person to fax or send a copy of a government issued ID,
or passport, or something before adding the APPKEY. I would assume
most DNS admins would not be interested in doing this, and as such,
we would end up with a bunch of APPKEYs which are signed and valid
by DNSSEC, but which cannot be trusted.

I may be in the minority here, but I feel that this type of
duty is best left to a certificate authority.

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

Ask yourself whether you are happy, and you cease to be
so.
   --John Stuart Mill

---

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

> problem of bootstrapping that other protocol.

You do? How?

> infrastructure using http, ldap or what have you?

DNS's 'caching, replication, data integrity' etc are probably at the
lower end of the scale when it comes to those terms. I would assert
that methods for doing that over and for HTTP are much more robust these days.

> neither securitywise nor performancewise.

It does when those protocols are engineered to do functions exactly like 
this. If your assertion were true then it would make sense to put 
web pages, mailbox capabilities, LDAP records, etc in DNS.

-MM

---

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

> doing large scale distribution of certificates and public keys.

a - dnssec s not yet real/deployable.  dnssec itself has keying problems.

b - because you have not designed a better container for your goods does
    not justify turning dns into a public dump.

randy

---

From: Bill Manning <[email-masked]>
Date: Fri, 26 Oct 2001 08:24:51 -0700 (PDT)

% > there are currently no scalable nor secure alternatives to dnssec for
% > doing large scale distribution of certificates and public keys.
% 
% a - dnssec s not yet real/deployable.  dnssec itself has keying problems.
	    ^ as a distribution method for certificates & pulbic keys i

There are components of DNSSEC that are eminently real and have been 
deployed. 

--bill

---

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

> the right authentication methods (which I would hope you would want).

Great, I'll be sure to intercept all of the HTTP requests for your
ssh public key and insert my own....

Seriously, all you've done is push the security off of DNS and onto HTTP.
We're no better off than we were before (except you can now rub your
hands and say "not my problem".  It's been everybody wiping their
hands this way that got us where we are today:  without security.

-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: Michael Mealling <[email-masked]>
Date: Fri, 26 Oct 2001 11:32:10 -0400

> ssh public key and insert my own....

You can try but I'll be doing it over authenticated SSL and if you can
snoop that then DNSSEC is just as useless...

> hands this way that got us where we are today:  without security.

I'm not saying "wipe your hands of it". I'm suggesting you do it in
a protocol that was designed to be able to support it. If that protocol
isn't currently sufficient I suggest it would be easier to fix that
than turn the DNS inside out to make it work there...

-MM

---

From: Mike Schiraldi <[email-masked]>
Date: Fri, 26 Oct 2001 11:44:17 -0400

> interpreted as true before very long.

I'm not sure i understand your argument. Michael was citing an example of
how imperfect solutions meant to bootstrap a new technology often stick
around far longer than their implementors intended them to, and can continue
to cause headaches for decades.

-- 
Mike Schiraldi
Verisign Applied Research

---

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

> due-dilligence in validating the keys that are put in the DNS before

This is a social issue, it cannot be solved technically alone.

> duty is best left to a certificate authority.

I agree, and I hope and think we are in majority -- I have not seen
anyone advocating using the DNSSEC PKI for trusting that keys belong
to a certain person.

Using the DNS to store a certificate issued by a CA via e.g. the CERT
record is different though.

---

From: bert hubert <[email-masked]>
Date: Fri, 26 Oct 2001 17:55:52 +0200

> There are components of DNSSEC that are eminently real and have been 

PKI may yet make dnnsec a reality - suddenly dnssec has a use beyond being a
'probably more secure but lots more complicated mousetrap'.

And DNSSEC needs all the help it can get to gain real world acceptance.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 27 Oct 2001 00:07:33 +0800

Lets see the trust model.

I am saying "I trust DNSSEC to give me an accurate reference of A". Then
I trust "ROOT KEY of R to give me accurate data of A".

You are saying, lets make ROOT KEY of R = DNSSEC, ie "I trust DNSSEC to
give me accurate data of A".

In terms of simplicity, I agree that yours is better, thus less proned
to technical risk.

OTOH, while I can trust D to give me some information, I may not trust D
to give me all the information. There are different security use &
practice and insurance and liabilities consideration. A lookup to verify
[email-masked] have a very different consideration compared to a
money-transfer transcation. Putting them all under a single trust model
is an engineer dream but a nightmare in reality.

The failure to build a single trust root for PKI is a testimont to the
fact that people wants different trust relationship for different
purposes. For an example, I would trust my bank with my money and I
would trust my lawyer with my will. I trust both my bank and lawyer but
they are not inexchangable nor chainable. If they do, it is based on my
choice, not some X party choice.

But these are obviously abstract thoughts, maybe not even worth
pondering on...

-James Seng

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 26 Oct 2001 18:43:07 +0200 (MEST)

> a - dnssec s not yet real/deployable.  dnssec itself has keying problems.

what problems are you refering to? the problems that initiated the work on
delegation signer or the general parent-child key transfer problem?

	jakob

---

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

> > problem of bootstrapping that other protocol.

how to you trust the tls/ssl peer that you are talking https or ldaps
with?

> that methods for doing that over and for HTTP are much more robust

distributed http caching mechanism? large scale http replication between
sites? signed content in dns? we must living in separate worlds.

	jakob

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 27 Oct 2001 00:54:44 +0800

I love following up my own mail.

But I like to post just one question (one which may not have an answer):

When an application retrieve the publickey, say using the mechanism
stated in draft-schlyter-appkey, does the application needs to validate
the publickey?

If yes, then ...(see how it relates below)...
If no, then ...(see how it relates below)...

:-)

-James Seng

---

From: John Schnizlein <[email-masked]>
Date: Fri, 26 Oct 2001 15:15:18 -0400

Microsoft's choice of 8.3 filenames is not an example of trying
to use the established (best practice) technology for purposes 
not anticipated at the time of invention.
The problem in this case was well known when MS-DOS was first
licensed to IBM. The implication that 8.3 filenames were
best practice at that time is historically false.

This attempted metaphor does not apply to the issue at hand:
using the (best practice) DNS to carry host-access security
information in addition to host-access address information.

John