Subject: RE: Software for PKI

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 9 Nov 2001 12:29:33 +1100

Just regarding you 1), 2), 3) and 4).

1) hasn't yet happened. Maybe the solution of 1) is equivalent to the PKI
question? (At least, they seem to be of the same complexity.)

2) SSL certificates do more than ensure the link between DNS name and IP
address. In fact, I don't know that they have a use in this area. I would
say the major use is to prevent a man-in-the-middle attack. Therefore, even
with DNSSEC, server certificates would still be required.

3) Invalid conclusion. (What is superfulous?)

4) I haven't looked into DNSSEC so I don't know if it is a pipe dream. As it
doesn't exist today, I guess I can say that this also is an invalid
conclusion.

Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, 9 November 2001 11:20
To: Ramsay, Ron
Cc: [email-masked]
Subject: RE: Software for PKI

 ... the DNSSEC RFC standards talk about adding security to DNS ... in part
by starting with effectively chain of trust/evidence with public keys.
independent of the DNSSEC work, registering of public keys would also
support making the domain name infrastructure more secure for TTP CA
purposes associated with SSL domain name certificates.

the mapping of domain name to ip address integrity issue was the primary
reason for having SSL domain name certificates at all in the first place.
While most people click on https for secure tunnel for their credit card
numbers .... the actual implementation of the SSL handshaking chatter ....
checks the domain name in the certificate provided by the server it is
talking to at the ip-address provided by dns ... with the domain name that
it thinks it is talking to.

Having created that infrastructure for SSL domain name certificates ....
somewhat implies that somebody thot the mapping from domain name to
ip-address was an issue .... enuf to justify the whole SSL domain name
certificates and browser use of those domain name certificates as part of
the SSL/TLS protocol .... aka if there was an actual belief that the
ip-address for the specified URL was always correct .... there would be no
reason for the client to check if the server at the ip-address mapped by
DNS is the server that the client thinks it is.

The issues are

1) DNSSEC & public keys can be part of scaffold to address integrity issues
in the domain name infrastructure (both for TTP CAs but also for all the
clients in the world)

2) with #1, clients can trust the DNS IP-addresses ... then they can
eliminate the check that they do with SSL domain name certificates
(checking that the server at the DNS-provided ip-address they are talking
to has the domain name certificate that matches the domain the client
specified in the browser ... prior to the DNS lookup).

3) if #2, then SSL domain name certificates can be eliminated as
unnecessary, superfulous and redundant.

4) if #1, and somebody actually wants to know a server's public key, and
they can otherwise trust the distribution of information by the domain name
infrastructure ... then they can also trust the DNS distribution of public
keys ... in so far as the public key is with respect to some network domain
name operation.

[email-masked] on 11/8/2001 4:53 PM wrote:

The problem is not in the registration. The problem is in retrieving the
public key. PGP, for example, is based on the "web of trust", and this does
not mean picking up public keys where you can find them.

Putting public keys into DNS would be as useless as tits on a bull. DNS
offers no security. It is trusted only because providing the IP address for
a domain name is not yet regarded as a critical function. Providing public
keys in this random way would, I guess, expose the vulnerabilities of the
system.

Ron.

---

From: "Stefan Kelm" <[email-masked]>
Date: Fri, 9 Nov 2001 10:00:52 +0100

Ron,

> doesn't exist today, I guess I can say that this also is an invalid

Some of the larger TLDs (including .com, .nl, .de) have been
looking into DNSSEC issues very intensively for quite a while
(http://www.pki-page.info/#DNSSEC). While the specs are
getting more stable there are still both technical and
organizational problems to be solved before we will see
DNSSEC beeing deployed on a large scale.

Cheers,

	Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 9 Nov 2001 11:10:08 +0100

Stefan,
Does not DNSSEC suffer from basically the same problems as
web-server certficates with resp to RPs?  I.e. you must install
trusted root certificates in clients.   Or is the hope that there will
be just a single root?  Signed by UN I guess...

The primary advantage seem to be that people don't have to buy
and install web-server certificates.  Quite a TTP-market there that
goes into pieces!

But does HTTPS really work without these?
If it does not, I don't think DNSSEC will be such a success.

Anders

----- Original Message ----- 
From: "Stefan Kelm" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 09, 2001 10:00
Subject: DNSSEC (RE: Software for PKI)

Ron,

Cheers,

Stefan.

---

From: "Stefan Kelm" <[email-masked]>
Date: Fri, 9 Nov 2001 17:35:23 +0100

Anders,

> be just a single root?  Signed by UN I guess...

The current theory is to distribute root keys the same way as
the root servers IP addresses are distributed: hardcoded
into the client (DNS resolver) and name server software
(e.g., BIND). Fortunately, this has been identified as
one of the major problems already.

Since there are 13 parallel root servers on top of the TLDs
it is unlikely that there will be one single DNSSEC root "CA".

(Hey, what about a "distributed root"?  :-)

> If it does not, I don't think DNSSEC will be such a success.

Comparing DNSSEC to PKIX style PKIs has its problems: DNSSEC
doesn't know the concept of certificates to begin with, at
least not in the X.509 sense. There are KEYs which are linked
to domains and there are SIGnatures which can be used to sign
any DNS data including KEYs. Signing a KEY, of course, is
similar to a certificate but differs in a number of ways.

Although DNSSEC is heavily based on public key technology it
lacks PKI processes. I think we will eventually see DNSSEC
being deployed on a larger scale but the infrastructure will
not be comparable to other PKIs.

Cheers,

	Stefan.