Subject: RE: Scale (and the SRV record)

From: [email-masked]
Date: Fri, 30 Oct 1998 15:29:04 -0000

An interesting thought.

Could purchasing software from Microsoft (or Netscape or other) be
regarded as an authentication mechanism and secure distribution
mechanism for certificates.

It depends on how much you trust the software vendor (if at all).

Perhaps free certificates are just good value for money.

Graham Bland

> -----Original Message-----
> From: MHenry [mailto:[email-masked]]
> Sent: 30 October 1998 14:57
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Scale (and the SRV record)
> 
> 
> al,
> interestingly enough, the largest base of existing
> pki users (those that have browsers with a hard coded
> certs at time of purchase) do, regularly, exactly what you take for
> granted they would never do. 
> semper fi,
> mike henry
> 
> > -----Original Message-----
> > From:	[email-masked] [SMTP:[email-masked]]
> > Sent:	Friday, October 30, 1998 8:41 AM
> > To:	[email-masked]; [email-masked]
> > Subject:	RE: Scale (and the SRV record)
> > 
> > I had taken it for granted that nobody would trust a self signed
> > certificate without having validated it by either a secure 
> distribution
> > mechanism or verification of the hash from a trusted source.
> > 
> > I am pleased to say we are in total agreement. 
> > 
> > Graham Bland 
> > 
> > > -----Original Message----- 
> > > From: Al Arsenault [ <mailto:[email-masked]>] 
> > > Sent: 30 October 1998 13:29 
> > > To: [email-masked]; [email-masked] 
> > > Subject: RE: Scale (and the SRV record) 
> > > 
> > > 
> > > 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: 
> > > 
> > > > 
> > > > 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]>> 
> <mailto:Ron.Ramsay@Ope> 
> > > nDirectory.c 
> > > > om.au] 
> > > > > 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: Michael Helm <[email-masked]>
Date: Fri, 30 Oct 1998 10:02:19 -0800

> mechanism for certificates.

Getting the CD would be, perhaps....

> > granted they would never do.=20

I think that the netscape online distribution of the 128-bit
browsers is done thru an ssl connection (& a verisign
certificate for their server).  Somewhere along the line,
tho, you got a browser with a verisign CA cert via a connection
that wasn't "authenticated" in this fashion!  (NB: It may be that
the software download switches over to non ssl after you pledge
allegiance.)

The IE distribution is different.  For windows the browser itself
& related tools is done non-SSL, & you download a separate 128-bit
kit for some other part of 9*/NT via SSL.  So the built-in certs are
delivered in a non-authenticated fashion.  For Solaris (the
last time I tried this) you get a new 128-bit browser securely,
so the certs are delivered in an authenticated fashion.
(Same comment about browser applies as above.)