On 10/22/2003 04:33 PM, Ian Grigg wrote: > > The frequency of MITM attacks is very low, in the sense that there > are few or no reported occurrences.
We have a disagreement about the facts on this point. See below for details.
> This makes it a challenge to > respond to in any measured way.
We have a disagreement about the philosophy of how to "measure" things. One should not design a bridge according to a simple "measurement" of the amount of cross-river traffic in the absence of a bridge. One should not approve a launch based on the "observed fact" that previous instances of O-ring failures were non-fatal.
Designers in general, and cryptographers in particular, ought to be proactive.
But this philosophy discussion is a digression, because we have immediate practical issues to deal with.
> Nobody doubts that it can occur, and that it *can* occur in practice. > It is whether it *does* occur that is where the problem lies.
According to the definitions I find useful, MITM is basically a double impersonation. For example, Mallory impersonates PayPal so as to get me to divulge my credit-card details, and then impersonates me so as to induce my bank to give him my money.
This threat is entirely within my threat model. There is nothing hypothetical about this threat. I get 211,000 hits from http://www.google.com/search?q=ID-theft
SSL is distinctly less than 100% effective at defending against this threat. It is one finger in a dike with multiple leaks. Client certs arguably provide one additional finger ... but still multiple leaks remain.
==================
The expert reader may have noticed that there are other elements to the threat scenario I outlined. For instance, I interact with Mallory for one seemingly trivial transaction, and then he turns around and engages in numerous and/or large-scale transactions.
But this just means we have more than one problem. A good system would be robust against all forms of impersonation (including MITM) *and* would be robust against replays *and* would ensure that trivial things and large-scale things could not easily be confused. Et cetera.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]