Re: Certificate proposal

At 4:46 PM 10/9/95, Hal wrote:
>Bill Stewart <stewarts@ix.netcom.com> writes:
....
>>also a signed attribute statement from the Bank's key that it's a bank, etc.
>>The meaning of the certificates changes a bit, but there's still a certificate
>>from the bank binding Alice's Key to Alice's Bank Account.
>
>I can see using keys with attributes in this way, for credentials or as
>other forms of authorization.  But what about for communications privacy?
>What is the attribute that tells you that using this key will prevent
>eavesdropping?

For communication, the only credential Alice needs to ensure that only Bob
can read her message is that she uses Bob's public key. If "Bob the Key"
reads it, presumably it was "Bob the Person" who read it.

(Again, Bob the Key = Bob the Person to many of us. If Bob the Person has
let his private key out, so that Chuck the Person is also able to read the
Bob the Key stuff, etc., then of course cryptography cannot really handle
this situtation.)

--Tim May


Views here are not the views of my Internet Service Provider or Government.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."

tcmay@got.net (Timothy C. May) writes:
>For communication, the only credential Alice needs to ensure that only Bob
>can read her message is that she uses Bob's public key. If "Bob the Key"
>reads it, presumably it was "Bob the Person" who read it.

>(Again, Bob the Key = Bob the Person to many of us. If Bob the Person has
>let his private key out, so that Chuck the Person is also able to read the
>Bob the Key stuff, etc., then of course cryptography cannot really handle
>this situtation.)

OK, but again, what about the man in the middle attack?  Suppose the
key that you found that claims to be from Bob is actually not his, but
another one created by a man in the middle, such as Bob's malicious
ISP?  Then that ISP is decrypting the messages Alice sends to him using
that fake key, and re-encrypting them using Bob's real key.  He is
reading all of the messages, and Alice and Bob do not in fact have
communications privacy.

I don't want to overstate the risk of this attack.  It would not be an
easy one to mount and I believe there are countermeasures which could
detect it unless the MITM had nearly supernatural powers.  But the MITM
attack is normally considered seriously in discussing crypto protocols.
It is a well known weakness in Diffie-Hellman, for example.  That is why
authenticated Diffie Hellman is used in some of the newly proposed key
exchange protocols for IP.  The risks of MITM attacks on public key
systems was recognized not long after those systems were proposed.  The
problems with fake keys have been discussed for over a decade.

Why is this all suddenly irrelevant?  Were these attacks never realistic?
Is it just not a problem somehow?  I am baffled by the fact that people
are just turning their backs on all these years of research and
experience.  If this is some kind of paradigm shift in which the idea of
communicating with keys is seen as the key to the puzzle, then I am
afraid I don't share the enlightenment.  To me the problem seems as real
as ever.

Hal

In the situation you cite, Bob doesn't know Alice apart from
their email correspondence?

	In this case the ISP is acting as extension-of-alice. Bob
thinks he is talking to Alice but he is talking to ISP+Alice. What
difference does it make, if Bob has no knowledge of Alice outside
their email discussion, that Bob is talking to ISP+ Alice rather than
just alice. From Bob's perspective, Alice is really an alias for
ISP+Alice. (The same goes for Alice in the other direction.)

	In tim's words, from alice's point of view "Bob the key" ==
"BOB the person and Bob's ISP". From Bob's point of view "Alice the
key" == "Alice the person & Bob's ISP".

	The MITM attack only matters if there is a context outside the
email correpondence. (Say, perhaps, a drug deal which involves real
physical goods.) 

	More concretely, All I know of 'Hal' is through is emails. If
his ISP is intercepting the email between him and me, then my
definition of 'Hal' is 'Hal+ISP' -- it doesn't make a real difference
unless there is another context involved.

	(The MITM is still -important- though, because in most
situations there *is* some external context)



> 
> tcmay@got.net (Timothy C. May) writes:
> >For communication, the only credential Alice needs to ensure that only Bob
> >can read her message is that she uses Bob's public key. If "Bob the Key"
> >reads it, presumably it was "Bob the Person" who read it.
> 
> >(Again, Bob the Key = Bob the Person to many of us. If Bob the Person has
> >let his private key out, so that Chuck the Person is also able to read the
> >Bob the Key stuff, etc., then of course cryptography cannot really handle
> >this situtation.)
> 
> OK, but again, what about the man in the middle attack?  Suppose the
> key that you found that claims to be from Bob is actually not his, but
> another one created by a man in the middle, such as Bob's malicious
> ISP?  Then that ISP is decrypting the messages Alice sends to him using
> that fake key, and re-encrypting them using Bob's real key.  He is
> reading all of the messages, and Alice and Bob do not in fact have
> communications privacy.
> 
> I don't want to overstate the risk of this attack.  It would not be an
> easy one to mount and I believe there are countermeasures which could
> detect it unless the MITM had nearly supernatural powers.  But the MITM
> attack is normally considered seriously in discussing crypto protocols.
> It is a well known weakness in Diffie-Hellman, for example.  That is why
> authenticated Diffie Hellman is used in some of the newly proposed key
> exchange protocols for IP.  The risks of MITM attacks on public key
> systems was recognized not long after those systems were proposed.  The
> problems with fake keys have been discussed for over a decade.
> 
> Why is this all suddenly irrelevant?  Were these attacks never realistic?
> Is it just not a problem somehow?  I am baffled by the fact that people
> are just turning their backs on all these years of research and
> experience.  If this is some kind of paradigm shift in which the idea of
> communicating with keys is seen as the key to the puzzle, then I am
> afraid I don't share the enlightenment.  To me the problem seems as real
> as ever.
> 
> Hal
> 


