Subject: Re: WG Review: Open Pluggable Edge Services (opes)

From: Vernon Schryver <[email-masked]>
Date: Wed, 20 Jun 2001 10:19:21 -0600 (MDT)

> From: Adam Shostack <[email-masked]>
> To: Vernon Schryver <[email-masked]>
> Cc: [email-masked], [email-masked]

> ...
> Unfortunately, the become your own CA solution doesn't actually help
> deal with the issue of man-in-the-middle attacks.  The threat under
> discussion is that there is a proxy modifying content; we'd like to
> prevent that.  If the server sends a key without reference to some
> established authority, then the MITM may simply replace that key with
> one of its own, or translate the http-over-SSL request into a
> cleartext http request, or otherwise munge the session, because there
> is no way for the browser to figure out if the self-signed key is the
> one the server sent.
>
> (I find it unfortunate because often, become your own CA is a good 
> idea, and this is one of the few cases where its not.)

That is what Verisign would like you to believe, but it is inaccurate
in more than one way.

In fact, becoming your own CA is most of a solution to man-in-the-middle
attacks.  In practice (e.g. assuming you are not under special attack by
people who could and would also mount "back bag," TEMPEST, and other
attacks against you and your systems), all that remains is to exchange
certificates with operators of other SMTP servers and clients that you
care about.

If the IETF would be its own CA and publish a certificate for loki
somewhere at http://www.ietf.org, then those who care to cut out men in
the middle on the output of this list could do so by copying that
certificate and making a link to it (at least if they're running sendmail
8.11 or newer).

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.

Vernon Schryver    [email-masked]

---

From: Adam Shostack <[email-masked]>
Date: Wed, 20 Jun 2001 13:35:08 -0400

On Wed, Jun 20, 2001 at 10:19:21AM -0600, Vernon Schryver wrote:
| > From: Adam Shostack <[email-masked]>
| > To: Vernon Schryver <[email-masked]>
| > Cc: [email-masked], [email-masked]
| 
| > ...
| > Unfortunately, the become your own CA solution doesn't actually help
| > deal with the issue of man-in-the-middle attacks.  The threat under
| > discussion is that there is a proxy modifying content; we'd like to
| > prevent that.  If the server sends a key without reference to some
| > established authority, then the MITM may simply replace that key with
| > one of its own, or translate the http-over-SSL request into a
| > cleartext http request, or otherwise munge the session, because there
| > is no way for the browser to figure out if the self-signed key is the
| > one the server sent.
| >
| > (I find it unfortunate because often, become your own CA is a good 
| > idea, and this is one of the few cases where its not.)
| 
| That is what Verisign would like you to believe, but it is inaccurate
| in more than one way.
| 
| In fact, becoming your own CA is most of a solution to man-in-the-middle
| attacks.  In practice (e.g. assuming you are not under special attack by
| people who could and would also mount "back bag," TEMPEST, and other
| attacks against you and your systems), all that remains is to exchange
| certificates with operators of other SMTP servers and clients that you
| care about.

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.

The CA service could add value against the OPES attacker by offering
that out-of-band 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.

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.

| 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.

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume