WYTM?

[Ian Grigg]

Tim Dierks wrote:
> 
> At 12:28 AM 10/13/2003, Ian Grigg wrote:
> >Problem is, it's also wrong.  The end systems
> >are not secure, and the comms in the middle is
> >actually remarkably safe.
> 
> I think this is an interesting, insightful analysis, but I also think it's
> drawing a stronger contrast between the real world and the Internet threat
> model than is warranted.
> 
> It's true that a large number of machines are compromised, but they were
> generally compromised by malicious communications that came over the
> network. If correctly implemented systems had protected these machines from
> untrustworthy Internet data, they wouldn't have been compromised.

The point is, any compromise of any system is more
likely to come from a node compromise than a wire
compromise.

How much more likely?  We don't know for sure, but
I'd say it is in the many thousand times as much.  E.g.,
look at those statistics.  Basically, the wire threat
is unmeasurable - there are no stats that I've ever
seen, and the node compromise is subject of some
great scrutiny, not to mention 13,000 odd Linux
reinstalls every month.

Does it mean that we should ignore the wire threat?
No, but it does mean that we are foolish to let any
protection of the wire threat cause us any grief.

Protecting against any wire attack is fun, but no
more than that - if it costs us a dime, it needs to
be justified, and that is really hard given that we
are thousands of times more likely to see a compromise
on the node.

If we spend 10c protecting against the wire attack,
should we then spend $1,300 spending against the
node attack?

The situation is so ludicrously unbalanced, that if
one really wanted to be serious about this issue,
instead of dismissing certs out of hand (which would
be the engineering approach c.f., SSH), one would
run ADH across the net and wait to see what happened.

Or, spit credit cards in open HTTP, and check how
many were tried by credit card snafflers.  You might
be waiting a long time :-)  But, that would be a
serious way for credit card companies to measure
whether they care one iota about certs or even
crypto at all.

> Similarly, the statement is true at large (many systems are compromised),
> but not necessarily true in the small (I'm fairly confident that my SSL
> endpoints are not compromised). This means that the threat model is valid
> for individuals who take care to make sure that they comply with its
> assumptions, even if it may be less valid for the Internet at large.


If the threat model is valid for individuals who
happen to understand what all this means, then  
by all means they should use the resultant
security model.  I don't think that anyone is
saying that people can't use SSL in its current
recommended form.  JUst that more people would
use SSL if software didn't push them in the
direction of using overly fraught security
levels.


> And it's true that we define the threat model to be as large as the problem
> we know how to solve: we protect against the things we know how to protect
> against, and don't address problems at this level that we don't know how to
> protect against at this level.


(See my first reply to Erik, where I quoted two
sections, earlier today.)

We protect against things which are cost-effective
to protect against.  That is, we use risk analysis
to work out the costs v. the benefits.

We know how to protect against an awful lot.  We
simply don't, unless the cost is less than the
benefit, in general.

And, this is the point:  SSL protected against
the MITM because it could.  Not because it was
present as a threat, and not because it was cost-
effective.  It was infamously and deplorably
weak security logic;  what it should do is
protect against things that are a threat, and
for a cost that matches the threat.


> So, I disagree: I don't think that the SSL model is wrong: it's the right
> model for the component of the full problem it looks to address. And I
> don't think that the Internet threat model has failed to address the
> problem of host compromise: the fact is that these host compromises
> resulted, in part, from the failure of operating systems and other software
> to adequately protect against threats described in the Internet threat
> model: namely, that data coming in over the network cannot be trusted.
> 
> That doesn't change the fact that we should worry about the risk in
> practice that those assumptions of endpoint security will not hold.

It's about relative risks - I'm not saying that
SSL should protect the node.  What I'm saying is
that it is ludicrous to worry overly much the
risk that SSL deals with - the ITM, supposedly -
in most practical environments, because that's
not where the trouble lies.

Another Analogy:  Soldiers don't carry umbrellas
into battle.   But it does rain!

The reasoning is simple - unless the umbrella
is *free* it's ludicrous to worry about water
when someone is shooting bullets at you.

We do a risk-analysis on the umbrella, and we
discover that it has a cost of making us too
conspicuous.  Cost exceed benefit, we ditch    
the umbrella.

iang

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