-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

sameer <sameer@c2.org> writes:

>	In the situation you cite, Bob doesn't know Alice apart from
>their email correspondence?

Right.  My goal is to have a system in which two individuals who have
never met can communicate securely.  This is not too radical a notion, I
trust.  In fact, I would go so far as to say that to a considerable
extent it is the whole point of public key cryptography.

>	In this case the ISP is acting as extension-of-alice. Bob
>thinks he is talking to Alice but he is talking to ISP+Alice. What
>difference does it make, if Bob has no knowledge of Alice outside
>their email discussion, that Bob is talking to ISP+ Alice rather than
>just alice. From Bob's perspective, Alice is really an alias for
>ISP+Alice. (The same goes for Alice in the other direction.)

What difference does it make?  I'll tell you.  It means that their
conversation is not private!  It means that their cryptography is
useless, that it has failed.  It means they have an unsecure channel.  I
don't know how I can put it more plainly than this.  I wrote a long
article a few days ago arguing that they almost might as well not use
cryptography if they're going to adopt this stance.  Let anyone
eavesdrop, and from Bob's point of view when he thinks he is talking to
Alice he is actually talking to eavesdroppers+Alice.  From his point of
view, Alice is just an alias for eavesdroppers+Alice.  Etc., etc.

>	In tim's words, from alice's point of view "Bob the key" ==
>"BOB the person and Bob's ISP". From Bob's point of view "Alice the
>key" == "Alice the person & Bob's ISP".

This is not a useful or appropriate way to think of the world, IMO.  If
you do this, then from your perspective people become bafflingly
unreliable.  I wrote all about this before.

>	The MITM attack only matters if there is a context outside the
>email correpondence. (Say, perhaps, a drug deal which involves real
>physical goods.) 

Try to think of it not in relativistic or epistemological terms, but
rather look at it in terms of reality.  The real world exists, and in it
exist real people.  We can agree on this much, right?  Two of these
people want to communicate securely.  That is not such a stretch of the
imagination, is it?  By "communicate securely" I mean they exchange
information in such a way that other people don't receive it.

Now surely it is clear that with this definition of the problem,
approaches which redefine people to mean people+eavesdroppers are not
responsive.  Perhaps the motivation to do so is simply the belief that
the problem is not solvable as stated.  If so, I'd like to hear someone
say this.

Hal

Hal writes:
>Try to think of it not in relativistic or epistemological terms, but
>rather look at it in terms of reality.  The real world exists, and in it
>exist real people.  We can agree on this much, right?  Two of these
>people want to communicate securely.  That is not such a stretch of the
>imagination, is it?  By "communicate securely" I mean they exchange
>information in such a way that other people don't receive it.

>Now surely it is clear that with this definition of the problem,
>approaches which redefine people to mean people+eavesdroppers are not
>responsive.  Perhaps the motivation to do so is simply the belief that
>the problem is not solvable as stated.  If so, I'd like to hear someone
>say this.

This whole issue is a philosophical one.  The issue is the "ontology"
of electronic relationships.  The argument presented is analogous to
the "Turing test" for artificial intelligence.  The MITM is relevant
only where two commuicating parties share no channels which the MITM
doesn't control, otherwise they exchange one secret over such a channel
and Mitch is hosed (with probability 1/2^h, where h is the entropy of
the secret).

Now, if Alice communicates with an entity she knows as "Bob", which in
"reality" is Bob filtered by Mitch, I think we can readily agree that
Alice probably cannot communicate securely with Bob.  She *can*,
however, communicate in perfect secrecy with "Bob" -- the amalgamation
of Bob and Mitch.  The ontological issue comes about when we ask who it
is with whom Alice *wants* to communicate.  I'd maintain that Bob has
no ontological status with Alice.  She knows nothing of Bob, only of
"Bob".  Therefore, she must be intending to communicate with "Bob", and
her communication is secure.

An entity cannot have a meaningful ontological status until some
communication occurs.  The status which results from the communication
is "the entity, calling itself Bob, with whom I communicated over
channel X".  When a second communication occurs, we may have "the
entity, calling itself Bob, with whom I communicated over channel Y".
If the second communication contains an authenticating transaction,
then we can note that the two entities are the same.  This is what we
really mean by authentication, anyway.

As long as Mitch is successful in his MITM attack, then Bob is not an
entity with respect to Alice.

