From: Ian Grigg <iang@systemics.com>
To: cryptography@metzdowd.com
Subject: WYTM?
Date: Mon, 13 Oct 2003 00:28:07 -0400 (EDT)
As many have decried in recent threads, it all
comes down the WYTM - What's Your Threat Model.
It's hard to come up with anything more important
in crypto. It's the starting point for ... every-
thing. This seems increasingly evident because we
haven't successfully reverse-engineered the threat
model for the Quantum crypto stuff, for the Linux
VPN game, and for Tom's q&d channel security.
Which results in, at best, a sinking feeling, or
at worst, endless arguments as to whether we are
dealing with yet another a hype cycle, yet another
practically worthless crypto protocol, yet another
newbie leading users on to disaster through belief
in simple, hidden, insecure factors, or...
WYTM?
It's the first question, and I've thought it about
a lot in the context of SSL. This rant is about
what I've found. Please excuse the weak cross over!
For $40, you can pick up "SSL & TLS" by Eric
Rescorla [1]. It's is about as close as I could
get to finding serious commentary on the threat
model for SSL [2].
The threat model is in Section 1.2, and the reader
might like to run through that, in the flesh, here:
http://www.iang.org/ssl/rescorla_1.html
perhaps for the benefit of at least one unbiased
reading. Please, read it. I typed it in by hand,
and my fingers want to know it was worth it [3].
The rest of this rant is about what the Threat
model says, in totally biased, opinionated terms
[4]. My commentary rails on the left, the book
composes centermost.
1.2 The Internet Threat Model
Designers of Internet security protocols
typically share a more or less common
threat model.
Eric doesn't say so explicitly, but this is pretty
much the SSL threat model. Here comes the first
key point:
First, it's assumed that the actual end
systems that the protocol is being
executed on are secure....
(And then some testing of that claim. To round
this out, let's skip to the next paragraph:)
... we assume that the attacker has more or
less complete control of the communications
channel between any two machines.
Ladies and Gentlemen, there you have it. The
Internet Threat Model (ITM), in a nutshell, or,
two nutshells, if we are using those earlier two
sentance models.
It's a strong model: the end nodes are secure and
the middle is not. It's clean, it's simple, and
we just happen to have a solution for it.
Problem is, it's also wrong. The end systems
are not secure, and the comms in the middle is
actually remarkably safe.
(Whoa! Did he say that?) Yep, I surely did: the
systems are insecure, and, the wire is safe.
Let's quantify that: Windows. Is most of the
end systems (and we don't need to belabour that
point). Are infected with viruses, hacks, macros,
configuration tools, passwords, Norton recovery
tools, my kid sister...
And then there's Linux. 13,000 boxen hacked per
month... [5]. In fact, Linux beats Windows 4 to 1
and it hasn't even challenged the user's desktop
market yet!
It shows in the statistics, it shows in experience;
pretty much all of us have seen a cracked box at
close quarters at one point or another [6].
Windows systems are perverted in their millions by
worms, viruses, and other upgrades to the social
networking infrastructure. Linux systems aren't
much more trust-inspiring, on the face of it.
Pretty much all of us present in this forum would
feel fairly confident about downloading some sort
of crack disc, walking into a public library and
taking over one of their machines.
Mind you... in that same library, could we walk
in and start listening to each other's comms?
Nope. Probably not.
On the one hand, we'd have trouble on the cables,
without being spotted by that pesky librarian.
And those darn $100 switches, they so ruin the
party these days.
Admittedly, OTOH, we do have that wonderful 802.11b
stuff and there we can really listen in [7].
But, in practice, we can conclude, nobody much
listens to our traffic. Really, so close to nobody
that nobody in reality worries about it [8].
But, every sumbitch is trying to hack into our
machine, everyone has a virus scanner, a firewall,
etc etc. I'm sure we've all shared that wierd
feeling when we install a new firewall that
notifies when your machine is being port scanned?
A new machine can be put on a totally new IP, and
almost immediately, ports are being scanned....
How do they do that so fast?
Hence the point: the comms is pretty darn safe.
And the node is in trouble. We might have trouble
measuring it, but we can assert this fact:
the node is way more insecure than the comms.
That's a good enough assumption for now; which
takes us back to the so-called "Internet Threat
Model" and by extension and assumption, the SSL
threat model:
"the actual end systems ... are secure.
.... the attacker has more or less complete
control of the communications channel between
any two machines."
Quite the reverse pertains [5]. So where does that
leave us with SSL?
I am going to assume, for now, that the Internet
Threat Model (ITM, (R)TM, YATLA) is the SSL threat
model. And that both are described fairly in the
book.
And, it's wrong. There are, then, given these
stated assumptions, three questions:
1. why was it chosen?
2. what effect did it have on the protocol?
3. what's the deal with repairing it?
Let's go back to the book and see if we can't work
it out [9].
Here's a designed-in limitation in Part One (the
end systems are secure):
Protecting against attacks where
one of the end systems is under
the control of the attacker is
extraordinarily difficult, if not
impossible.
Here's the acceptance of the all-powerful comms
channel attacker:
Other than that, we assume that the
attacker has more or less complete
control of the communications
channel between any two machines
with no limitations on the threat level of the
attacker.
Now check this caveat in part two (the comms is
totally open):
protocol designers don't worry about
_denial-of-service_ attacks not
because these attacks aren't
important but because they're
extraordinarily difficult to prevent.
What does all this say? Well, in a nutshell,
we won't protect against the end system attack,
because its really difficult. And we'll ignore
DOS because that's too difficult too.
But we'll cover the entire on-the-wire threats
... because, as the book goes on to show, we can!
And that's the clanger - the threat model is
about what we can protect. It is not a
statement of what is needed for the application.
Rather, the whole SSL threat model is a statement,
lifted out of some book from some academic's
library, of what we know, in theory, about how
to create a channel protocol!
Whether the perfect channel protocol is useful or
relevant or applicable was never at issue. This
means the threat model isn't the threat model it
should be.
A threat model looks at the application - at what
we are trying to protect. In this case, we know
that the actual threat that SSL was built for was
the sniffer of credit card numbers. But, he, the
sniffer, is not considered, what's replaced his
role is some theoretical bogey man. The bogey
man can do anything that we know how to protect
against, and not the things we can't protect
against.
This is pretty damning. What it means is that,
in essence, the threat model analysis wasn't
carried out. Properly, at least, or at all,
at the most.
SSL was put together as a "perfect" protocol to
solve a "convenient" threat model from the
(admittedly persuasive and pervasive) knowledge
of the times. And, it took little or no account
of the needs of the application.
And now, it should be clear to us why SSL looks
so damn odd in the secure browsing application -
because it was, as a result of its unhappy
parentage, an unexpected child that wasn't
created to plan.
That's why, for example, the protocol finishes its
security job close to the borders of the comms.
That's why CA-signed certs were chosen, because
they solved something that could be solved, with
no particular analysis as to whether anyone would
bother to attack that weak link. That's why, for
example, it's a channel security product, and not
a page (credit card number) protection product.
And, for example, the digsig creates a chain
instead of affirming an intent.
It was only assumed, guessed at, indeed, hoped for
that this protocol was the best way to secure the
credit card in a browsing application. Here's the
assumption that confirms the failure:
Designers of Internet security
protocols typically share a more
or less common threat model.
It's para three, section 1.2. And, it is of course,
famously not true [10].
SSH is the most outstanding example of not sharing
that threat model [11]. In fact, it's fair to say
that most Internet security protocols do not share
that threat model, unless they happen to have
followed in SSL's footsteps and also forgotten to
do their threat model analysis.
Which is not to say that the threat model is
inappropriate in the circumstances. And, there
is still some room to consider that fortune
might have favoured the brave.
But, it is murky enough that we can rip the
pretense aside: SSL borrowed someone else's
threat model, and it happened to have at least
two highly challengeable assumptions in it,
both of which led to a strong design feature
we are now finding is detrimental.
These two assumptions - node is secure and comms
are insecure - led to the very strong emphasis on
MITM protection, which is the root cause of the
failure of availability of secure browsing to the
Internet public [12].
What do we do about it? Firstly, we should
recognise that the threat model is wrong. Broken,
in the crypto parlance. No, not just broken, but
irrelevant. We know that the active attack is
not a serious threat, and is in any event way
less important than the threat to the machine
itself.
Secondly, and thusly, this clears the way to de-
emphasise protection against active attacks. We
can in most cases safely propose opportunistic
cryptography from self-signed certs, cached or
otherwise, from other methods of fingerprint
distribution, or even from anonymous Diffie-Hellman.
For example, for starters.
That doesn't mean ripping out the CA-signed certs,
but just making them honestly optional. Any server
that wishes to use them can and should.
But servers and browsers that have no need, shouldn't
need to.
Thirdly, it remains that secure browsing, isn't [13].
We need to recognise that the pervasive myth that
SSL secures the browing process is holding back a
rethink on how to do it better.
And that has to come from the crypto community;
that's where the myth was created and that's where
the debunking has to come from.
Or, at least, it's better if the crypto community
repairs its own myths, rather than the Internet
community debunking it, and the credibility of the
crypto community along with it.
iang
[1] http://www.amazon.com/exec/obidos/ASIN/0201615983/cryptix/104-8224124-8532711
is the link you want :-) Rescorla's book is becoming
the must-have guide for SSL & TLS, a point I rely upon
overly much.
[2] The spec for TLS doesn't really mention threats.
The scattering of papers on the topic seem to gloss
over it as well. So the book is both well needed
and somewhat belated, this late in the SSL cycle.
[3] It's also on the amazon link above. I wish I'd
known...
[4] Oh, yea of little faith!
[5] "During August, 67 per cent of all
successful and verifiable digital
attacks against on-line servers
targeted Linux, followed by Microsoft
Windows at 23.2 per cent. A total of
12,892 Linux on-line servers running
e-business and information sites were
successfully breached in that month,
followed by 4,626 Windows servers."
http://www.globetechnology.com/servlet/story/RTGAM.20030911.gtlinuxsep11/BNStory/Technology/
[6] I like BSD more and more.
[7] Note to self. Must download a WEP crack kit!
I'm sure someone around here has a WEP network to
break into ...
Quick reality check: yes, WEP is broken, but
no, it isn't useless: who is going to go to the
library and crack the crypto? Not me. Fact of
the matter here is that for the vast majority
of uses, WEP may very well be "good enough" ...
not great or a protocol to be proud of, but it's
good enough for ordinary net use.
[8] Yeah, I know. "At a conference, I saw..."
No, this rant is not about *us* people, it's about
security for *everyone*. That includes, especially,
everyman aggressive attacker, however he does it.
[9] I'd love to hear the inside scoop, but all I
have is Eric's book. Oh, and for the record,
Eric wasn't anywhere near this game when it was
all being cast out in concrete. He's just the
historian on this one. Or, that's the way I
understand it.
[10] There are others - PGP, Kerberos, Paypal,
and my own company's SOX spring to mind.
[11] In a recent presentation to Usenix, the author
admits that the "Internet Threat Model" is "not
really true."
http://www.rtf.com/TooSecure-usenix.pdf slide 5.
[12] http://www.iang.org/ssl/how_effective.html
argues that only 1% of servers make SSL available
to their customers.
[13] http://www.iang.org/ssl/spoof4.html Recall
here, onslaught of spoofing, etc. Also, serious
high-level business types might like to look at this:
http://www.glenbrook.com/opinions/financial-privacy.html
That is **mainstream** writings on how insecure
the browsing scenario is. The point is - it's
about to become a major hot potatoe. At some point
the mud will sling.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com