Subject: RE: Scale (and the SRV record)

From: Ron Ramsay <[email-masked]>
Date: Fri, 30 Oct 1998 13:42:13 +1100

Phillip,

Thanks again.

Let me pick up on two points.

Firsly, DNS security. If I can spoof DNS (which doesn't look to hard) I
can provide the address of my server in any of the records of interest.
A request for your certificate will come to my server and I will send
back the certificate that I have constructed for you. If you ask for a
CRL I will give you one that doesn't name this certificate. If you
choose to use a validation service like OCSP that's OK because I'll
return 'valid' for your/my certificate.

Denial of service is the best bad behaviour you can expect. Positively
helpful service is much worse!

Secondly, you're going to send your certificate with the message. Why, I
shall do that too! So I'm still you!

It is interesting you say that the worst that can happen is that you
receive a certificate you don't trust. How do you know you don't trust
it? I should think if you already know what certificates you trust then
you don't need PKI at all!

Ron.
> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Friday, October 30, 1998 2:38 AM
> To:	Ron Ramsay; Alan Lloyd
> Cc:	Stephen Kent; [email-masked]; Rick Harvey
> Subject:	RE: Scale (and the SRV record)
> 
> 
> 
> > Phillip,
> > 
> > Thanks for taking time to develop the example.
> > 
> > Two issues:
> > 
> > 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.
> 
> > 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.
> 
> 
> 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
> > 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?
> 
> 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: Paul Koning <[email-masked]>
Date: Fri, 30 Oct 1998 10:22:13 -0500

I continue to be amazed at this thread.

It seems that there's a stream of statements of the form "<disliked
protocol X> is broken because you can open holes by denial of service
attacks on CLRs conveyed by <X>" -- and this is used as an argument
against <X>.

CRLs contain negative statements, so any attack on a CRL turns a
denial of service into a permission of service.  That's fundamental in 
CRLs, and no fiddling with the underlying directories, transports, or
whatnot will fix this.  (Well, maybe if you implement Radia Perlman's
networks with Byzantine robustness you can avoid it.)

	paul

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Fri, 30 Oct 1998 10:18:42 -0500

> return 'valid' for your/my certificate.

But I won't trust the signature on the response.

I think you are overplaying the DNS security issue. Although it is a 
concern the routers are also subject to attack. This is the case regardless
of whether they are Internet routers or Telephone switches. People tend
to forget that Kevin Mitick was not primarily a cracker, he was a phone 
phreak.

Whether the service is OCSP, LDAP or X.500 is irrelevant. They are
all vulnerable to a DNS spoofing attack when routing packets across
the Internet.

The work in DNSSec is useful and important but it is important to 
recognize that it is raising the bar for attacks by forcing them to
take place at a lower level. It does not eliminate the risk of attack.

> you don't need PKI at all!

? I think that your understanding of PKI appears to be so radically 
different from the PKIX model as to be unrelated.

PKIX makes trust decisions on the basis of the CONTENT of the signed
objects alone. If you care how you got the signed objects it isn't
PKIX.

		Phill