If Alice finds a key that purports to belong to Bob, about whom she
previously knows nothing, what possible relevance can it have whether
it really belongs to Bob or to "Bob" --- there is nothing in Alice's
mind to distinguish the two.

If Alice finds a key that purports to belong to Carol, about whom she
knows something, then she must execute an authentication protocol with
the new key to verify that the entity with whom it permits
communication is actually Carol, and not "Carol".

Identifying the key with the person is entirely reasonable, if the key
is what introduced the person to you (and thus ontologically created
the entity).  If the introduction happens prior to receiving the key,
then authentication becomes necessary to avoid MITM.

Hal said:
> Try to think of it not in relativistic or epistemological terms, but
> rather look at it in terms of reality.  The real world exists, and in it
> exist real people.  We can agree on this much, right?  Two of these
> people want to communicate securely.  That is not such a stretch of the
> imagination, is it?  By "communicate securely" I mean they exchange
> information in such a way that other people don't receive it.

If the devil runs the entire network, Alice and Bob are out of luck.
They can't absolutely guarantee that this is not the case.

But as you point out, it is useless to say, "This key lets you talk
securely to Alice and anyone else who may be listening."  This
hard-codes your paranoid fantasies into the semantics of the system.
Overestimating the threat can result in bad decisions just as
underestimating can.  I've seen people on Usenet say, "The NSA can
break anything, so why bother with PGP?"

What we want is for two parties, presumed trustworthy, to be able to
communicate with some confidence that they are not being eavesdropped
upon by any opponent with realistic capabilities.  This is feasible.
This is a useful thing to be able to do.  Defining the problem away is
less useful. 

I could say more, but I'm not certain I really understand this whole
conversation, so I'll hold off for now.

--
   Eli Brandt
   eli+@cs.cmu.edu

Scott Brickner writes:
 > [ ... a bunch of stuff I have no quarrel with ... ]
 >
 > Identifying the key with the person is entirely reasonable, if the key
 > is what introduced the person to you (and thus ontologically created
 > the entity).

Right (sez me).

 > If the introduction happens prior to receiving the key,
 > then authentication becomes necessary to avoid MITM.

Maybe I'm not sure what good a "true name" certificate is going to do
me in establishing confidence in a key.  How will I know that the
MITM attack didn't begin with the "true name" registration?

(Note that I continue to insist that I very well might be totally
without clue here, so correct me brutally if applicable.)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

hfinney@shell.portal.com writes:
 > >just alice. From Bob's perspective, Alice is really an alias for
 > >ISP+Alice. (The same goes for Alice in the other direction.)
 > 
 > What difference does it make?  I'll tell you.  It means that their
 > conversation is not private!  It means that their cryptography is
 > useless, that it has failed.

But if by all means available Bob and Alice satisfy themselves that
their conversation *is* secure, then (until they're proven wrong) it
might as well be.  They have satisfied themselves *at least* that
their messages are in fact encrypted at some point, just as if they
walked into a room, looked around, and satisfied themselves that there
are no hidden microphones.  I don't see how you can ever do any better
than this if you're willing to imagine arbitrary powerful
men-in-the-middle.

 > This is not a useful or appropriate way to think of the world, IMO.  If
 > you do this, then from your perspective people become bafflingly
 > unreliable.  I wrote all about this before.

Gee, in my reality people already *are* bafflingly unreliable.  (You
must not be watching enough afternoon trash talk shows.)

 > Try to think of it not in relativistic or epistemological terms, but
 > rather look at it in terms of reality.  The real world exists, and in it
 > exist real people.  We can agree on this much, right?  Two of these
 > people want to communicate securely.  That is not such a stretch of the
 > imagination, is it?  By "communicate securely" I mean they exchange
 > information in such a way that other people don't receive it.

What, however, is the real difference between the MITM scenario in a
purely electronic relationship, and a "phony personality in the
middle" attack on a "flesh" relationship?  You *think* you're working
with a realtor to buy a house, but in fact it's a con artist that
betrays your trust and rips you off.  You *think* you've found the
love of your life, but in reality it's just somebody who wants to use
you for sex.  There are no guarantees.

Let me ask this:  how do you *guarantee* that you're having a truly
private in-the-flesh correspondence with a person?  And, having done
that, how do you *guarantee* that the other person will behave in an
absolutely trustworthy fashion?

 > Now surely it is clear that with this definition of the problem,
 > approaches which redefine people to mean people+eavesdroppers are not
 > responsive.  Perhaps the motivation to do so is simply the belief that
 > the problem is not solvable as stated.  If so, I'd like to hear someone
 > say this.

I certainly don't know how to solve it, but I wouldn't trust me if I
were you :-)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I have been following this MITM argument, and find the reasons for
the presentation of some of the arguments confusing.

I'm near certain everyone of those arguing understands public key, and
the use of out of band channels (physical meeting, paper mail,
alternate information provider, plastering public key hashes (eg PGP
fingerprints) everywhere by all comms mediums available, etc) to build
a web of trust, and hence reduce chances of a MITM.

