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

From: Eric Rescorla <[email-masked]>
Date: 09 Nov 2001 11:50:00 -0800

[email-masked] writes:
> since the client already has the public key for the server before it even
> does anything (i.e. as part of obtaining the ip-address), the client
> encrypts cypersuites, session id, key all in one message. Server responds
> accepted/finsihed or changespec. Single round-trip if the server accepts
> the client's specification. To increase the probability, the server can
> register the preferred ciphersuite with their key in DNS and DNS can
> distribute that as a single bundle with the key ... in the single DNS call.
Yes, this scheme was considered back in about 1995/1996 and rejected
as infeasible for pretty much the same reason then as now: it relies
on DNSSEC, which doesn't exist to any significant degree. One of the
primary virtues of SSL/TLS is that it doesn't require much in the way
of supporting infrastructure.

In fact, what was proposed at the time was an optimization whereby if
the client knew the server's public key and preferences (never mind
how) it could short-circuit the handshake. This would also have
allowed the client to cache the server's identity data.

In any case, this doesn't really simplify things very much. The client
needs to process much the same data but from two sources rather than
one. And since SSL has to work in situations where DNS is not
available, you need to retain the full handshake anyway so you've
added complexity to the protocol, not subtracted it. At the time the
sense of the group was that DNSSEC was insufficiently deployed to make
this a worthwhile optimization. Things haven't changed much in 5
years.

-Ekr

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

---

From: [email-masked]
Date: Fri, 9 Nov 2001 09:30:27 -0700

There is no middle man attacks ... assuming trusted distribution of the
public key ... since only the server can decode what the client has sent in
the initial message.

There is the ancillary issue of flowing HTTP/HTTPS/stateless over short TCP
... with the associated TCP set-up/shutdown (all the performance issues
with various TCP linear list scanning from the early & mid-90s)

The issue then is to look at having real tunneling with long-term (TCP)
sessions and a real stateless transactiion where the client transaction is
piggybacked with the setup ... more like reliable UDP and do the
transaction version in single packet round-trip ... aka XTP (actually three
packet exchange for reliable setup/transaction/tear-down/etc ... but that
is better than the TCP minimum of seven packet)

random ref:
http://www.garlic.com/~lynn/99.html#0 Early tcp development?
http://www.garlic.com/~lynn/99.html#164 Uptime (was Re: Q: S/390 on
PowerPC?)
http://www.garlic.com/~lynn/99.html#207 Life-Advancing Work of Timothy
Berners-Lee
http://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still
have a meaning?
http://www.garlic.com/~lynn/2001b.html#57 I am fed up!
http://www.garlic.com/~lynn/2001e.html#24 Pre ARPAnet email?

[email-masked] on 11/9/2001 8:58 AM wrote:

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