From: Scott Brickner <sjb@universe.digex.net>
Date: Mon, 9 Oct 95 16:52:11 PDT
To: m5@dev.tivoli.com (Mike McNally)
Subject: Re: Certificate proposal
In-Reply-To: <9510092311.AA27677@alpha>
Message-ID: <199510092351.TAA25651@universe.digex.net>
MIME-Version: 1.0
Content-Type: text/plain


Mike McNally writes:
>
>aba@atlas.ex.ac.uk writes:
> > Now the puzzling stuff is people who appear to be arguing that MITM is
> > unimportant
>
>Hal said this same thing in a recent note.  For myself, I've never
>meant to argue that the MITM threat is unimportant.  I've simply
>contended that you're no more vulnerable to it in the key-as-True-Name
>scenario than with a certificate-bound key-to-name relationship
>system.  If you assume an MITM could thwart the establishment of trust
>in the first case, then I guess I posit that the same energies could
>with equivalent hope for success be directed in an attack on a more
>"traditional" certificate scheme.

I disagree.  The MITM is foiled by one successful communication.  The
reason for certificates is to isolate and limit the number of
authentication transactions which are not automated.

When you get your key certified you go through some sort of
very-hard-to- subvert process.  The exact process is irrelevant, as it
merely affects the trustworthiness of the certifier.  Let's assume for
the sake of argument that the key is certified by the same organization
(DMV/MVA/DPS/whatever) that issues drivers licences, and on the same
identification criteria.  When you have your key certified, you also
get a copy of the KCA's key.  You now have enough information to
authenticate to roughly the same level as presentation of a state
issued ID card.  After the first transaction, you can accept any
key *signed* by the KCA under the same circumstances you'd accept
the id card.  But you can get KCA signed keys from almost *anywhere*,
without the overhead associated with that level of authentication.

The expensive authentication happens once, followed by a nearly
unlimited number of cheap ones.

> > Perhaps the view is based on the fact that there are plenty of
> > situations where you don't care what an entities name is, and hence
> > the attribute which should be under discussion is credit worthiness,
> > or reliability, but still you need to protect against MITM, using
> > whatever channels and means available.  I don't see how this alters
> > the argument.
>
>And this is where I start to think we're all in agreement even though
>there's an argument going on!  Yes, I think you need to protect
>against MITM attacks by whatever means are available.  I think that no
>matter what you do, if you're strictly relying on communications
>systems over which you ultimately have no control (if at some point
>somebody you simply have to trust on faith inevitably gets his hands
>on your bits), then you have to put up with a non-zero probability of
>being victimized by a MITM attack.  If you're willing on blind faith
>to trust certificates granted by some authority, you're fooling
>yourself (I claim).  If you only trust that authority because it fits
>into an established web, then I don't see why there's any need for a
>certificate binding a public key to some "True Name" constant; what's
>the point?  (How do you know the alleged True Name has any meaning in
>the first place?)
>
>I also posit that this is not really any different than the problems
>of social interaction homo sapiens have been dealing with ever since
>they grunted their way into cooperative tribal life.

I think we're still "arguing past each other."

One side seems to argue "people have keys, and we need a way to
authenticate them".  The other seems to argue "there are situations
where we don't care about the people behind the keys."

Both are correct.  As I said before, authentication is the correlation
of entities with whom you've communicated over different channels.  The
notion that "people have keys" sort of implies that you know something
about the "people".  This really means you've communicated with them
out-of-band --- even if you've just heard about them, it's a few bits
of information.  When you finally communicate in-band, you need an
authentication protocol to correlate the entity on the other end of the
current channel with the entity you have in mind.