I think I have seen two roughly equivalent views of the relationships
between keys and names presented, and these could be sumarised:

a) a person has-a key

 ("has-a" in an entity relationship diagram sense -- it is somthing
  that a person posses), that person may or may not choose to go by
  their true name, whilst using that key)

a) a key has attributes one of which could (optionally) be a true name

both cases use the same techniques of using all available out of band
comms channels, to make life as tough as possible for the MITM.

So far so good.

Now the puzzling stuff is people who appear to be arguing that MITM is
unimportant, and the whole thing revolves around some relativistic
world view, and it somehow doesn't matter if there is an eavesdropper
so long as you have not yet discovered this.

As it quite clearly does matter, and I can't see how that view
provides anything useful, I assume that there is some theoretical
point these people are trying to make which I fail to grasp.

Anyone care to fill me in as to what this concept is?

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.

Adam

It occurs to me that perhaps I have been missing a point here when people
argue that having a "man in the middle" is not that different from
various forms of secure communication, such as where Bob has multiple
personalities or is a committee.  I have been taking this to mean that we
should therefore not worry about MITM attacks, which seems crazy to me.

Instead perhaps this was meant as a "reductio ad absurdum" argument for
why MITM attacks cannot be prevented in the scenario where people have no
out-of-band contact.  Anything which could detect and prevent MITM
attacks could, by this analogy, detect whether Bob had multiple
personalities.  Since the latter is obviously impossible, the former must
be as well.  Hence the problem has no solution and we should not
waste much time on it.

I don't fully agree with this but at least it is not as bizarre as the
first interpretation.

Hal

I rather figured there was miscommunication here.


> 
> It occurs to me that perhaps I have been missing a point here when people
> argue that having a "man in the middle" is not that different from
> various forms of secure communication, such as where Bob has multiple
> personalities or is a committee.  I have been taking this to mean that we
> should therefore not worry about MITM attacks, which seems crazy to me.
> 
> Instead perhaps this was meant as a "reductio ad absurdum" argument for
> why MITM attacks cannot be prevented in the scenario where people have no
> out-of-band contact.  Anything which could detect and prevent MITM
> attacks could, by this analogy, detect whether Bob had multiple
> personalities.  Since the latter is obviously impossible, the former must
> be as well.  Hence the problem has no solution and we should not
> waste much time on it.


	My point is not that MITM has no solution and that time should
not be wasted but that context (in many cases out-of-band contact, but
not necesarily) is an important factor when dealing with MITM. A
context-free situation is not a very useful thing to look at when
trying to solve MITM -- MITM should be looked at in context-based
situations.

> 
> I don't fully agree with this but at least it is not as bizarre as the
> first interpretation.
> 
> Hal
> 


-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

>  Hence the problem has no solution and we should not
 > waste much time on it.

Exactly. If a public key ONLY has an existence in cyberspace (as per
Pr0duct Cipher) then it is impossible to prove that they aren't
surrounded by a MITM cloud which is also seeing everything they
see without them knowing it.

It is important to be aware of this. However the importance is
perhaps mitigated by the following considerations:

1. Surrounding someone with such an MITM cloud is so hard as to
   be impossible for practical purposes. This will be more true
   if the person trying to establish a cyberspace identity can
   prove that they move around physically and use different service
   providers at different times [but then again perhaps if you
   do that you cease to be a purely cyberspace entity].

2. If the other end of the communication is a purely cyberspace
   entity then you can't possibly establish the sort of relationship
   which would enduce you to send them anything really secret. The
   possibility that there might be a baddy playing MITM is 
   infinitesimal compared to the probability that the other end
   is itself a baddy.

The time you will want to deal with a cyberspace entity is where
you are taking no risks and they are taking all the risks.
This will hopefully be the case when we are a seller and they are
the buyer. As long as we get the digital cash we don't care who
they are.

Apart from that we will always want some certificate that links the
public key to something in the real world. The point of the
key-centric approach is that that doesn't have to be a name or
something that contains a name. If we want to make sure the key
belongs to the person you were talking to last night then maybe you'd
like some biometric data: "five foot two, eyes of blue,...". And
of course the certificate is useless unless it is signed by a key
that we trust for that purpose.

Bob Smart

P.S. I hope my earlier posting were not interpreted as being critical
of the IPSEC effort. I strongly support it. It would be silly to
go to them and say "hold everything I think we need a whole new
security architecture". That is something for the future that we
are only just starting to think about. However I think the IPSEC
work confirms the difficulties of the current "name first then
key" approach. Whenever it is incorporated in any protocol from
network layer to application it makes the protocol at least twice
as complex and at least twice as hard to manage.

"Never underestimate the effort your opponent will expend on
cryptanalysis."  -- Robert Morris, Sr., speaking at Crypto '95

	If a MITM attack would be useful, then there will be times
when one will be mounted.  It might take 30 law enforcement officers
to do it, but it has been demonstrated that the FBI will use that many
people for a year or more on some cases.  The CIA and NSA can be
presumed to be willing to spend more time and effort to get certain
results.

