Subject: RE: [isdf] RE: Palladium (TCP/MS)

From: Franck Martin <[email-masked]>
Date: Fri, 25 Oct 2002 13:17:29 +1200

I agree with you, I found many more applications that do not support s/mime
cf SSL-Certificates HOWTO on www.tldp.org <http://www.tldp.org> .

However, you can sign messages in s/mime clear text, which works the same as
PGP by encapsulating the message in clear inside a signature... but some
systems will still not be able to handle properly this mime signature...

Note that you can set your exchange server to convert s/mime messages
automatically... On my exchange 5.5 in the Internet connector there is an
option that says clients support s/mime. If it is enabled, the s/mime
message is send as it to the client, if it is not enabled then the signature
is removed (but the user does not know he has received a signed message).

s/mime still need more work, on the implementation level...

We are in chicken-egg situation, that will be solved with a global PKI (my
opinion)...

Cheers.

 ----Original Message-----
From: Cirillo CWO2 Michael R [mailto:[email-masked]]
Sent: Friday, 25 October 2002 12:27
To: 'Franck Martin '; ''Gary Lawrence Murphy' '
Cc: ''TOMSON ERIC' '; [email-masked]' '; [email-masked]' '
Subject: RE: [isdf] RE: Palladium (TCP/MS)

MS promises S/MIME support in their next release, which would be Dec or Mar
or Jun or...  Currently, Outlook Web Access doesn't "know" S/MIME, so
certificate use is not possible.  It is possible to read a signed email and
to retrieve the attachment, but it requires Notepad or reconfig of the app
to which the PKCS #7 is associated.  Not hard.  Encrypted emails are
unreadable period.

---

From: [email-masked]
Date: Fri, 25 Oct 2002 11:26:49 -0400

> automatically... On my exchange 5.5 in the Internet connector there is an

This is, of course, assuming you are willing or able to use an exchange server.
Not all the world uses the same proprietary package (which happens to be what
originally STARTED this thread).

> We are in chicken-egg situation, that will be solved with a global PKI (my

You might want to stop, take a deep breath, and ask yourself exactly what
problems a "global PKI" will solve (you might want to go read the chapter
on PKI in Schneier's "Secrets and Lies" if you haven't already).  Now let's see:

If it's within my organization, a cert signed by my local CA is fine.  I trust
the guys upstairs from me to sign my organization's user's certs more than
I trust some top-level CA to sign a certificate-signing-cert for some group
I've never heard of.

If it's an organization that we've got ongoing business with, it's easy enough
to exchange certs and cross-sign them (a la PGP).

Now we get to the hard case - initiating contact with a group I've never
been in contact with before.  Now, if all you care about is establishing
an encrypted tunnel, a self-signed cert works *just fine*.  So there's
only two cases to worry about here:

1) A PKI *does* allow you to (somewhat) verify that the server at the other
end is who it claims to be, and that you haven't been redirected by nefarious
means (DNS cache poisoning, domain hijacking, etc) and that the server you
are talking to really *IS* the www.example.com that you wanted.  Note that
the most popular application that uses SSL is IE, and that (A) IE is well-known
for a lot of ways to hijack things (and that if you've been redirected via
Javascript XSS, and you THINK you're talking to foo1.com, but really talking to
foo2.com, then a cert for foo2.com will show "no problems" unless you actually
click on the "check cert details" button and see it's issued to foo2.com.
(B) few users seem to actually care.

2) Even if you've successfully connected to www.joes-junkyard-parts.com, and
the certificate checks out, and all that, it tells you *NOTHING* about their
business other than the fact that they qualified for a cert from some CA.
It doesn't tell you if they're just in it for the credit card fraud, or if
they will actually ship the parts, or whether they are in the habit of leaving
all the credit cards out for anonymous FTP....

I suspect that the *real* reason there's no PKI yet is because there's no
really motivating reason to have anything other than a cert for the company
webserver (in most cases).  And I suspect that this is unlikely to change
until the legal climate regarding digital signatures has changed a lot.
Not only does there need to be some legislation about it, but *also* some
case law testing what the legislation does and doesn't mean - the biggest
challenge will be defining the liability of a company if a private key is
hacked/stolen and used to sign things without permission.  As Schneier
points out, the fact that it's signed *ONLY* proves that the data and the
private key were at the same place at the same time, and says nothing about
whether it's an *authorized* signature....
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Franck Martin <[email-masked]>
Date: 26 Oct 2002 09:38:50 +1200

On Sat, 2002-10-26 at 03:26, [email-masked] wrote:

I was answering a specific point about outlook web mail, to help one
user.

You may want to think about SPAM. Certificates for web access and
protocols is well defined and working.

I agree with you about all the cert usage possibilities. They are all
valid. I will check the refrence you gave, but I have also read Peter
Gutmann tutorial on security.

I think the only question of a PKI in our case, is to initiate
communication between two people who never met. If you have to do an
handsake before the message is sent, I think it is overkill and may not
work, however tmda.sourceforge.net proposes exactly that.

The question of a global PKI is to remove anonymity. You can trace back
to a real person (legal person) from the certificate. Who can offer
that? What has to be done? This is my question...

