anonymous DH & MITM

[Tim Dierks]

At 03:28 PM 10/3/2003, Jerrold Leichter wrote:
>From: Tim Dierks <tim at dierks.org>
>| >No; it's false.  If Alice and Bob can create a secure channel between them-
>| >selves, 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.

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

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

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

  - Tim


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com