Re: Failure of PKI in messaging
The solution is simpler than it seems. Let's first look at one scenario that is already working and use it as an example to show how the email scenario may work. Banks are already, and securely, sending and receiving online messages to/from their clients. This is done by a web interface, after the user logs in to their account. Web user login can be based on a number of two-factor and mutualauthentication solutions, some of them quite ineffective to prevent phishing but, nonetheless, better than what the email PKI model provides. What's missing with the email PKI model? While the bank is asking to be authenticated by the user, it does so by asking the user to rely on a number of third-party references that are actually unreliable (ie, by being without recourse, warrantless, unverifiable, and chosen by the purported sender in what may be a con game). The bank would never allow the user to be authenticated under the same assumptions! So, what's missing in the email PKI model is two-sidedness. Fairness. It is essential to have a reference point that the user trusts. In the web messaging example already used by banks, this is provided by the user login -- the user trusts that that is their account -- their name is correct, their balance and transactions are correct. I am using this insight in a secure email solution that provides just that -- a reference point that the user trusts, both sending and receiving email. Without such reference point, the user can easily fall prey to con games. Trust begins as "self-trust". Anyone interested in trying it out, please send me a personal email with application info. Best, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Failure of PKI in messaging
Ian G wrote: > Actually, there are many problems. If you ask the low-level crypto > guys, they say that the HI is the problem. If you ask the HI guys, they > say that the PKI concept is the problem. If you ask the PKI people, > they say the users are not playing the game, and if you ask the users > they say the deployment is broken ... Everyone has got someone else to > blame. This is, in my experience, exactly right. I'm trying to take some steps for the better on the OLPC: all e-mails and IMs will be signed transparently and by default, with the possibility of being encrypted by default in countries where it's not a problem. This'll help with privacy and message integrity, but it's not designed to stop phishing or impersonation. Phishing is less of an immediate problem for us, as there's little incentive to phish 6-year olds in developing countries. But it will be a problem eventually, and by then, it might be extremely difficult to introduce sweeping changes in the security and HCI model to remedy the problem. One tremendous advantage we have now with OLPC is the ability to ignore backwards compatibility for a number of things, so if we had a really good model for dealing with phishing and the like -- even if it required new assumptions or approaches -- we could probably do it. So maybe it's time (for us, perhaps) to organize a workshop on this? Is there a better way to do it? -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Failure of PKI in messaging ... addenda
re: http://www.garlic.com/~lynn/aadsm26.htm#32 Failure of PKI in messaging another way of looking at the issue is somewhat alluded to in this blog post http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minium liability, the CA trap, the market in browswer governance somewhat contrasting SSL domain name certificate with association branded payment instruments. the association logos also promote a feeling of comfort for people doing transactions ... but they have quite a bit of regulatory and policy standing behind those transactions for the benefit of the consumer ... something that you don't find in any of the ssl domain name certificate operations. at least in some of the PKI publicity and hype ... the concept was conveyed that a relying party could base trust purely on a digital certificate ... that the existence of a digital certificate provided all the trust that anybody would ever need. however, there is a big gap in the level of recourse provided to a consumer using an association branded payment mechanism ... and the recourse provided to a consumer (relying party) by the existence of a digital certificate. i would contend that basic fundamental asymmetric cryptography defined business process that allowed an individual to somewhat equate digitally signed electronic communication nearly equivalent to having face-to-face communication with an individual; aka it provided for authentication and integrity. there was no sense of "trust" ... the concept of trust was something that was associated with an individual or entity ... digitally signature somewhat put electronic communication on level playing field with face-to-face communication ... allowing it to be associated with a specific individual or entity. The issue of "trust" was separate from being able to depend on that equivalence. this starts out purely as certificateless operation http://www.garlic.com/~lynn/subpubkey.html#certless or this email from 1981 discussing using public key for secure communication http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network various PKI related publicity and hype from the 90s basically attempted to equate digital certificates (added to an underlying public key operation) would actually provide the basis for "trust" between two parties that had no previous interaction (aka this is the letters of credit/introduction from the sailing ship days scenario). part of the issue was that there was frequently nothing that actually provided recourse to the parties in the event that something didn't go quite as expected (which is present in the association branded payment mechanisms). such publicity/hype may also account for any confusion that ssl domain name certification ... while only the basis for the owner of a domain name is likely also the operator of a webserver (addressed by that domain name) ... rather than actually the basis for a webserver that a person thinks they are talking to is actually the webserver they are talking to. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Failure of PKI in messaging
Ian G wrote: Actually, there are many problems. If you ask the low-level crypto guys, they say that the HI is the problem. If you ask the HI guys, they say that the PKI concept is the problem. If you ask the PKI people, they say the users are not playing the game, and if you ask the users they say the deployment is broken ... Everyone has got someone else to blame. They are all right, in some sense. The PKI concepts need loosening up, emails should be digsig'd for authentication (**), and the HI should start to look at what those digsigs could be used for. But, until someone breaks the deadly embrace, nothing is going to happen. That's what James is alluding to: what part can we fix, and will it help the others to move? iang ** I didn't say digital signing ... that's another problem that needs fixing before it is safe to use, from the "ask the lawyers" basket. looking at the ssl domain name certificate uptake scenario ... there was a combination of things ... lots of publicity so that consumers perceived it providing some benefit, merchants perceiving that the consumers would feel better about it ... and therefor (for merchants) that it was worthwhile to shell out the money ... and lots of financial interests providing for publicity and support to have it ubiquitously deployed (to encourage merchants to shell out the money). lots of past posts mentioning the whole ssl domain name certificate scenario http://www.garlic.com/~lynn/subpubkey.html#sslcert part of the problem was that the PKI financial model is out of kilter with standard business practices. nominally a relying party has some sort of relationship with the certification authority (i.e. what they are relying on) and there is exchange of value between the two parties. In the standard PKI model, there frequently is absolutely no relationship between the relying party and the certifying agency. The "owner" of the digital certificate is paying the certifying agency ... not the relying party ... so there is typically no exchange of value between the certifying agency and the relying party ... and therefor the relying party has no foundation for actually relying on the certifying agency. In early 90s ... there was some attempt to sidestep the lack of business foundation for PKI ... by defining X.509 identity certificates, frequently grossly overloaded with personal information and then getting gov. regulations mandating the certificates. There were also attempts to up the anty with semantic confusion attempting to equate "digital signatures" with "human signatures". misc. past posts about helping word smith various electronic signature legislation and/or the wide divide between "digital" and "human" signatures. http://www.garlic.com/~lynn/subpubkey.html#signature Remember that the (late 80s and) early 90s (with the attempts at ISO x.509 identity certificates) was also in the period when you saw various institutions and govs. mandating the elimination of the internet and its replacement with ISO (OSI model) networking standards. one might even contend that in the ssl domain name certificate scenario ... that once all the hype and publicity is stripped away ... that a fundamental issue is that the "relying party" has absolutely no recourse with regard to the certifying agency when things go wrong (which would exist in normal business relationship between two parties). That the "padlock" symbol is purely a representation of the hype and publicity ... and not a fundamental business foundation. recent thread about one of the major, fundamental justifications for ssl domain name certificates ... countermeasure to man-in-the-middle attacks ... and not being very effective http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Failure of PKI in messaging
Ian G wrote: > Steven M. Bellovin wrote: >> On Mon, 12 Feb 2007 17:03:32 -0500 >> Matt Blaze <[EMAIL PROTECTED]> wrote: >> >>> I'm all for email encryption and signatures, but I don't see >>> how this would help against today's phishing attacks very much, >>> at least not without a much better trust management interface on >>> email clients (of a kind much better than currently exists >>> in web browsers). >>> >>> Otherwise the phishers could just sign their email messages with >>> valid, certified email keys (that don't belong to the bank) >>> the same way their decoy web traffic is sometimes signed with >>> valid, certified SSL keys (that don't belong to the bank). >>> >>> And even if this problem were solved, most customers still >>> wouldn't know not to trust unsigned messages purporting >>> to be from their bank. >>> >> >> Precisely. The real problem is the human interface, where we're asking >> people to suddenly notice the absence of something they're not used to >> seeing in the first place. > > > Actually, there are many problems. If you ask the low-level crypto > guys, they say that the HI is the problem. If you ask the HI guys, they > say that the PKI concept is the problem. If you ask the PKI people, > they say the users are not playing the game, and if you ask the users > they say the deployment is broken ... Everyone has got someone else to > blame. > > They are all right, in some sense. The PKI concepts need loosening up, > emails should be digsig'd for authentication (**), and the HI should > start to look at what those digsigs could be used for. > > But, until someone breaks the deadly embrace, nothing is going to > happen. That's what James is alluding to: what part can we fix, and > will it help the others to move? > > iang > > ** I didn't say digital signing ... that's another problem that needs > fixing before it is safe to use, from the "ask the lawyers" basket. Perfectly safe to use in the UK. But sorry, I forgot that only the US exists. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "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: Failure of PKI in messaging
Steven M. Bellovin wrote: On Mon, 12 Feb 2007 17:03:32 -0500 Matt Blaze <[EMAIL PROTECTED]> wrote: I'm all for email encryption and signatures, but I don't see how this would help against today's phishing attacks very much, at least not without a much better trust management interface on email clients (of a kind much better than currently exists in web browsers). Otherwise the phishers could just sign their email messages with valid, certified email keys (that don't belong to the bank) the same way their decoy web traffic is sometimes signed with valid, certified SSL keys (that don't belong to the bank). And even if this problem were solved, most customers still wouldn't know not to trust unsigned messages purporting to be from their bank. Precisely. The real problem is the human interface, where we're asking people to suddenly notice the absence of something they're not used to seeing in the first place. Actually, there are many problems. If you ask the low-level crypto guys, they say that the HI is the problem. If you ask the HI guys, they say that the PKI concept is the problem. If you ask the PKI people, they say the users are not playing the game, and if you ask the users they say the deployment is broken ... Everyone has got someone else to blame. They are all right, in some sense. The PKI concepts need loosening up, emails should be digsig'd for authentication (**), and the HI should start to look at what those digsigs could be used for. But, until someone breaks the deadly embrace, nothing is going to happen. That's what James is alluding to: what part can we fix, and will it help the others to move? iang ** I didn't say digital signing ... that's another problem that needs fixing before it is safe to use, from the "ask the lawyers" basket. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
