From: Adam Shostack <adam(_at_)homeport(_dot_)org>
...
Yes. I made a point of saying "The threat under discussion is that
there is a proxy modifying content..." because this discussion started
with OPES. In that particular case, where random people might
approach your website, you want to send them content that is
authenticated, and there is no out-of-band channel, then you don't have a
way to send them a certificate reliably.
There is no creditable threat that OPES or OPES-like mechanisms would
filter, replace, or modify my or anyone's certificates. It is silly
to imply that AOL might use something like OPES to defeat the distribution
of certificates that would wreck SMTP interception proxies like AOL's.
The CA service could add value against the OPES attacker by offering
that out-of-band channel.
That is true, but only for remote SMTP clients and servers that do
not already have certificates. Because the authentication offered by
commercial CA's is almost nil, their added value is convenience instead
of security.
(never mind that CA services are often not "out-of-band."
Do you fetch new copies of IE or Netscape with their built-in
CA lists using HTTPS or some other authenticated channel?)
Of course, the CA needs to verify that it
offers certificates only to "authorized" entities, and the browser
needs to check that the cert matches the site you think you're
visiting. So theres not a lot of value there, but there is potential.
No matter how often it is said that there is no or little value in
STARTTLS, it remains false. STARTTLS is not a sufficient defense
against serious commerical or other personal attacks, but it would be
quite sufficient against such as would use OPES without the permission
of one of the ends.
In the case of email with "servers you care about," the self-certified
key works fine; there is motivation to use an out-of-band channel such
as verifying the key at an IETF meeting, via a PGP wot, etc.
That implicit claim that site certificates must be exchanged out-of-band
to squelch data muggers such as would use OPES is obviously false. It is
obviously implausible to imply that such as would use OPES would filter
or modify either site certs or CA certs.
It is silly to imply that a cert on http://www.ietf.org/ would not be
sufficent to prevent any data mugging commercial SMTP or even HTTPS
interception proxies. A self-signed cert on http://www.ietf.org/
might be too weak to protect credit card transactions (the vendor's
exposure, not consumers's) against people hoping to steal merchandise,
but it would put a spoke in the bad uses of OPES.
To defend against other, more personal attacks, you do need to exchange
certificates out of band. If you need to worry about many such attacks,
assurances from commercal CA's are just as useless, as is obvious if
you've ever looked at what they require to do what they call verifying
identities and as the recent Microsoft/Verisign cert circus demonstrated.
| A second problem with the Verisign sales--uh--information is that there
| are hassles in detecting STARTTLS verfy=NO or =FAIL in MUA's. It's not
| good enough to have to read Received: lines to check that a message that
| looks as if it came from the IETF's list was really from the IETF's SMTP
| client. This problem has nothing to do with whether you pay Verisign's
| ridiculous fees for almost nothing. However, for squashing the data
| muggers, this problem is not relevant.
Sure. But thats for the case where you have a well-known server.
Well known servers get much less benefit from CA services than do
random ones. I'm not asserting that a random server gets substantial
benefit from a CA service; only that a well known server gets even
less.
I do not understand that paragraph either by itself or as a response
to my words. I certainly agree that a known outfit gets even less
value from a commercially CA than an obscure outfit. I've also been
saying in public for years that the so called verification of identities
done by commercial CAs is less of a joke for a big outfit. For $150
(Thwate), $250, $350, or even $900 I wouldn't hope that a commercial
CA would be able to afford to detect bogus "proofs" such as a D&B
number for Rhyolite Software, but I used Microsoft as an example of
such a big outfit that would be hard to inpersonate. I never dreamed
that Verisign couldn't recognize a fake Microsoft.