Bob Smart wrote:

| Exactly. If a public key ONLY has an existence in cyberspace (as per
| Pr0duct Cipher) then it is impossible to prove that they aren't
| surrounded by a MITM cloud which is also seeing everything they
| see without them knowing it.
| 
| It is important to be aware of this. However the importance is
| perhaps mitigated by the following considerations:
| 
| 1. Surrounding someone with such an MITM cloud is so hard as to
|    be impossible for practical purposes. This will be more true
|    if the person trying to establish a cyberspace identity can
|    prove that they move around physically and use different service
|    providers at different times [but then again perhaps if you

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

Adam Shostack writes:
 > 	If a MITM attack would be useful, then there will be times
 > when one will be mounted.  It might take 30 law enforcement officers
 > to do it, but it has been demonstrated that the FBI will use that many
 > people for a year or more on some cases.  The CIA and NSA can be
 > presumed to be willing to spend more time and effort to get certain
 > results.

Right; if there's that much energy being expended, then I have no
reason to trust that just because the Department of Keys tells me that
a particular key belongs to one "Alice B. Crypto" it's really the same
Alice I think I know.  I'll make sure that we verify our keys in
person.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Bob Smart <smart@mel.dit.csiro.au> writes:

> >  Hence the problem has no solution and we should not
> > waste much time on it.

>Exactly. If a public key ONLY has an existence in cyberspace (as per
>Pr0duct Cipher) then it is impossible to prove that they aren't
>surrounded by a MITM cloud which is also seeing everything they
>see without them knowing it.

Well, I don't think this is true.  First of all, the MITM has limited
powers.  He may be able to perform certain automated and occasionally manual
replacements on messages, but he is not able to affect communications
which take place off of the net.  In particular, he is not able to stop
Pr0duct Cipher from reading Verisign's key fingerprint in the newspaper
and comparing it with his own copy of the key.  And if PC has a valid
Verisign key then he can know that he has a valid key for other people.
If he then sends mail to those people using their keys, the MITM cannot
control that mail.  Hence PC can communicate securely with other people
even if the MITM controls all of his network communication, contrary to
the claims of impossibility.

>It is important to be aware of this. However the importance is
>perhaps mitigated by the following considerations:

>1. Surrounding someone with such an MITM cloud is so hard as to
>   be impossible for practical purposes. This will be more true
>   if the person trying to establish a cyberspace identity can
>   prove that they move around physically and use different service
>   providers at different times [but then again perhaps if you
>   do that you cease to be a purely cyberspace entity].

If only one ISP is used (which is true for the vast majority of people)
and if they only get and send keys in specific ways then I would not say
it is impossible.  Look at programs like Satan or the internet worm.
They contain many different possible attacks.  Writing such programs is
almost an exercise in tedium as much as creativity.  In the same way it
would be possible for a filter program to anticipate a dozen or more
different ways in which a user might get keys from the net, and make
substitutions.  Doing it for any given method is not that hard, so it is
just a matter of motivation to do it for 99% of the ways people will
use.

>2. If the other end of the communication is a purely cyberspace
>   entity then you can't possibly establish the sort of relationship
>   which would enduce you to send them anything really secret. The
>   possibility that there might be a baddy playing MITM is 
>   infinitesimal compared to the probability that the other end
>   is itself a baddy.

Not necessarily.  As I argued before, we do establish trust relationships
in the real world.  And we do that on the basis of communication.  Yes,
in real life there are wider communication channels, nonverbal ways of
judging the sincerity of others.  But over time I would guess that online
relationships can take on the same character.  In fact, I have read
countless puff pieces about friendships, even romances, formed online.
The notion that you can't possibly establish the sort of relationships
online which would induce you to share secrets is demonstrably false, at
least for many people.

>The time you will want to deal with a cyberspace entity is where
>you are taking no risks and they are taking all the risks.
>This will hopefully be the case when we are a seller and they are
>the buyer. As long as we get the digital cash we don't care who
>they are.

That's an awfully limited way of looking at things.  We do a lot more
online than buy and sell.

>Apart from that we will always want some certificate that links the
>public key to something in the real world. The point of the
>key-centric approach is that that doesn't have to be a name or
>something that contains a name. If we want to make sure the key
>belongs to the person you were talking to last night then maybe you'd
>like some biometric data: "five foot two, eyes of blue,...". And
>of course the certificate is useless unless it is signed by a key
>that we trust for that purpose.

No, I don't think this is at all useful.  The VAST majority of people I
talk to on the net are people I have never met.  What earthly use is a
credential that key so-and-so belongs to a person with blond hair, in
helping me to establish secure communications?  Should we only talk
online to the miserable few people we live near who share our interests?
The net is global!  Virtual communities allow niche interests (like ours)
to attract people from all over the world.  Any scheme which requires
face to face meetings between every pair of participants is doomed.

Hal

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.

 > 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 kinda wish somebody with more of a clue than I have would support
me or tell me to shut up :-]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

