| Date: Fri, 03 Oct 2003 17:27:36 -0400
| From: Tim Dierks <[EMAIL PROTECTED]>
| To: Jerrold Leichter <[EMAIL PROTECTED]>
| Cc: Cryptography list <[EMAIL PROTECTED]>
| Subject: Re: anonymous DH & MITM
|
| At 03:28 PM 10/3/2003, Jerrold Leichter wrote:
| >From: Tim Dierks <[EMAIL PROTECTED]>
| >| >No; it's false. If Alice and Bob can create a secure channel between
| >| >themselves, it's reasonable to say that they are protected from MITM
| >| >attacks if they can be sure that no third party can read their messages.
| >| >That is: If Alice and Bob are anonymous, they can't say *who* can read
| >| >the messages they are sending, but they might be able to say that,
| >| >assuming that their peer is following the protocol exactly (and in
| >| >particular is not releasing the shared secret) *exactly one other party*
| >| >can read the message.
| >|
| >| They've got exactly that same assurance in a MITM situation:
| >| >unfortunately,
| >| Mallet is the one other party who can read the message.
| >But Mallet is violating a requirement: He is himself passing along the
| >information Alice and Bob send him to Bob and Alice. No notion of secrecy
| >can make any sense if one of the parties who legitimately *has* the secret
| >chooses to pass it along to someone else!
|
| In an authenticated protocol, you can have a risk model which includes the
| idea that an authorized person will not choose to share a secret with an
| unauthorized person. However, in an anonymous protocol, you cannot have
| such a risk model, because there's no such distinction.
Why not?
| Are you saying that you're defining a protocol with rules of behavior which
| cannot be enforced (namely that Mallet is breaking the protocol by
| forwarding the data)?
They can't be *enforced*, but violations can (perhaps) be detected.
| Previously, you said that you were defining the thing
| to be controlled as the shared secret, but now you're extending it to any
| and all content transmitted over the link.
The shared secret is the session key. Assuming the encryption is sufficient,
the security of this shared secret implies the security of all data exchanged
on the link.
| Describing the format of
| communications between parties is in a "protocol"; what they do with those
| communications is in a "risk model" or "trust model".
| >As long as Mallet continues to interpose himself in *all* subsequent
| >sessions between Alice and Bob, he can't be detected. But suppose each of
| >them keeps a hash value that reflects all the session keys they think they
| >ever used in talking to each other. Every time they start a session, they
| >exchange hashes. Whenever Mallet is present, he modifies the messages to
| >show the hash values for the individual sessions that he held with each
| >party seperately. Should they ever happen to form a session *without*
| >Mallet, however, the hashes will not agree, and Mallet will have been
| >detected. So the difference isn't just notional - it's something the
| >participants can eventually find out about.
|
| No disagreement with this: if you can ever communicate over an
| unintermediated channel, you can detect previous or future intermediations.
"Every being able to communicate over an unintermediated channel" can mean
two things:
1. We can communicate over such a channel *and know we are doing so*.
In that case, we can safely exchange keys, check our previous
communications, etc.
2. We sometimes communicate over such a channel, but we can't
recognize when it happens.
Case 2 is much weaker than case 1, but is sufficient to detect that Mallet
has been playing games. In fact, even case 2 is stronger than needed:
Suppose that there are multiple Mallet_i playing MITM. Any given connection
may go through any subset of the Mallets. Any time a connection happens
not to go through a particular either Mallet that "usually" talks directly
to Alice or Bob, the game is up.
| There are easier ways to do it than maintaining a hash of all session keys:
| you can just insist that the other party have the same public key they had
| the first time you spoke, and investigate if that becomes untrue (for
| example, ssh's authentication model).
Sure.
| >In fact, if we assume there is a well-known "bulletin board" somewhere, to
| >which anyone can post but on which no one can modify or remove messages, we
| >can use it as to force a conversation without Mallet. Alice and Bob can:
| >
| > [...elided...]
| >
| >If not, Mallet was at work. (For this to work, the bulletin must have a
| >verifiable identity - but it's not necessary for anyone to identify himself
| >to the bulletin board.)
|
| This can be defeated by Mallet if he makes changes in his forwarding of
| communications (that either have no semantic effect or have whatever
| semantic effect he chooses to impose), but which causes the hashes to vary.
| He then posts statements re: his communications with each of Alice & Bob,
| so they'll see a match.
This is no longer MITM as such. At what point do we say that Mallet is
simply having independent conversations with Alice and Bob?
In any case, if Alice and Bob use the Interlocked Protocol, they can tell
each other what the hash is supposed to be, and Mallet can't change the
value.
| Or, alternately, he interposes himself between Alice & Bob and the bulletin
| board, which is possible within most understandings of the MITM threat.
| (Again, if Mallet can't do that, it implies that Alice & Bob have an
| unintermediated channel available: the bulletin board).
The bulletin board isn't anonymous - it's well-known, in the sense of having
a well-known public key. Mallet can't interpose on anyone's connection to the
bulletin board. However, it's not a CA - it knows nothing about anyone else's
identity.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