I don't beleive (personnal view) that the web of trust is fully good.
This is interesting and I'm curious about it but someone can proxy
someone, etc.. so that When I'm trying to know who I'm dealing with I'm
lost in a web of "front companies" to name an analogy.

If signed e-mails become standard, I may decide to accept only signed
e-mail, because I will be able to know who it is, and take action...
Think about SPAM and viruses that impersonate other people...

The other application would be with IPsec, to initiate an IPSEC channel
between 2 computers that do not know each other..

At USD300 a certificate per year, IPSEC will made a few VERY rich... May
I put an analogy between the evolution of software cost to the evolution
of IP protocols cost: From Free to low cost (https) to major cost
(IPsec, e-mail) and unavoidable.

This is not an easy subject I realise that...

---

From: [email-masked]
Date: Sat, 26 Oct 2002 00:05:26 -0400

> to a real person (legal person) from the certificate. Who can offer

No. You can trace back to the fact that the signed data was at the same
place as the private key, at the same time.  It most certainly does *not*
prove that a given person intentionally signed it.

I want you to think about how many people have had things mailed out because
they've gotten an email-based worm - and then think about the fact that the
FBI *seriously* considered something called Green Lantern.  Then think about
how lax security has to be on the average to have Green Lantern actually work.

The designers of Curious Yellow (http://blanu.net/curious_yellow.html) have
some thoughts regarding worms and PKI, which you might want to read - and
consider that said worms do nothing that an attacker can't do on a one-off
basis.

I'll bet there's at least a dozen different ways to code a malicious webpage
that contains Javascript that will download a file, sign it on the victim's
PC, and upload it back to the server. No, I don't know of any, but anybody
who watches Bugtraq probably goes *yawn* at the discovery of *another* browser
hole or cross-site scripting exploit (and note that the latter can possibly
be abused as well...)

An amazing number of people never even notice they're mailing out tons of
attachments.  But let's assume the user actually notices, and realizes their
key may be compromised (and the average user will *NOT* correlate "worm" with
"compromised key")....

You get lots of bonus points for designing a PKI that's able to issue a new key
and a CRL for the old one every time somebody gets bit by Klez or *any other*
worm that mails out attachments - unless you can *prove* the attachment wasn't
your key, you need a new one.  The 4 Mirapoints on our mail hub are fast
closing in on *5 million* trapped viruses.  And we're one relatively small
site, with only 60K mailboxes. Extrapolate to 600 million mail users. That
makes for massive churn on the CRL...

There's a subtle difference between the average PKI and credit cards too -
if I *lose* my credit card, it's easy to cancel - but a lot of fraud doesn't
surface till I get my bill weeks later.  That's OK, because I can protest the
fraudulent transactions and agree to pay the legitimate part of the bill.
The average PKI has a hard time dealing with this sort of thing - even if it's
able to deal with "we got hacked 3 weeks ago and just found out", there's very
fundemental issues with what to do with the 95% of transactions since then.
Any sane PKI scheme will insist that everything in the last 3 weeks be invalid
and needs to be redone.  Good luck doing THAT, especially if the goods and
money have already been exchanged in the 95% good transactions....

> that? What has to be done? This is my question...

First off, you need a PKI that *guarantees* that this never happens:

http://www.cert.org/advisories/CA-2001-04.html

Then you need to consider that we're averaging a CERT advisory *A WEEK*
so far this century.

Right now, saying "it has a digital signature, therefor the person signed it"
is like saying "we didn't see the driver, but because this pickup truck hit
somebody, the owner did the hit and run" when the defense has a dozen witnesses
that will testify that the defendant habitually left the keys in the ignition....
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Matt Crawford <[email-masked]>
Date: Mon, 28 Oct 2002 12:35:52 -0600

> No. You can trace back to the fact that the signed data was at the same
                                         ^
                                     a hash of
> prove that a given person intentionally signed it.

I've seen people *who operate CAs* lose sight of the fact that it's
the hash that's signed, not the full data.

---

From: [email-masked]
Date: Mon, 28 Oct 2002 16:16:35 -0500

> the hash that's signed, not the full data.

OK, if you want to be pedantic. ;)

However, let's remember that although a hash collision is *possible* to
generate, you'd need on the order of 50K-100K Pentium-4 class boxes for
a *year* to generate *one* hash collision(*).  Well within the capacities of
distributed.net, but hardly the method of attack I'd choose when there's
a plethora of easier ways.

If things ever actually get secure enough that the distinction between
signing the data and a hash thereof actually matters for a real-world
threat model, I'll declare victory and retire. ;)

/Valdis

(*) That's for just a collision.  You want a collision where both hashed items
make sense as data, that will cost extra. A *lot* extra...

---

From: Matt Crawford <[email-masked]>
Date: Thu, 31 Oct 2002 09:15:35 -0600

> > > place as the private key, at the same time. 
> generate, ...

My point was not about hash collisions, but rather that the dongle
that holds the key often has no idea at all about the meaning of what
was signed.  And if it's an intruder who caused the signing, there may
be no record of the cleartext.  If it was a certificate, you can't
revoke it because you don't know its serial number or anything else[*]
about it.
			Matt
[*] Well, if NameConstraints were implemented you could put a bound
on the Subject.  That's not much comfort.