Scott Brickner writes:
 > I disagree.  The MITM is foiled by one successful communication. 

I'm going to need some clarification of this; what is meant by
"successful"?  If you mean "a communication without a MITM
participating", and presuming also that that communication would
involve a key validation, then I suppose it's true.  However, I don't
see how this success can be evaluated if the parties do not have
nearly complete control over the communications substrate.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mike McNally writes
>
>Scott Brickner writes:
> > I disagree.  The MITM is foiled by one successful communication. 
>
>I'm going to need some clarification of this; what is meant by
>"successful"?  If you mean "a communication without a MITM
>participating", and presuming also that that communication would
>involve a key validation, then I suppose it's true.  However, I don't
>see how this success can be evaluated if the parties do not have
>nearly complete control over the communications substrate.

By "successful" I mean communicating without the MITM *interfering*.
Either the parties need to exchange a symmetric key without the MITM
eavesdropping, or exchange asymmetric keys without the MITM modifying
them.

The chance of failure is minimized by diversity in the channels used to
try to bypass the MITM.  The issue becomes one of risk management.  If
you can't afford a failure, you *do* need a channel over which you have
nearly complete control.  The simplest such channel is a physical
meeting, during which you exchange public keys.  If the MITM threat is
from your ISP, you are likely to bypass his control with the telephone
network.  Any single success is adequate.

hfinney@shell.portal.com writes:
 > OK, but again, what about the man in the middle attack?  Suppose the
 > key that you found that claims to be from Bob is actually not his, but
 > another one created by a man in the middle, such as Bob's malicious
 > ISP?

You have several alternative means of verifying the key:

1) You can meet Bob at a local Pizza Hut and verify the key in person.

2) You can go through a variety of channels to a variety of other
trusted entities and verify with them that they're using the same key
for Bob.

3) You can set up some sorts of communications tests to "probe" for a
MITM situation, perhaps by passing through "seeded" information (data
taggants?).

 > I don't want to overstate the risk of this attack.  It would not be an
 > easy one to mount ... The risks of MITM attacks on public key
 > systems was recognized not long after those systems were proposed.  The
 > problems with fake keys have been discussed for over a decade.
 >
 > Why is this all suddenly irrelevant?  

I don't think it is irrelevant, I just think it's orthogonal to the
issue of whether a certificate for a key<-->entity relationship is
considered to be the key or an adjunct to the key.  I could be wrong,
of course.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

m5@dev.tivoli.com (Mike McNally) writes:

>You have several alternative means of verifying the key:

>1) You can meet Bob at a local Pizza Hut and verify the key in person.

>2) You can go through a variety of channels to a variety of other
>trusted entities and verify with them that they're using the same key
>for Bob.

>3) You can set up some sorts of communications tests to "probe" for a
>MITM situation, perhaps by passing through "seeded" information (data
>taggants?).

I will agree that there are alternatives to certificates.  I alluded to
this in the part of my message which you elided below, about defeating
MITM attacks via various techniques.  However, it may not be as easy to
automate these tests as to automate a certificate check, and in
particular the more automated the tests become the more plausible it
would be that the MITM could recognize and defeat a standard test.

> > I don't want to overstate the risk of this attack.  It would not be an
> > easy one to mount ... The risks of MITM attacks on public key
> > systems was recognized not long after those systems were proposed.  The
> > problems with fake keys have been discussed for over a decade.
> >
> > Why is this all suddenly irrelevant?  

>I don't think it is irrelevant, I just think it's orthogonal to the
>issue of whether a certificate for a key<-->entity relationship is
>considered to be the key or an adjunct to the key.  I could be wrong,
>of course.

The POV I am really arguing against is the one that defines identity to
be a key, that states that in communicating with a key you are by
definition communicating with the person you have in mind.  The man in
the middle attack does not exist because from your point of view the
entity at the other end of the communication channel is just the MITM
plus the person you think you are talking to.  This idea has been
expressed many times by other people in this discussion, and it is this
which I think is fundamentally flawed and even dangerous because it
encourages the use of untested keys.  In fact it seems to define away
the question of whether a key is real or fake.

Hal

> 
> The POV I am really arguing against is the one that defines identity to
> be a key, that states that in communicating with a key you are by
> definition communicating with the person you have in mind.  The man in
> the middle attack does not exist because from your point of view the
> entity at the other end of the communication channel is just the MITM
> plus the person you think you are talking to.  This idea has been
> expressed many times by other people in this discussion, and it is this
> which I think is fundamentally flawed and even dangerous because it
> encourages the use of untested keys.  In fact it seems to define away
> the question of whether a key is real or fake.
> 
> Hal
> 


Suppose you have Alice, Bob, and Mallet. (Mallet is the convention for
the MITM, right?)

	Suppose Alice and Bob are communicating privately. Suppose
that Mallet is one of Bob's personalities, because he suffers from
multiple personality disorder.

	How is this different from where Mallet is actually Bob's ISP?

	Even if Alice & Bob were talking in person, privately, Alice
