Subject: RE: Scale (and the SRV record)

From: [email-masked]
Date: Fri, 30 Oct 1998 11:06:06 -0000

How are you going to do all this ?

The only way I can think of is that either you know or have compromised
the CA private keys.
If you know the private signature keys then all information is
compromised regardless of source.
If you don't how will you construct the Certificates, CRLs, OCSP
responses etc.

This is an attack based on the compromise of the CA, not the security of
DNS OCSP etc.

Graham Bland

> -----Original Message-----
> From: Ron Ramsay [mailto:[email-masked]]
> Sent: 30 October 1998 02:42
> To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> Cc: Stephen Kent; [email-masked]; Rick Harvey
> Subject: RE: Scale (and the SRV record)
> 
> 
> 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: Al Arsenault <[email-masked]>
Date: Fri, 30 Oct 1998 08:29:14 -0500

Since I agree with most of what Phill has to say on this topic, I'll go against
my better judgement and jump in here.

If I'm understanding this correctly, the attack of concern is as follows:
Nothing today stops me from cobbling together my own certificate-generating and
-signing software, and then generating a self-signed certificate for user "US
Verisign Primary Class 3 Public Certificate Authority" (or whatever the magic
string is that will exactly match what VeriSign uses).  This new certificate
will use the public key corresponding to a private key that I know, rather than
the one that VeriSign actually uses.  (This ignores the scenario described by
Graham, in which I've managed to obtain VeriSign's private key.)

Given this, can I get you, the unsuspecting user, to use MY certificate (and
any user certificates I then issue with it) instead of the real one?  After
all, once you've retrieved the certificate, the DN or subjectAltName field will
LOOK "right" to you, if you bother to check it.  The argument has been that
given an insecure, spoofable, distribution mechanism, I might be able to fool
you into using the wrong "VeriSign certificate".  If, for example, I can spoof
DNS and make you think that the IP address corresponding to "VeriSign.com" is,
say, 130.85.1.3,  and I control that machine (note: I don't :-) then you'll go
there for the "real certificate" and I've got you.  So, to counter that, you
need a "secure" distribution mechanism.

I frankly don't buy that argument, though.  What is required in a PKI is that I
somehow securely obtain the certificate/public key of a CA that I have chosen
to trust - normally, that's the one that issued my certificate.  If this first
step is broken - I'm fooled into accepting a certificate from a phony CA, or
whatever - then the security of the entire PKI is shot, and no X.500 directory
or other mechanism is going to help.  Once I have that public key, though, I
can detect any faked certificates based on the trust my CA has.  My CA will
have cross-certified with the REAL VeriSign Class 3 primary CA (when WHAT
freezes over? :-)   Thus, even if I get your phony VeriSign cert that looks to
be the right one based on the name, I can't build a certification path back to
a node I trust, because my CA or whomever else I trust hasn't signed your
spoof.  I'm protected against your spoof by the certificates and CRLs, not the
distribution mechanism.

(Of course, if you can trick the people I trust - my CA, for example - into
cross-certifying your fake certificate, I'm hosed.  But that just means that I
trusted some incompetent fool I shouldn't have.  A '"secure" X.500 directory
won't help at all once my CA has botched it.)

                                        Al Arsenault

--- standard disclaimer - my own opinions; don't reflect those of my employer
or of any other organization to which I may have a relationship; etc., etc., ad
infinitum, ad nauseum

At 11:06 AM 10/30/98 +0000, [email-masked] wrote: 

> The only way I can think of is that either you know or have compromised the
> CA private keys. 
> If you know the private signature keys then all information is compromised
> regardless of source. 
> If you don't how will you construct the Certificates, CRLs, OCSP responses
> etc. 
>
> This is an attack based on the compromise of the CA, not the security of DNS
> OCSP etc. 
>
> Graham Bland 
>
> > From: Ron Ramsay
> [<mailto:[email-masked]>mailto:[email-masked]
> om.au] 
> > > To:Ron Ramsay; Alan Lloyd 
> > > Cc:Stephen Kent; [email-masked]; Rick Harvey