Re: WYTM - but what if it was true?
If you are insisting that there is always a way and that, therefore, the situation is permanently hopeless such that the smart ones are getting the hell out of the Internet, I can go with that, but then we (you and I) would both be guilty of letting the best be the enemy of the good. A reasonable critique. It is not necessary though that there exists an acceptable solution that keeps PC's with persistent stores secure. A bootable CD from a bank is an unexpectedly compelling option, as are the sort of services we're going to see coming out of all those new net-connected gaming systems coming out soon. --Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM - but what if it was true?
On 06/27/05 00:28, Dan Kaminsky wrote: ... there exists an acceptable solution that keeps PC's with persistent stores secure. A bootable CD from a bank is an unexpectedly compelling option Even more compelling is: -- obtain laptop hardware from a trusted source -- obtain software from a trusted source -- throw the entire laptop into a GSA-approved safe when not being used. This is a widely-used procedure for dealing with classified data. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM - but what if it was true?
On 6/26/05, Dan Kaminsky [EMAIL PROTECTED] wrote: It is not necessary though that there exists an acceptable solution that keeps PC's with persistent stores secure. A bootable CD from a bank is an unexpectedly compelling option, as are the sort of services we're going to see coming out of all those new net-connected gaming systems coming out soon. You just know that people won't want to totally reboot their machines every time they want to bank, because that'll break their excel+quicken+msmoney integrated finances. So they try make a bootable HD partition, or run it under vmware, or copy the trusted client off. These of course cannot be allowed by the banks if they want to preserve the illusion of their secure banking app... And now we have a market for cracked trusted banking clients, both for phishers and lazy people... it's game copy protection wars all over again. :) -- GDB has a 'break' feature; why doesn't it have 'fix' too? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM - but what if it was true?
What do you tell people to do? commercial_message Defense in depth, as always. As an officer at Verdasys, data-offload is something we block by simply installing rules like Only these two trusted applications can initiate outbound HTTP where the word trusted means checksummed and the choice of HTTP represents the most common mechanism for spyware, say, to do the offload of purloined information. Put differently, if there 5,000 diseases but only two symptoms, then symptomatic relief is the more cost-effective approach rather than cure. In this case, why do I care if I have spyware if it can't talk to its distant master? (Why do I care if I have a tumor if angiostatin keeps it forever smaller than 1mm in diameter?) Of course, there are details, and, of course, I am willing to discuss them at far greater length. /commercial_message --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM - but what if it was true?
Dan-- I had something much more complicated, but it comes down to. You trust Internet Explorer. Spyware considers Internet Explorer crunchy, and good with ketchup. Any questions? A little less snarkily, Spyware can trivially use what MS refers to as a Browser Helper Object (BHO) to alter all traffic on any web page. Inserting a 1x1 iframe in the corner of whatever, that does nothing but transmit upstream data via HTTP image GETs, is trivial. And if HTTP is a bit too protected -- there's *always* DNS ;). gethostbyname indeed. --Dan P.S. Imagine for a moment it was profitable to give people cancer. No, not just a pesky side effect, but kind of the idea. Angiostatin wouldn't stand a chance. [EMAIL PROTECTED] wrote: What do you tell people to do? commercial_message Defense in depth, as always. As an officer at Verdasys, data-offload is something we block by simply installing rules like Only these two trusted applications can initiate outbound HTTP where the word trusted means checksummed and the choice of HTTP represents the most common mechanism for spyware, say, to do the offload of purloined information. Put differently, if there 5,000 diseases but only two symptoms, then symptomatic relief is the more cost-effective approach rather than cure. In this case, why do I care if I have spyware if it can't talk to its distant master? (Why do I care if I have a tumor if angiostatin keeps it forever smaller than 1mm in diameter?) Of course, there are details, and, of course, I am willing to discuss them at far greater length. /commercial_message --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM - but what if it was true?
Dan Kaminsky writes: | Dan-- | | I had something much more complicated, but it comes down to. | | You trust Internet Explorer. | Spyware considers Internet Explorer crunchy, and good with ketchup. | Any questions? | | A little less snarkily, Spyware can trivially use what MS refers to | as a Browser Helper Object (BHO) to alter all traffic on any web page. | Inserting a 1x1 iframe in the corner of whatever, that does nothing but | transmit upstream data via HTTP image GETs, is trivial. And if HTTP is | a bit too protected -- there's *always* DNS ;). gethostbyname indeed. | | P.S. Imagine for a moment it was profitable to give people cancer. No, | not just a pesky side effect, but kind of the idea. Angiostatin | wouldn't stand a chance. | If you are insisting that there is always a way and that, therefore, the situation is permanently hopeless such that the smart ones are getting the hell out of the Internet, I can go with that, but then we (you and I) would both be guilty of letting the best be the enemy of the good. commercial However, I/we routinely disable all use of BHOs, prevent mod of any entity as chosen by filename extension, checksum, or filesystem location, and whitelist applications, to name a _few_. For the genuinely paranoid, regular (like every few hours) reboot to a new VM is also enforceable and recommended, especially if you care about attacks that are purely in-memory and which do not leave behind any payload such as to aid an attacker on his/her proposed second visit. If you indeed are an I don't need no stinkin' payload sort of guy, like the folks who eschew carrying matches because you can always light a fire rubbing two sticks together, make me a suggestion; I love free consulting. /commercial --dan = Internet Explorer is the most dangerous program ever written. -- Rik Farrow to Scott Charney during the audience grilling stage of http://www.usenix.org/events/usenix04/tech/sigs.html#mono_debate - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM - but what if it was true?
Allan Liska wrote: 3. Use an on-screen keyboard. For extra points, try Dasher. http://www.inference.phy.cam.ac.uk/dasher/ -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
On Tue, 21 Oct 2003 15:02:14 +1300, Peter Gutmann said: Are there any known servers online that offer X.509 (or PGP) mechanisms in their handshake? Both ssh.com and VanDyke are commercial offerings so it's not possible to look at the source code to see what they do, and I'm not sure Joel N. Weber II developed PGP patches for OpenSSH: http://www.red-bean.com/~nemo/openssh-gpg/ and I am pretty sure that he has a server up somewhere. Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
Thor Lancelot Simon [EMAIL PROTECTED] writes: I believe the VanDyke implementation also supports X.509, and interoperates with the ssh.com code. It was also my perception that, at the time, the VanDyke guy was basically shouted down when trying to discuss the utility of X.509 for this purpose and put his marbles back in his cloth sack and went home. Are there any known servers online that offer X.509 (or PGP) mechanisms in their handshake? Both ssh.com and VanDyke are commercial offerings so it's not possible to look at the source code to see what they do, and I'm not sure that I want to run the gauntlet of getting some sample copy of a commercial app (if they're available) and figuring out how to set it up to work with certs just to see what the data format is supposed to be... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
On Sun, 2003-10-19 at 00:47, Peter Gutmann wrote: What was the motive for adding lip service into the document? So that it's possible to claim PGP and X.509 support if anyone's interested in it. It's (I guess) something driven mostly by marketing so you can answer Yes to any question of Do you support x. You can find quite a number of these things present in various security specs, it's not just an SSH thing. I think that you are misrepresenting the problem a little. At least one vendor (ssh.com) has a product that supports both X.509 and PGP, so the inclusion of these in the I-D is not just marketing overriding reality - just a lack of will on part of the the draft's authors. I have seen little involvement on the secsh wg mailing list by the ssh.com people since the public spat about trademark rights over ssh a few years back. Since noone else implements these two public key methods, the work has never been done. IIRC The wg decided to punt the issue to a separate draft if it ever arose again. It hasn't in two years. In the meantime, everyone involved seems to have become deathly afraid of touching the draft so as not to impede its glacial progress through the IETF on its way to RFC-hood. Whether a sizeable number of customers acutally use certificates for ssh is another matter. IMO The only real use for certs in ssh is the issue of initial server authentication. If one wants to use certificates to facilitate this process, they can already - just publish the server keys on a https server somewhere and/or sign them with PGP :) -d - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
Damien Miller [EMAIL PROTECTED] writes: The SSH protocol supports certificates (X.509 and OpenPGP), though most implementations don't. One of the reason why many implementations may not support it is that the spec is completely ambiguous as to the data formats being used. For example it specifies the signature blob format as an X.509 signature, which could be about half a dozen different things. Same with PGP signatures, for which there's even more possibilities. In addition since almost nothing implements them, it's not possible to get test data from someone else's server to see what they're doing (hmm, and even if there was there's no way to tell whether their interpretation would match someone else's). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
On 10/16/2003 07:19 PM, David Honig wrote: it would make sense for the original vendor website (eg Palm) to have signed the MITM site's cert (palmorder.modusmedia.com), not for Verisign to do so. Even better, for Mastercard to have signed both Palm and palmorder.modusmedia.com as well. And Mastercard to have printed its key's signature in my monthly paper bill. Bravo. Those are golden words. Let me add my few coppers: 1) This makes contact with a previous thread wherein the point was made that people often unwisely talk about identities when they should be talking about credentials aka capabilities. I really don't care about the identity of the order-taking agent (e.g. palmorder.modusmedia.com). What I want to do is establish the *credentials* of this *session*. I want a session with the certified capability to bind palm.com to a contract, and the certified capability to handle my credit-card details properly. 2) We see that threat models (as mentioned in the Subject: line of this thread), while an absolutely vital part of the story, are not the whole story. One always needs a push-pull approach, documenting the good things that are supposed to happen *and* the bad things that are supposed to not happen (i.e. threats). 3) To the extent that SSL focuses on IDs rather than capabilities, IMHO the underlying model has room for improvement. 4a) This raises some user-interface issues. The typical user is not a world-class cryptographer and may not have a clear idea just what ensemble of credentials a given session ought to have. This is not a criticism of credentials; the user doesn't know what ID the session ought to have under the current system, as illustrated by the Palm example. The point is that if we want something better than what we have now, we have a lot of work to do. 4b) As a half-baked thought: One informal intuitive notion that users have is that if a session displays the MasterCard *logo* it must be authorized by MasterCard. This notion is enforceable by law in the long run. Can we make it enforceable cryptographically in real time? Perhaps the CAs should pay attention not so much to signing domain names (with some supposed responsibility to refrain from signing abusively misspelled names e.g. pa1m.com) but rather more to signing logos (with some responsibility to not sign bogus ones). Then the browser (or other user interface) should to verify -- automatically -- that a session that wishes to display certain logos can prove that it is authorized to do so. If the logos check out, they should be displayed in some distinctive way so that a cheap facsimile of a logo won't be mistaken for a cryptologically verified logo. Even if you don't like my half-baked proposal (4b) I hope we can all agree that the current ID-based system has room for improvement. = Tangentially-related point about credentials: In a previous thread the point was made that anonymous or pseudonymous credentials can only say positive things. That is, I cannot discredit you by giving you a discredential. You'll just throw it away. If I somehow discredit your pseudonym, you'll just choose another and start over. This problem can be alleviated to some extent if you can post a fiduciary bond. Then if you do something bad, I can demand compensation from the agency that issued your bond. If this happens a lot, they may revoke your bond. That is, you can be discredited by losing a credential. This means I can do business with you without knowing your name or how to find you. I just need to trust the agency that issued your bond. The agency presumably needs to know a lot about you, but I don't. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
On Fri, 2003-10-17 at 00:58, John S. Denker wrote: Tangentially-related point about credentials: In a previous thread the point was made that anonymous or pseudonymous credentials can only say positive things. That is, I cannot discredit you by giving you a discredential. You'll just throw it away. If I somehow discredit your pseudonym, you'll just choose another and start over. This problem can be alleviated to some extent if you can post a fiduciary bond. Then if you do something bad, I can demand compensation from the agency that issued your bond. If this happens a lot, they may revoke your bond. That is, you can be discredited by losing a credential. This means I can do business with you without knowing your name or how to find you. I just need to trust the agency that issued your bond. The agency presumably needs to know a lot about you, but I don't. One can claim this is what a credit card does for the consumer the name on the card is somewhat tangential to it being a credential; it is there so that the merchant can authenticate the credential by cross checking the name on the card with names on other credentials that you might be carrying. If you have enuf credentials with the same name ... then it eventually satisfies the merchant that it is your credential. Some number of places are taking the name off the card as part of improving consumer privacy at point-of-sale. They can do this with debit where the PIN is a substitution for otherwise proving it is your credential. however, as previously posted there is a lot of skimming going an with the information for making a counterfeit card as well as skarfing up the corresponding PIN is being done. This is also being done with some kinds of chip cards where a PIN is involved but since the infrastructure trusts the cards the counterfeit cards are programmed to accept any PIN see the yes card at the bottom of the following URL. http://www.smartcard.co.uk/resources/articles/cartes2002.html The issue is that technique used to skim static data for making counterfeit magstripe cards also applies to skimming static data for making counterfeit yes cards. The claim in X9.59 is that the signature from something like an asuretee card ... can both demonstrate two (or three) factor authentication as well as proving that the transaction hasn't been tampered with since it was signed. In this case, while the card may still look like an (offline) credential from pre-1970s (with printed credential revokation lists mailled out every month to all merchants) it, in fact does an online transaction. The digital signature proving 2/3 factor authenticaiton (and no transaction tampering during transit) is then accepted (or not) by the financial institution which reports back real-time result to the relying party (merchant). This is a move from the ancient offline paradigm that has been going on for hundreds of years (with credentials as substitute for real-time interaction) to an online paradigm. While the form-factor may still appear the same as the rapidly becoming obsolete offline credential; it is actually operating as a long-distance 2/3 factor authentication mechanism between the consumer and their financial institution with the merchant/relying-party getting back a real-time response as to whether the institution stands behind the request. The difference between the x9.59/asuretee implementation and the yes card implementation is that there is no static data to skim (and use for creating counterfeit cards/transactions). misc. x9.59 refs: http://www.garlic.com/~lynn/index.html#x959 misc. aads chip strawman asuretee refs: http://www.garlic.com/~lynn/index.html#aads The integrity of the chipcard and the integrity of the digital signature substitutes for requiring the merchants to cross-check the name on the card with the names on an arbitrary number of other credentials until they are comfortable performing the transaction. The current (non-PIN card) infrastructure is sort of half way between the old style everything is a credential and the new everything is online to a fully trusted online infrastructure. The magstripe does an online transaction and the institution will approve the transactions with some number of caveats regarding it not being a counterfeit/fraudulent transaction. For the non-PIN transactions, the merchant (can) uses the name on the card to cross check with as many other credential names until the merchant becomes comfortable. This is similar to the scenario with the existing SSL domain name certificate issuing process (using names mapping to common/real-world identities in order to achieve authentication). The domain name system registers the owner's name. The CA SSL certificate issuer obtains a name of the certificate requester and then the CA attempts to map the two names into the same real world identities as a means of achieving authentication. The
Re: WYTM?
Jon Snader wrote: On Mon, Oct 13, 2003 at 06:49:30PM -0400, Ian Grigg wrote: Yet others say to be sure we are talking to the merchant. Sorry, that's not a good answer either because in my email box today there are about 10 different attacks on the secure sites that I care about. And mostly, they don't care about ... certs. But they care enough to keep doing it. Why is that? I don't understand this. Let's suppose, for the sake of argument, that MitM is impossible. It's still trivially easy to make a fake site and harvest sensitive information. Yes. This is the attack that is going on. This is today's threat. (In that it is a new threat. The old threat still exists - hack the node.) If we assume (perhaps erroneously) that all but the most naive user will check that they are talking to a ``secure site'' before they type in that credit card number, doesn't the cert provide assurance that you're talking to whom you think you are? Nope. It would seem that only the more sophisticated users can be relied upon to correctly check that they are at the correct secure site. In practice almost all of these attacks bypass any cert altogether and do not use an SSL protected HTTPS site. They use a variety of techniques to distract the attention of the user, some highly imaginative. For example, if you target the right browser, then it is possible to popup a box that covers the appropriate parts. Or to put a display inside the window that duplicates the browser display. Or the URL is one of those with strange features in there or funny letters that look like something else. In practice, these attacks are all statistical, they look close enough, and the fool some of the people some of the time. Finally, just in the last month, they have also started doing actual cert spoofs. This was quite exciting to me to see a spoof site using a cert, so I went in and followed it. Hey presto, it showed me the cert, as it said it was wrong! So I clicked on the links and tried to see what was wrong. Here's the interesting thing: I couldn't easily tell, and my first diagnosis was wrong. So then I realised that *even* if the spoof is using a cert, the victim falls to a confusion attack (see Tom Weinstein's comments on bad GUIs). (But, for the most part, 95% or so ignore the cert, and the user may or may not notice.) Now, we have no statistics on how many of these attacks work, other than the following: they keep happening, and with increasing frequency over time. From this I conclude they are working, enough to justify the cost of the attack at least. I guess the best thing to say is that the raw claim that the cert ensures that you are talking to the merchant is not 100% true. It will help a sophisticated user. An attack will bypass some of the users a lot. It might fool many of the users only occasionally. If the argument is that Verisign and the others don't do enough checking before issuing the cert, I don't see how that somehow means that SSL is flawed. SSL isn't flawed, per se. It's just not appropriately being used in the secure browser application. It's fair to say that its use is misaligned to requirements, and a lot of things could be done to improve matters. But, one of the perceptions that exist in the browser world is that SSL secures ecommerce. Until that view is rectified, we can't really build the consensus to have efforts like Ye Smith, and Close, and others, be treated as serious and desirable. (In practice, I don't think it matters how Verisign and others check the cert. This is shown by the fact that almost all of these attacks have bypassed the cert altogether.) iang http://www.iang.org/ssl/maginot_web.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
Hopefully everyone realizes this, but just for the record, I didn't write the lines apparently attributed to me below -- I was quoting Bruce Schneier. By the way, I strongly agree with David Honig's point that the wrong entities are doing the signing. Regards, Bryce O'Whielacronx David Honig [EMAIL PROTECTED] wrote: At 01:51 PM 10/16/03 -0400, Bryce O'Whielacronx wrote: I doubt it. It's true that VeriSign has certified this man-in-the-middle attack, but no one cares. Indeed, it would make sense for the original vendor website (eg Palm) to have signed the MITM site's cert (palmorder.modusmedia.com), not for Verisign to do so. Even better, for Mastercard to have signed both Palm and palmorder.modusmedia.com as well. And Mastercard to have printed its key's signature in my monthly paper bill. (This is aside your main point about it being Mastercard et al. doing the checking/backup for the customer, not certs.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
Eric Rescorla wrote: Ian Grigg [EMAIL PROTECTED] writes: I'm sorry, but, yes, I do find great difficulty in not dismissing it. Indeed being other than dismissive about it! Cryptography is a special product, it may appear to be working, but that isn't really good enough. Coincidence would lead us to believe that clear text or ROT13 were good enough, in the absence of any attackers. For this reason, we have a process. If the process is not followed, then coincidence doesn't help to save our bacon. Disagree. Once again, SSL meets the consensus threat model. It was designed that way partly unconsciously, partly due to inertia, and partly due to bullying by people who did have the consensus threat model in mind. (If you mean that the ITM is consenus, I grant you that two less successful protocols follow it - S/MIME and IPSec (partly) but I don't think that makes it consensus. I know there are a lot of people who don't think in any other terms than this model, and that is the issue! There are also a lot of people who think in terms completely opposed to ITM. So to say that ITM is consensus is something that is going to have to be established. If that's not what you mean, can you please define?) That's not the design process I would have liked, but it's silly to say that a protocol that matches the threat model is somehow automatically the wrong thing just because the designers weren't as conscious as one would have liked. I'm not sure I ever said that the protocol doesn't match the threat model - did I? What I should have said and hoped to say was that the protocol doesn't match the application. I don't think I said automatically, either. I did hold out hope in that rant of mine that the designers could have accidentally got it right. But, they didn't. Now, SSL, by itself, within the bounds of the ITM is actually probably pretty good. By all reports, if you want ITM, then SSL is your best choice. But, we have to be very careful to understand that any protocol has a given set of characteristics, and its applicability to an application is an uncertain thing; hence the process of the threat model and the security model. In SSL's case, one needs to say use SSL, but only if your threat model is close to ITM. Or similar. Hence the title of this rant. The error of the past has been that too many people have said something like Use SSL, because we already got it right. Which, unfortunately, skips the whole issue of what threat model one is dealing with. Just like happened with secure browsing. In this case, the ITM was a) agreed upon after the fact to fill in the hole, and b) not the right one for the application. And on the client side the user can, of course, click ok to the do you want to accept this cert dialog. Really, Ian, I don't understand what it is you want to do. Is all you're asking for to have that dialog worded differently? There should be no dialogue at all. Going from HTTP to HTTPS/self signed is a mammoth increase in security. Why does the browser say it is less/not secure? Because it's giving you a chance to accept the certificate, and letting you know in case you expected a real cert that you're not getting one. My interpretation - which you won't like - is that it is telling me that this certificate is bad, and asking whether me if I am sure I want to do this. A popup is symonymous with bad news. It shouldn't be used for good news. As a general theme, that is, although this is the reason I cited that paper: others have done work on this and they are a long way ahead in their thinking, far beyond me. It's not THAT different from what SSH pops up. (Actually, I'm not sure what SSH pops up, it's never popped up anything to me? Are you talking about a windows version?) SSH in terminal mode says: The authenticity of host 'hacker.stanford.edu (171.64.78.90)' can't be established. RSA key fingerprint is d3:a8:90:6a:e8:ef:fa:43:18:47:4c:02:ab:06:04:7f. Are you sure you want to continue connecting (yes/no)? I actually find the Firebird popup vastly more understandable and helpful. I'm not sure I can make much of your point, as I've never heard of nor seen a Firebird? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
Minor errata: Eric Rescorla wrote: I totally agree that the systems are insecure (obligatory pitch for my Internet is Too Secure Already) http://www.rtfm.com/TooSecure.pdf, I found this link had moved to here; http://www.rtfm.com/TooSecure-usenix.pdf which makes some of the same points you're making, though not all. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
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. 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. 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. This is no more incorrect than my buying clothes which will protect me from rain, but failing to consider shopping for clothes which will do a good job of protecting me from a nuclear blast: we don't know how to make such clothes, so we don't bother thinking about that risk in that environment. Similarly, we have no idea how to design a networking protocol to protect us from the endpoints having already been compromised, so we don't worry about that part of the problem in that space. Perhaps we worry about it in another space (firewalls, better OS coding, TCPA, passing laws). 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. - Tim - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
Eric, thanks for your reply! My point is strictly limited to something approximating there was no threat model for SSL / secure browsing. And, as you say, you don't really disagree with that 100% :-) With that in mind, I think we agree on this: [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. Actually, I was there, though I was an outsider to the process. Netscape was doing the design and not taking much input. However, they did send copies to a few people and one of them was my colleague Allan Schiffman, so I saw it. OK! It's really a mistake to think of SSL as being designed with an explicit threat model. That just wasn't how the designers at Netscape thought, as far as I can tell. Well, that's the sort of confirmation I'm looking for. From the documents and everything, it seems as though the threat model wasn't analysed, it was just picked out of a book somewhere. Or, as you say, even that is too kind, they simply didn't think that way. But, this is a very important point. It means that when we talk about secure browsing, it is wrong to defend it on the basis of the threat model. There was no threat model. What we have is an accident of the past. Which is great. This means there is no real objection to building a real threat model. One more appropriate to the times, the people, the applications, the needs. And the today-threats. Not the bogeyman threats. Incidentally, Ian, I'd like to propose a counterargument to your argument. It's true that most web traffic could be encrypted if we had a more opportunistic key exchange system. But if there isn't any substantial sniffing (i.e. the wire is secure) then who cares? Exactly. Why do I care? Why do you care? It is mantra in the SSL community and in the browsing world that we do care. That's why the software is arranged in a a double lock- in, between the server and the browser, to force use of a CA cert. So, if we don't care, why do we care? What is the reason for doing this? Why are we paying to use free software? What paycheck does Ben draw from all our money being spent on this i don't care thing called a cert? Some people say because of the threat model. And that's what this thread is about: we agree that there is no threat model, in any proper sense. So this is a null and void answer. Other people say to protect against MITM. But, as we've discussed at length, there is little or no real or measurable threat of MITM. Yet others say to be sure we are talking to the merchant. Sorry, that's not a good answer either because in my email box today there are about 10 different attacks on the secure sites that I care about. And mostly, they don't care about ... certs. But they care enough to keep doing it. Why is that? Someone made a judgement call, 9 or so years ago, and we're still paying for that person caring on our behalf, erroneously. Let's not care anymore. Let's stop paying. I don't care who it was, even. I just want to stop paying for his person, caring for me. Let's start making our own security choices? Let crypto run free! iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