doesn't know that she is also talking to Mallet. My point is that
given no other context, there is *no way* to know for certain that you
are communication with the person you have in mind.

	Or suppose that Bob is a drug user doing a plea bargain. He
agrees to have his communications monitored via MITM attack to get a
lesser sentence. He buys drugs from Alice and Alice gets caught.

	The thing I am emphasizing here is the necessity to have some
sort of -context- when addressing MITM. In a situation without
context, MITM is not an issue. In a situation -with- context, MITM is
an issue.


-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:	 510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

hfinney@shell.portal.com writes:
 > >3) You can set up some sorts of communications tests to "probe" for a
 > >MITM situation, perhaps by passing through "seeded" information (data
 > >taggants?).
 > 
 > I will agree that there are alternatives to certificates.  

I'm a little confused, I guess.  What is it about certificates that
you'll trust with such confidence?  How do you know that the guarantor
of a certificate wasn't spoofed by an MITM attack?  How do you know
that the certificate itself wasn't spoofed?

 > >I don't think it is irrelevant, I just think it's orthogonal to the
 > >issue of whether a certificate for a key<-->entity relationship is
 > >considered to be the key or an adjunct to the key.  I could be wrong,
 > >of course.
 > 
 > The POV I am really arguing against is the one that defines identity to
 > be a key, that states that in communicating with a key you are by
 > definition communicating with the person you have in mind.  The man in
 > the middle attack does not exist because from your point of view the
 > entity at the other end of the communication channel is just the MITM
 > plus the person you think you are talking to.  

I think it's more correct to say that the MITM attack is acknowledged
to be possible, but realistically no more of a threat than in a
certificate model.   And note the "I think", and this warning that I
could be wrong.  (Or I could be an MITM...  bwahahahaha!)

 >                                                    This idea has been
 > expressed many times by other people in this discussion, and it is this
 > which I think is fundamentally flawed and even dangerous because it
 > encourages the use of untested keys.  In fact it seems to define away
 > the question of whether a key is real or fake.

Oh now wait a sec here; I don't think anybody's advocated using
"untested" keys.  It's still perfectly reasonable to establish
networks of reliable information focused on a key.

If I electronically "encounter" Alice and decide to begin a secure
conversation, we initiate a key exchange.  I can then go to as many
already-trusted entities as I like in an attempt to verify that as
many attributes that are claimed to be associated with the key are
really there as I desire.  If Alice wants to buy a widget from me, I
can ask other businesses whether they've ever had problems collecting
from that key.  If I want to buy a widget from Alice, I can ask
friends whether they've gotten good widget from that key.  If I'm
interested in a little e-hanky-panky, I can ask around the sleazier
corners of the net to see whether Alice is the kiss-and-post type.

Somebody's going to have to explain to my thick skull how it is that a
certificate system makes this process any different, fundamentally.  I
mean, it may be that there's more superficial security, but I don't
see where there's any additional risk truly introduced by using the
key itself as a "True Name".  Maybe the real question is, how does a
certificate system give me the confidence that there really is an
"Alice" according to some definition of "really" that satisfies me?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mike McNally wrote:

> interested in a little e-hanky-panky, I can ask around the sleazier
> corners of the net to see whether Alice is the kiss-and-post type.
> 
> Somebody's going to have to explain to my thick skull how it is that a
> certificate system makes this process any different, fundamentally.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
*This Key was signed by AidsFree Inc., a THL (Trusted HIV Laboratory)*
 
 The Time-Stamped Public Key of AidsFree Inc. can be found at:
 shttp://health.cdc.gov/hiv/trusted_labs/aidsfree/dec-99/

 Date: 20/12/99
 Aidsfree Inc. certifies that a person (*Alice*) in proven 
 posession of This Key was tested HIV negative at this date.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

m5@dev.tivoli.com (Mike McNally) writes:
>I'm a little confused, I guess.  What is it about certificates that
>you'll trust with such confidence?  How do you know that the guarantor
>of a certificate wasn't spoofed by an MITM attack?  How do you know
>that the certificate itself wasn't spoofed?

I believe that the certificate wasn't spoofed by an MITM attack because 
the certificate issuing process requires face to face contact with some
proof of identity, in at least one way of doing this.  The certificate
wasn't spoofed because I got the key of the signer through an out of band
mechanism, such as seeing it printed in the newspaper.

The main requirement is to have some contact between Alice and the rest
of the world which doesn't go through the MITM, and the same for Bob.  By
using certificates, this contact only has to be done once (for each of
them).  There is no need for Alice and Bob themselves to have a face to
face meeting, nor for Alice and Charlie, Alice and Dave, Bob and Charlie,
Bob and Dave, Dave and Charlie, etc.  Just the one will suffice.

>I think it's more correct to say that the MITM attack is acknowledged
>to be possible, but realistically no more of a threat than in a
>certificate model.   And note the "I think", and this warning that I
>could be wrong.  (Or I could be an MITM...  bwahahahaha!)

