Subject: Re: DNSSEC (RE: Software for PKI)

From: [email-masked]
Date: Fri, 9 Nov 2001 07:19:12 -0700

Well, comparing a chain-of-trust:

1) both TTP CAs and DNS are dependent on the same domain name
infrastructure registration & operation as the authoritative reference as
to the validity of domain name owndership.

2) Registering public keys as part of domain name registeration to improve
the integrity of #1 would also be the same for both TTP CAs and DNS

3) DNS would obtain the public key from that data base in real time ...
effectively inverting the current TTP CA PKI valid key issue. The TTP CA
for SSL domain name certificates doesn't have a real PKI i.e. from the
point of view of administrating stale certificates that they have
manufactored at some time way in the past .... based on #1 & possibly #2.
DNS effectively jumps way ahead of the existing SSL domain name certificate
to the equivalent of a real PKI ... having real-time administration of
validity of public keys.

4) SSL currently obtains a server public key from a lot of protocol chatter
involving certificate distribution, certificates which have been signed by
some CA public key. Then the current SSL validates a certificate with CA
public keys that have been distributed as part of the browser. Once, the
certificate signature has been validating (note that this isn't a real PKI
so none of the other certificate validation stuff is in effect), then the
cretificate can be checked that the domain name requested and the domain
name in the certificate is the same. After that, the validity of some
signed something from the server can be validated with the public key in
the certificate.

5) In a DNSSEC world, browser could obtain a valid ip-address and public
key in the same DNS transaction. By definition, the ip-address is trusted
(so the issue of domain name to ip-address translation is eliminated).
Also, by definition the public key for that "domain name/ip-address/public
key" tuble is trusted. Majority of the protocol setup chatter in the
existing SSL is eliminated ... since there is real-time trusted key
distribution (as part of real-time trusted ip-address distribution). So the
only real SSL setup step that is left is the validaty of some signed
something from the server.

The issue ... as always ... with DNS is does it provide real-time trusted
information distribution. If DNSSEC can improve the trust & integrity of
that process ... then I would claim that there is, in effect, a real PKI
(real-time distribution and administration of trusted public keys) as
compared to the restricted subset of certificate manufactoring that occurs
today for SSL domain name certificates.

[email-masked] on 11/9/2001 3:10 am:

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

---

From: Eric Rescorla <[email-masked]>
Date: 09 Nov 2001 07:58:07 -0800

[email-masked] writes:
> existingf SSL is eliminated ... since there is real-time trusted key
Actually, very little of the SSL protocol overhead is concerned with
certificate issues. Most of it is concerned with ciphersuite negotiation,
key exchange and handshake verification, none of which would be 
affected significantly by DNSSEC.

The typical SSL handshake is:

C: ClientHello (ciphersuites, random, session id)
S: ServerHello (ciphersuite selection, random, session id)
S: Certificate
S: ServerHelloDone
C: ClientKeyExchange
C: ChangeCipherSpec
C: Finished
S: ChangeCipherSpec
S: Finished

In a hypothetical world in which we had DNSSEC we'd be able to eliminate
exactly one of these messages, the server Certificate.

I agree that a world with DNSSEC would be potentially more secure than
the current world of SSL certificates, but it wouldn't make SSL 
much simpler.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

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

Lynn,

> to the equivalent of a real PKI ... having real-time administration of

yes and no. One of the problems is that you cannot actively "revoke"
a key or a signature other than physically delete that information
from the DNS zone file. However, the DNS data will still be
cached in dozens of servers out there.

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 20:19:35 +0100

Lynn,
This is interesting.  What you are saying is that server-based PKI (sort of)
that generates fresh (or short-time cached) responses from a database
is the way to go.

This is essentially the same thing I have been pushing several years for
extranet authentication.  That each company server generates freshly
signed "tickets" (http://www.x-obi.com/purple) based on their databases
instead of issuing and distributing employee certificates.

Server-cryptography rulez!

These DNSSEC servers will not be practical until HW-crypto
support is down in the $100 region.   This may take another
5 years or so.  It is driven by the B2B market that needs such
servers as well.

Anders

----- Original Message ----- 
From: <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, November 09, 2001 15:19
Subject: Re: DNSSEC (RE: Software for PKI)

Stefan,

Anders