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