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

[Perry E. Metzger]

Ian Grigg <iang at systemics.com> writes:
> 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.
> 
> The question is one of costs and benefits - how much
> should we spend to defend against this attack?  How
> much do we save if we do defend?

I have to find I find this argument very odd.

You argue that TLS defends against man in the middle attacks, but that
we do not observe man in the middle attacks, so why do we need the
defense?

Well, we don't observe the attacks much because they are hard to
undertake. Make them easy and I am sure they would happen
frequently. Protocols subject to such attacks are frequently subjected
to them, and there are whole suites of tools you can download to help
you in intercepting traffic to facilitate them.

You argue that we have to make a "cost/benefit analysis", but we're
talking about computer algorithms where the "cost" is miniscule if it
is measurable at all. Why should we use a second-best practice when a
best practice is in reality no more expensive?

It is one thing to argue that a bridge does not need another million
dollars worth of steel, but who can rationally argue that we should
use different, less secure algorithms when there is no obvious
benefit, either in computation, in development costs or in license
fees (since TLS is after all free of any such fees), and the
alternatives are less secure? In such a light, a cost/benefit analysis
leads inexorably to "Use TLS -- second best saves nothing and might
cost a lot in lower security".

Some of your arguments seem to come down to "there wasn't enough
thought given to the threat model." That might have been true when the
SSL/TLS process began, but a bunch of fairly smart people worked on
it, and we've ended up with a pretty solid protocol that is at worst
more secure than you might absolutely need but which covers the threat
model in most of the cases in which it might be used. You've yet to
argue that the threat model is insufficiently secure -- only that it
might be more than one needs -- so what is the harm?

Honestly the only really good argument against TLS I can think of is
that if one wants to use something like SSH keying instead of X.509
keying the detailed protocol doesn't support it very well, but the
protocol can be trivially adapted to do what one wants and the
underlying security model is almost exactly what one wants in a
majority of cases. Such an adaptation might be a fine idea, but it can
be done without giving up any of the fine analysis that went into TLS.

Actually, there is one other argument against TLS -- it does not
protect underlying TCP signaling the way that IPSec does. However,
given where it sits in the stack, you can't fault it for that.

> I think the failure of client certs has the same
> root cause as the failure of SSL/TLS to branch
> beyond its "mandated" role of "protecting e-
> commerce."  Literally, the requirement that
> the cert be supplied (signed) by a third party
> killed it dead.  If there had been a button on
> every browser that said "generate self-signed
> client cert now" then the whole world would be
> using them.

This is not a failure of TLS. This is a failure of the browsers and
web servers. There is no reason browsers couldn't do exactly that,
tomorrow, and that sites couldn't operate on an SSH "accept only what
you saw the first time" model. TLS is fully capable of supporting that.

If you want to argue against X.509, that might be a fine and quite
reasonable argument. I would happily argue against lots of X.509
myself. However, X.509 is not TLS, and TLS's properties are not those
of X.509.

-- 
Perry E. Metzger		perry at piermont.com

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