Subject: RE: Scale (and the SRV record)

From: Ron Ramsay <[email-masked]>
Date: Thu, 29 Oct 1998 11:10:57 +1100

Phillip,

Thanks for taking time to develop the example.

Two issues:

1. Surely DNS is not secure?

2. Your example seems to be based on encryption using public keys. From
what I know of the public key system, it is not used for encryption. Its
purpose is authentication and integrity. To bend your example, you will
be encrypting your message with your own private key. How is an
addressee to verify it was you who sent the message and that the message
was not modified?

Ron.

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Thursday, October 29, 1998 3:37 AM
> To:	Alan Lloyd
> Cc:	Stephen Kent; [email-masked]
> Subject:	Scale (and the SRV record)
> 
> Alan issued the following challenge,
> 
> > I need to be enlightened - How does one deploy a large scale
> distributed
> > PKI without a large scale object oriented distributed (and protected
> by
> > ACI, etc) directory system?
> 
> Seems like a good question, it occured to me that now is a good time
> to
> raise it.
> 
> Look at the one already deployed and work it out. The SSL secured part
> of
> the Web does not stop working if directory.verisign.com goes down.
> 
> I have had this arguement before with the hypertext establishment.
> They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were
> completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L
> to
> give the keynote!
> 
> The greater the scale the less weight a base information system can
> carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of
> consistency
> across transactions. Finally at global scale it is not practical to
> deal in
> data, we must deal in names instead, names in this case being of
> Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live)
> to
> make the DNS sytem tractable, precisely because they have Sebok's
> 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
> 
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
> 
> Making PKI scale to global reach is no more than a matter of naming.
> Bind
> the network level directory infrastructures to the internet naming
> system
> which is and will continue to be DNS.
> 
> There is already a DNS resource record defined for the purpose - SRV.
> If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
> 
> Email client is to send to [email-masked], there is no cert in the
> address
> book:
> 
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> 	_ldap._tcp.arius.com	SRV 0 0 389 directory.arius.com
> 	_ldap._tcp.arius.com	SRV 1 3 389 fast.backup-site.net
> 	_ldap._tcp.arius.com	SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest
> priority
> 	number which offers a directory protocol that is understood,
> 	in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> 	[email-masked]
> 5) The client retrieves the certificates for the entry, there are
> three
> 	of which one is a currently valid one for [email-masked]
> 6) The client encrypts the email
> 7) The client sends the email
> 
> 
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
> 
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
> 
> 
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
> 
> 
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
> 
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
> 
> 	__pkix._ldap._tcp.arius.com	SRV 0 0 389 directory.arius.com
> 	__pkix._ldap._tcp.arius.com	SRV 1 3 389 fast.backup-site.net
> 	__pkix._ldap._tcp.arius.com	SRV 1 1 389 slow.backup-site.net
> 
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
> 
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
> 
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have
> deployed.
> 
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
> 
> 
> 		Phill
> 
>

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Thu, 29 Oct 1998 10:38:26 -0500

> 1. Surely DNS is not secure?

Define secure? With the exception of a denial of service attack DNS
is 'secure enough' for this purpose since there is no trust placed
on the server. The origin of a signed message is irrelevant. Only
the signature is relevant.

> what I know of the public key system, it is not used for encryption. 

I think you are confusing DNS security here with PKIX. The two are very
separate.

If someone spoofed DNS the worst that would happen is that I would 
recieve a certificate I didn't trust (and would ignore) or no certificate
at all.

>Its

I send my signing certificate with the message. Or once the infrastructure
is deployed the recipient could use the SRV pointer to locate a directory
where a copy of the certificate was available. 

		Phill

---

From: [email-masked]
Date: Thu, 29 Oct 1998 13:59:04 -0500

>recieve a certificate I didn't trust (and would ignore) or no >certificate
at all.

Well, if you're only fetching certificates, probably.

But if you're fetching CRL's, then no.  Suppose a cert is compromised,
and CRLn is issued before the "next update" time purely because of
that compromise.  The adversary could spoof DNS and just send out
the valid, but outdated CRL(n-1) and potentially have quite a
window of opportunity.
	/r$

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Thu, 29 Oct 1998 14:55:11 -0500

> the valid, but outdated CRL(n-1) and potentially have quite a

Hence the motivation for an Online Status service like OCSP.

Alternatively use the OCDP mechanism to provide a 'meta CRL'. A master
CRL can be issued every minute which would contain a list (CRLList) of 
the most current CRLs in each partition.

This issue is orthogonal to the issue of directory discovery however.
Any infrastructure for distributing CRLs has the same problem. I don't
see that the solution is to attempt to guarantee delivery of the CRLs
by hypothesizing secure infrastructures will be installed. I believe
we should address the issue by removing the dependence.

		Phill

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Oct 1998 20:25:20 -0500

This vulnerability cannt be completely eliminated.  The CA's policy
determines the amount of risk associated with the frequency of CRL
issuance.  Even if a fresh CRL is posted prior ti the earlier on expiring,
clinets may obtain the older one from a cache.

OCSP was supposed to address this concern.  But, even OCSP does not get a
fresh answer for every query.  Without a protocol that goes all the way to
the CA for a fresh response for every query, this vulnerability cannot be
eliminated.

Russ