I'm not sure whether this is because you think MITM is so difficult as
to be almost impossible in any model, or whether you think that an MITM
attack is possible in some cases against relatively naive users, but that
certificates won't help at all in that case.

Let me make clear how I would see a MITM attack working.  There are two
main flavors, the permanent and the transitory.  Here is how the
permanent MITM could work.

Alice's ISP provides all of her email services.  She has created and
published a public key, but the ISP has detected this and replaced it
with a fake key.  Everyone who tries to send to her using that key gets
their message decrypted and read by the ISP, then re-encrypted using
Alice's real key and delivered to her mailbox.  This much would be
relatively easy.

But it is not enough.  If Alice gets hold of a good key for Bob, she will
send messages to him using that key.  The ISP can't read those messages.
If she signs them, Bob will notice that the signature doesn't check
against his copy of Alice's key (the one which the ISP has installed in
place of Alice's real one), and the ISP will be caught.

Therefore the ISP is going to have to make sure that every single key
Alice gets is a fake one, one for which the ISP has the secret key.
When Alice get's Bob's key, Charlie's, everybody's, the ISP has to
replace those with fake versions.  Then again it can do its
translate-and-replace trick on messages going in both directions.  This
is obviously a much more difficult task, but if people acquire keys in
limited, stereotyped and automated ways, it could conceivably be done.

With this, what more could trip the MITM up?  Well, if anybody ever
included any keys within the body of a message, those would have to be
detected and substituted.  Even key fragments might have to be handled,
although it is unlikely that this would be noticed.

The biggest threat would be if Alice used a different method to get
someone's keys, her own or anybody's that she communicates with.  She
could use a different ISP or use some "out of band" (off-net) method.
If she went to a key signing party the jig would be up.

Does this mean that the MITM attack is impossible?  Not necessarily.
I'll bet there are plenty of people who only use one ISP (AOL or MSN)
and who have never been to a key signing party.  Maybe they've never
even met someone in real life whom they communicate with on the net.  A
lot of people could fall into this category.

This is where the certificate comes in handy.  A certificated key from a
signer whose key Alice is able to verify out of band will not be
forgeable by the MITM.  Likewise if Alice's key distributed on the nets
is signed by a trusted certificator then other people can have confidence
that there is no MITM involved.  Basically the certificate is a way of
forcing people, at least once, to go around their ISP.  And once is
enough.

Now let me describe the other form of MITM attack, the transitory one.
In this one the attacker doesn't care if he's caught, he just wants to
peek at a few (possibly crucial) messages.  Here again his attack is to
replace Alice's public key in the databases with a bogus one, and to
intercept her communications.  Or maybe he is attacking SSL or some
other protocol where one side sends their public key to the other.
Then it is even easier to send a fake one.  People who trust and use
that key will lose their privacy.

This attack is obviously a lot easier to mount in some contexts.
Again, the use of a certificate should prevent these, and in fact SSL
does use certificated keys.  The MITM will not be able to supply a
certificated key with the name/address information for Alice.
(Netscape currently doesn't check to see whether the name in the key is
valid, so it is not getting much benefit from the use of certificates.
I hope it is clear that abandoning certificates or using ones without
any name or address information would make SSL very unsafe.)

>Oh now wait a sec here; I don't think anybody's advocated using
>"untested" keys.  It's still perfectly reasonable to establish
>networks of reliable information focused on a key.

>If I electronically "encounter" Alice and decide to begin a secure
>conversation, we initiate a key exchange.  I can then go to as many
>already-trusted entities as I like in an attempt to verify that as
>many attributes that are claimed to be associated with the key are
>really there as I desire.  If Alice wants to buy a widget from me, I
>can ask other businesses whether they've ever had problems collecting
>from that key.  If I want to buy a widget from Alice, I can ask
>friends whether they've gotten good widget from that key.  If I'm
>interested in a little e-hanky-panky, I can ask around the sleazier
>corners of the net to see whether Alice is the kiss-and-post type.

What if you just want to talk to her securely?  I asked before what
"attributes" would handle that case, and the answer that at least Tim
gave was that talking to the key is talking to Alice.  I don't buy
that, at least not yet.

(Don't get me wrong - I don't have anything against attributes.  I love
Chaum's pseudonymous credentials.  I'm just worried that unless we have a
foundation of secure communication that the rest of the edifice isn't
going to stand.)

>Somebody's going to have to explain to my thick skull how it is that a
>certificate system makes this process any different, fundamentally.  I
>mean, it may be that there's more superficial security, but I don't
>see where there's any additional risk truly introduced by using the
>key itself as a "True Name".  Maybe the real question is, how does a
>certificate system give me the confidence that there really is an
>"Alice" according to some definition of "really" that satisfies me?

OK, I wrote at length above on how certificates can help against two
forms of MITM attacks.  What do you think?  Maybe it is hard to imagine
a long-term successful MITM attack, but wouldn't you feel uncomfortable
with an SSL which used uncertificated keys?

Hal