SSL, client certs, and MITM (was WYTM?)

[John S. Denker]

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 majordomo at metzdowd.com