Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Ben Laurie wrote: > This is the SSH design for host keys, of course, and also the petnames > design for URLs. Unfortunately petnames don't solve the problem that it > is hard to check the URL even the first time. the original SSL paradigm was predicated on end-to-end security that "the server the user thot they were taling to" was "the server that they were actually talking to". certificates addressed the part from "the URL inside the browser" to "the server". the paradigm was dependent on the user having a tight binding between "the server the user thot they were talking to" and "the URL inside the browser" ... which in turn was dependent on the user actually inputing the URL (as demonstration of the binding between the server the user thot they were talking to and the inputed URL). the problem was that as the infrastructure matured ... the actual URL came to have less & less meaning to the user. so the MITM-attacks moved to the weak points in the chain ... rather than attacking a valid certificate and/or the process after the URL was inside the browser, attack the process before the URL got inside the browser. petnames would seem to suffer somewhat the same problem as shared-secrets and passwords ... requiring a unique petname for every URL. it works as long as their a few ... when they reach scores ... the user no longer can manage. so part of the problem is that the URL has become almost some internal infrastructure representation... almost on par with the ip-address ... the user pays nearly as much attention to the URL for a website as they pay to the lower-level ip-address for the site (legacy requirements still have ways for people to deal with both the URL and the ip-address ... but they don't have a lot of meaning for a lot of people). however the URL Is one way of internally doing bookkeeping about a site. so security issues might be 1) is the user talking to the server they think they are talking 2) does the user believe that the site is safe 3) is the site safe for providing certain kinds of sensitive information 4) is the site safe for providing specific sensitive information #1 is the original SSL design point ... but the infrastructure has resulted in creating a disconnect for establishing this information. possibly another approach is that the local environment remembers things ... akin to PGP key repository. rather than the SSL locked ... have a large green/yellow/red indicator. red is neither SSL locked and/or checked. yellow is both SSL locked and checked. green is SSL loaked, initial checked, and further checked for entry of sensitive information. a human factors issue is how easy can you make preliminary checking ... and then not have to do it again ... where the current infrastructure requires users to match something meaningful to URL to SSL certificate on every interaction. preliminary checking is more effort than the current stuff done on every SSL URL ... but could be made to be done relatively rarely and part of an overall infrastructure that directly relates to something the end-user might find meaningful. bits and pieces of the infrastructure is already there. for instance there is already support for automatically entering userid/password on specific web forms. using bits and pieces of that repository could provide ability to flag a specific web form as approved/not-approved for specific sensitive information (like specific userid/password). the issue isn't that a simple indicator with 2-4 states isn't useful ... but the states presented need to realistic need to mean something to the user. the locked/unlocked just says that the link is encrypted. it doesn't indicate that the remote site is the server that that the user thinks it is ... in part because of the way that the infrastructure has creating disconnect between the URL and what users actually deal in. if the browser kept track of whether the user actually hit the keys for the entering of the URL ... then it might be useful for the browser to provide a higher level of confidence to the SSL certificate checking (aka it is only if the user actually typed in the URL ... can their be a high-level of confidence related to the SSL certificate checking). one might be tempted to make some grandiose philosophical security statement ... that unless the user is involved in actually doing some physical operation (at least at some point in time) to correlate between what is meaningful to the user and the internal infrastructure. the original SSL scheme was dependent on the user actually typing in the URL. this is somewhat analogous to the confusion that seems to have cropped up in the past with respect to the difference between digital signature and human signature. http://www.garlic.com/~lynn/subpubkey.html#signature x9.59 http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 could actually have digital signature applied to a retail transaction at point-of-sale as means of
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Anne & Lynn Wheeler wrote: > a more sensible human factors design ... is to remember whether a person > has checked out first time communication with a stranger ... the real > first time, have the person do something additional ... and from then on > remember that checking. in that respect ... creating a dependency on the > user to repeatedly check a field that changes possibly thousands of > times per day is extremely poor human factors security design. This is the SSH design for host keys, of course, and also the petnames design for URLs. Unfortunately petnames don't solve the problem that it is hard to check the URL even the first time. Cheers, Ben. -- 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: X.509 / PKI, PGP, and IBE Secure Email Technologies
Ben Laurie wrote: > Eh? It surely does stop MitM attacks - the problem is that there's > little value in doing so for various reasons, such as no strong binding > between domain name and owner, UI that doesn't make it clear which > domain you are going to, or homograph attacks. part II; i've repeatedly asserted that the fundamental, underlying certificate business practices is to address the first time communication between complete strangers ... analogous to the letters of credit/introduction from the sailing ship days. so the original SSL design point was to cross-check the domain name from the URL typed in by the client to the certificate supplied by the server. that basic premise is underminned when the server supplies the URL and the certificate. so you are left with placing the burdon on the user to cross-check the URL displayed with the URL they think they are going to. it is simple human dynamics ... after the first several thousand displayed URLs ... they are going to ignore the process. this is somewhat akin to the share-secret passwords ... that the security experts define that the user has to have hard-to-guess, impossible-to-remember passwords that change every 30 days, can never be written down and every new password has to be unique ... as well as unique across all security domains. the problem is that the number of unique security domains that a person deals with has grown from 1-2 (I had my first logon password in the 60s followed with the addition of an ATM pin in the late 70s) to scores ... there is no practical possibility that all such requirements can be satisified. misc. past collected posts on shared-secret http://www.garlic.com/~lynn/subpubkey.html#secrets the underlying infrastructure further complicated the whole process when a large percentage of the merchants outsourced the payment process to 3rd party ... where the click button supplied a URL of the 3rd party payment processor that had absolutely no relationship to the merchant site the client had been shopping at. this not only creates the situation where 1) any initial connection to a merchant site where the user might possibly have typed in the URL (or controls the URL generation via other mechanisms) is not checked ... and any actual checking for things like MITM-attacks doesn't occur until there is a URL provided by a potentially suspect site. but also 2) conditions the user as normal process that the pay/checkout button may have a complete different domain name URL than the domain name of the shopping site. so, pretty well documented human factors ... especially related to the design of security systems ... is that you don't tie humans making determination about soem security issue to something that repeatedly happens thousands and thousands of times. there are some guards that have to check badges against faces ... but they tend to have intensive training AND organizations that have high volume have gone to guards doing it only short periods and rotating ... and/or the guards are looking for a very simple repeating pattern and are trained to look for missing pattern). having the human have to repeatedly check a (URL) field that changes several thousand times a day against something they are suppose to expect ... is pretty quickly a useless security design. a more sensible human factors design ... is to remember whether a person has checked out first time communication with a stranger ... the real first time, have the person do something additional ... and from then on remember that checking. in that respect ... creating a dependency on the user to repeatedly check a field that changes possibly thousands of times per day is extremely poor human factors security design. now, the other part of my constant theme about certificates having design point of first time communication between complete strangers ... involves the additional constraing that the relying party has no other recourse to obtain information about the other party. if you go to paradigm where the relying party has facilities to remember first time checking ... then the appended certificate on the communication is actually only useful for the real first-time-communication (since by definition the relying party has facilities to remember previous checking ... like saving away the other parties publickey in a trusted public key repository). another part is that if you have the relying party do some additional checking on the real first time interaction (rather than expecting the user to do increasingly trivial checking on each new URL) ... and the user is really online ... then that first time checking can involve real-time check of online resources again invalidating more of the underlying design point of appending a certificates on every communciation for benefit of relying parties who have no other recourse for determining information about complete stranger in first time communication. there is something of a dichotomy here ... where ther
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Anne & Lynn Wheeler <[EMAIL PROTECTED]> > as part of various integrity issues related to that > process, there has been a proposal, somewhat backed by > the ssl domain name certification authority industry > that domain name owners also register a public key > with the domain name infrastructure (in addition to > identificaiton information). then future communcation > can be digitally signed and verified with the onfile > public key. also the ssl domain name certification > authority industry can require that ssl domain name > certificate applications be digitally signed. then the > certification authority can replace the expensive, > time-consuming, and error-prone identification > matching process with a much less-expensive and > efficient authentication process by doing a real-time > retrieval of the on-file publickey from the domain > name infrastructure for verifying the digital > signature (in lieu of doing a real-time retrieval of > the on-file identificaiton information for the > expensive, time-consuming and error-prone > identification matching). Unfortunately most domain name registrars take a completely irresponsible attitude to domain name theft, despite the fact that domain name theft is a major problem. OpenSRS is good but their resellers a very bad. Unfortunately by default, one winds up having the same password with OpenSRS as with the reseller. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG LA7xNzxuTFoXA1ir8b2UWqPg/P6NhF+naIs34+LG 49FONv1xLEWSjg/TiZ8oHGLHyCAhQLOM7CzPNCuTD - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Ben Laurie wrote: > Eh? It surely does stop MitM attacks - the problem is that there's > little value in doing so for various reasons, such as no strong binding > between domain name and owner, UI that doesn't make it clear which > domain you are going to, or homograph attacks. it stops the MITM attacks where the client supplies a URL and the server supplies a certificate that corresponds to the URL. the original issue is that a MITM might have redirected the connection from the client to a bogus site ... or an intermediate site that then impersonated the real site. the infrastructure issue was that the merchants decided that SSL was too high an overhead and stopped using SSL for the main connection where the client supplied the URL. they allowed the client supplied URL connection to be done w/o a URL. then later ... the website provided a click button for checkout/pay ... which supplied a URL and then they also supplied a certificate that matches the URL that they provided. this situation could either be a completely bogus site ... or even a mitm-attack ... which just did a pure passthru of all traffic going in each way except for the pay/checkout button. for the pay/checkout button, the mitm substituted their own URL & certificate. everything else passes thru as usual ... except the mitm is having two ssl session ... the mitm to "real" server session and the mitm to the client session. the mitm to "real" server uses the "real" server's certificate ... the mitm to client server users the mitm certificate. since the mitm supplied the URL to the client as part of the click operation ... the mitm can control that the actual URL invoked by the client matches the certitificate used by the mitm. the e-commerce use for pay/checkout scenario is one of the major uses for SSL on the internet today ... and the way that the infastructure has come to use SSL no longer prevents the mitm-attack with the attacker can supply both the URL and the certificate. the issue for preventing mitm-attacks ... you need the client to supply the URL and have the SSL process validate the other end of that connection (with a server provided ssl domain name certificate ... or at least a trusted, supplied public key associated with the URL). when the attacker provides both the URL and a trusted public key ... what is being prevented. there is another problem, somewhat the week binding between domain name and domain name owner. the issue is that many of the certification authorities aren't the authoritative agency for the information they are certifying. much of the original justification for SSL related to mitm attacks was various integrity issues in the domain name infrastructure. the process tends to be that a domain name owner registers some amount of identification information for their domain name ownership with the domain name infrastructure. the certification authorities then require that SSL domain name certificate applicants also provide some amount of identification information. then the certification authorities attempt to do the expensive, time-consuming, and error-prone process of matching the supplied identification information for the SSL domain name certificate with the identificaiton information on file with the domain name infrastructure for the domain name. as part of various integrity issues related to that process, there has been a proposal, somewhat backed by the ssl domain name certification authority industry that domain name owners also register a public key with the domain name infrastructure (in addition to identificaiton information). then future communcation can be digitally signed and verified with the onfile public key. also the ssl domain name certification authority industry can require that ssl domain name certificate applications be digitally signed. then the certification authority can replace the expensive, time-consuming, and error-prone identification matching process with a much less-expensive and efficient authentication process by doing a real-time retrieval of the on-file publickey from the domain name infrastructure for verifying the digital signature (in lieu of doing a real-time retrieval of the on-file identificaiton information for the expensive, time-consuming and error-prone identification matching). the two catch22 issues here are 1) improving the overall integrity issues of the domain name infrastructure lessons the original justification for ssl domain name certificates 2) if the certification authority industry can rely on real-time retrieval of publickeys from the domain name infrastructure as the base, TRUST ROOT for all of their operations ... it is possible that other people in the world might also be able to do real-time retrieval of publickeys as a substitute to relying on SSL domain name certificates misc, numerous past postings mentioning SSL and ssl domain name certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert ---
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Anne & Lynn Wheeler wrote: > James A. Donald wrote: >> However, the main point of attack is phishing, when an >> outsider attempts to interpose himself, the man in the >> middle, into an existing relationship between two people >> that know and trust each other. > > in the public key model ... whether it involves pgp, pki, digital > certificates, what-ever; the local user (relying party) has to have a > local trusted repository for public keys. in the pki model, this tends > to be restricted to public keys of certification authorities ... so that > the relying party can verify the digital signature on these > message/document constructs called digital certificates. > > in the traditional, ongoing relationship scenario, relying parties > directly record authentication information of the parties they are > dealing with. if a relying party were to directly record the public key > of the people they are communicating with ... it is the trusting of that > public key and the validating of associated public key operations that > provide for the countermeasure for man-in-the-middle attacks and > phishing attacks. > > the issue that has been repeatedly discussed is that supposedly the > existing SSL domain name digital certificates was to prevent > impresonation and mitm-attacks. however, because of various > infrastructure shortcomings ... an attacker can still operate with > perfectly valid SSL domain name digital certificates ... and it doesn't > stop the MITM-attack and/or phishing. Eh? It surely does stop MitM attacks - the problem is that there's little value in doing so for various reasons, such as no strong binding between domain name and owner, UI that doesn't make it clear which domain you are going to, or homograph attacks. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "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: X.509 / PKI, PGP, and IBE Secure Email Technologies
James A. Donald wrote: -- From: Werner Koch <[EMAIL PROTECTED]> You need to clarify the trust model. The OpenPGP standard does not define any trust model at all. The standard merely defines fatures useful to implement a trust model. "Clarifying the trust model" sounds suspiciously like designers telling customers to conform to designer procedures. This has not had much success in the past. People using PGP in practice verify keys out of band, not through web of trust. James, Yes. Your observation on out-of-band PGP key verification is very important and actually exemplifies what Werner wrote. Exactly because there's no trust model defined a priori, uses can choose the model they want including one-on-one trust. This is important because it eliminates the need for a common root of trust -- with a significant usability improvement. If the web of trust is used, the sender and recipient must a priori trust each other's key signers, requiring a common root of trust -- that may not even exist to begin with. So, instead of worrying about what trust model PGP uses, the answer is that you can use any trust model you want -- including a hierarchical trust model as used with X.509. Jon Callas and I had several conversations on trust in May '97, when Jon visited me for two weeks while I was in Brazil at the time, I think before the OpenPGP WG was even working on these issues. This is one of the comments Jon wrote in a listserv then, with a great insight that might be useful today: As I understand it, then, I've been thinking about some of the wrong issues. For example, I have been wondering about how exactly the trust model works, and what trust model can possibly do all the things Dr Gerck is claiming. I think my confusion comes from my asking the wrong question. The real answer seems to be, 'what trust model would you like?' There is a built in notion (the 'archetypical model' in the abstract class) of the meta- rules that a trust model has to follow, but I might buy a trust model from someone and add that, design my own, or even augment one I bought. Thus, I can ask for a fingerprint and check it against the FBI, Scotland Yard, and Surite databases, check their PGP key to make sure that it was signed my Mother Theresa, ask for a letter of recommendation from either the Pope or the Dalai Lama (except during Ramadan, when only approval by the Taliban will do), and then reject them out of hand if I haven't had my second cup of coffee. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Werner Koch <[EMAIL PROTECTED]> > You need to clarify the trust model. The OpenPGP > standard does not define any trust model at all. The > standard merely defines fatures useful to implement a > trust model. "Clarifying the trust model" sounds suspiciously like designers telling customers to conform to designer procedures. This has not had much success in the past. People using PGP in practice verify keys out of band, not through web of trust. People using https tend to click through. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 9zzvV5qgyWeB4uTJn5vTjFtKeouMk46hiM0EN7Q+ 4CKg4nhwvcBjl855xVUXY5XMP46ZdvXoOl8Wu0Hyb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
On Mon, 12 Dec 2005 10:59:05 -0600, Travis H said: > Not to side track the discussion, but frequently I've heard PKI > compared to PGP's model. Isn't PGP's trust model the same as everyone > being their own CA? You need to clarify the trust model. The OpenPGP standard does not define any trust model at all. The standard merely defines fatures useful to implement a trust model. AFAIK, PGP provides two different trust models; with GnuPG you may also select between 4 trust models. However this is implementation specific and not part of the standard. The "classic" web of trust is just the commonly used one. It is a pity that many commonly used mail programs don't even make use of any real trust model but use the "always" trust model. The newer trust model "pgp" makes use of the advanced OpenPGP features and allows implementing a hierarchical model very similar to the X.509 one. In fact it is a superset of the X.509 model. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Ralf Senderek <[EMAIL PROTECTED]> > I think what's missing is the understanding that there > cannot be secure email without the persons involved > acting responsible and knowing their role in the > process. Your mother will probably expect the computer > to do the job for her (mine will never expect anything > from computers) rejecting any responsibility for her > email's security. In my opinion establishing secure > email this way is impossible despite the fact that > encryption is (relatively) easy if our algorithms work > as expected This sounds like "it is not my fault. It is those stupid user's fault" No, it is not those stupid user's fault. It is our fault. For example phishing ought not to be possible - would not be possible if we used zero knowledge technologies to protect passwords. Whenever a user communicates anything to anyone, they use a password, or some form of shared secret - their credit card number - the password whereby they login to their mail server. Therefore, whenever a user communicates anything to anyone, it should be secure, but it is not. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG Jogksi+CFTLv6yHXLYAd6VeQz73gNHYNM1t/B6aB 4uVe9+oTO/DP7awisj6RYpMbzekGf0+UrwxWfnpxM - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Not to side track the discussion, but frequently I've heard PKI compared to PGP's model. Isn't PGP's trust model the same as everyone being their own CA? I find PGP to be problematic. Many keys I see are only self-signed, and this includes important keys like CERT. Many others sit unsigned on the same website you access to download the source code protected by it. And 90% of the time when they have more than one signature you don't have a key that signed the other party's key, so you get to do a breadth-first search manual-like (pathserver being dead and all). Even with kgpg pulling the keys from a keyserver for you, it's still non-trivial. I successfully inspired a local keysigning, but it seems like most of the people didn't see any immediate benefit, and so declined to participate. "What does this mean for me" was a common question. I tried to explain the purpose, but I suspect it is too recondite or too far removed from their experience. Perhaps I'd have better luck by stating what kind of attacks it would prevent (email spoofing being relatively rare, save for some obvious spam tactics). I'm open to any suggestions along these lines. -- http://www.lightconsulting.com/~travis/ -><- P=NP if (P=0 or N=1) "My love for mathematics is unto 1/x as x approaches 0." GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Ed Gerck <[EMAIL PROTECTED]> > Digital certs (X.509 and PGP) are useful when the key > owner is not online. There is a world when this not > only happens but is also useful. BTW, this is > recognized in IBE as well. But the key owner is always online, for in practice, certs are always used for https. Arguably we should be using not-necessarily-online certs to sign email, but the email that arguably needs signing, for example emails from amazon.com, are never signed. The only reason this email is signed is to make a point about technology, not because the signature serves any useful purpose. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ca4N69sv32Q/plWYe5BnvcydTDFaMVJkZ0rPbVp6 4CRaaWK8UP3bCPHDbDzuPW7zEKImu5L9x7RUMIrbG - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Anne & Lynn Wheeler <[EMAIL PROTECTED]> > drastically improving the useability of the interface > to the trusted public key repositories could be viewed > as having two downsides 1) certification authorities > that haven't payed to have their public keys preloaded > can more easily join the club, 2) the pgp-like > scenario becames much easier, potentially drastically > reducing existing reliance on the > digital-certificate-only (and certification authority > only business process) digital-signed-operation model. I would state the same thing differently: That the revenue model is based on sprinkling holy water over communications, rather than actually providing security. Hence the proposal to address phishing by providing higher priced grades of holy water. Public keys are relevant to the problem of decentralized reputation management. For relationship management, shared secrets are better. At present, the only widely applied reputation management software is that possessed by Ebay - which uses centralized reputation management software, so that it can charge people a fee for making use of their own reputations, and thus has no inherent need or desire for public keys. After all these years, we still do not have a good fit between the capabilities of the technology, the usability of the interface, and the problems people need solved. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG X1okruQ3BE+qbWjk1b7CgXMbsiKNhvf5oMKDgR71 4cxizGKqHfxeifgKTUEvpkLYq7wSgzAckTy2yLzQ8 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Ed Gerck <[EMAIL PROTECTED]> > As new capabilities conflict with the old, the end > result of this approach seems to ne a lot of patched > in complexity and vulnerabilities. > > It seems better to start with a performance > specification for the full system. The code can follow > the specs as close as possible for each version, the > specs can change too, but at least the grand picture > should exist beforehand. Usability is the key part of perfomance. Amazon is sending out unsigned emails. Seems to me this is in part because they find it hard to sign anything, in part because if they did sign something I doubt it would do the end user much good, since the end user is already suffering from name overload, and is unlikely to appreciate the difference between a signature belonging to amazon.com, amazon.co.uk, and amazon.jim.com We really need to start from the user, and look for ways in which the user's mental model of security can be used to defeat realistic threats. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG b5RoNWK+PD+pn6rk1lBkzIqv8T4ntwUO6CxDoPtA 48yzird9uDuNNK+xU0XcZisSug3K2XHzHu0MXgwqB - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Bill Stewart <[EMAIL PROTECTED]> > The real security issue for your mother is [...] her > bank and eBay don't cryptographically sign their mail. And, since her bank and ebay are under massive attack from phishers, and your mother, if she is using any of the common email clients is using a cryptographically enabled mail agent, why don't they sign their email? This is exactly the attack that PKI was designed to address. My possibly biased answer to this question, based on my past job as key keeper for two companies, would be that not only can your mother not sign her stuff with PKI, but the chairman of the board finds it even harder. Does anyone else have war stories on this issue? Just as big companies find it hard to write software that does not open their servers to a cross scripting attack, and hard to interact with their users in ways that do not train their users to respond to phishing attacks, and hard to write server side software that does not rely on the behavior of client side forms, they also find it hard to sign their email. In the unlikely event that my mother is threatened by man in the middle attacks, she will allow me to set up secret key on her computer, and will follow my instructions on how to use it, but the chairman of the board will not, nor will the marketing department. That is my experience - does anyone else have any experience that differs from this, or confirms this? And before we sneer at the chairman of the board - hands up all programmers who failed to client and server side disable all past cookies and issue new https and http cookies on receiving a valid login, and all programmers who failed to enumerate and sterilize all fields appearing in any response. It is not my position that inability to sign means that the chairman of the board is stupid. It is that cryptographic signatures are too @#$%^&* hard and need to be made user friendly. First write software that is easy enough for your mother. Then we can work on making it easy enough for the marketing department. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG gvDLBPaNQFZ3Y0yhzmO2KnYEKGolt9E+eey2rPxE 4bGpW6AUGiMGbJFzaXJ8QcBY0HMhbypcque+5LrMd - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
James A. Donald wrote: > This was the scenario envisaged when PKI was created, > but I don't see it happening, and in fact attempting to > do so using existing user interfaces is painful. They > don't seem designed to do this. > > My product, Crypto Kong, http://echeque.com/Kong was > designed to directly support this scenario in a more > convenient fashion - it keeps a database of past > communications and their associated keys, but there did > not seem to be a lot of interest. I could have made it > more useful, given it more capabilities, but I felt I > was missing the point i've seen some discussions that were either/or regarding pki & pgp; aka pki advocates attempting to position pki as a OR to pgp. the issue is that both pki and pgp require a local trusted public key repository as the basis for establishing trust. pki then layers on it, these certification authority business processes, specialized digitally signed messages called digital certificates, etc to address first time communication between strangers where the relying parties have no other resources for determining information about the sender in an offline environment. they then advocate that all (personally) digitally signed operations are required to have attached x.509 identity digital certificates that has been digitally signed by a certification authority. we saw some of that when we did work on the cal. state & fed. electronic signature legislation http://www.garlic.com/~lynn/subpubkey.html#signature one possible interpretation might be that it would have increased the revenue stream for the certification authority industry. drastically improving the useability of the interface to the trusted public key repositories could be viewed as having two downsides 1) certification authorities that haven't payed to have their public keys preloaded can more easily join the club, 2) the pgp-like scenario becames much easier, potentially drastically reducing existing reliance on the digital-certificate-only (and certification authority only business process) digital-signed-operation model. part of the problem with the trusted third party certification authority model is that its primary benefit in the case of first time communication betweeen two strangers ... where the relying party has no other recourse to information about the other party. this is actually an extremely small percentage of communications. we saw some of this working on the original e-commerce activity http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 where we layed out hypothetical certification issues for merchants ... including things like having FBI background checks for all merchant employees. the problem is that e-commerce transactions have been quite bi-model whith the largest percentage of transaction occuring as repeat business with well-known merchants. in these cases, consumers have established trust via a large number of other mechanisms ... so there is little added value that a certification authority can provide ... especially if they aren't willing to stand-behind and guarantee all merchant transactions (ssl then is primarily countermeasure to mitm-attack and evesdropping on transaction as opposed to a certification/trust issue). the rest of the remaining transaction are spread around to a large number of different merchants having a few transactions each. the issue here is that the incremental revenue flow for a few transactions a month couldn't possibly cover the cost of a certification process that involved things like fbi background checks on all merchant employees. the large majority of transactions are either repeat business and/or with extremely well-known merchants ... this doesn't satisfy the PKI target profile of first time communication between complete strangers. simple countermeasure to mitm-attack and countermeasure is achieved by having stored the merchant's public key (from the consumer's standpoint). from the merchant standpoint they already have transaction guarantees on credit card processing from their contract with financial institution. the threat/vulnerability model here is client-originated fraudulent transactions that aren't strongly authenticated. here, x9.59 standard http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 allows for digitally signed transaction where the public key is registered with the consumer's financial institution and the digital signature is verified by the consumer's financial institution as part of verifying the transaction. the other part of x9.59 standard is that it specifies that account numbers used in x9.59 transactions can't be used in non-authenticated transactions. this eliminates both data breaches and evesdropping as a threat/vulnerability for fraudulent financial transactions ... aka the requirement given the x9a10 working group for x9.59 standard was to preserve the integrity of the financial infrastructure fo
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- James A. Donald wrote: > > However, the main point of attack is phishing, when > > an outsider attempts to interpose himself, the man > > in the middle, into an existing relationship between > > two people that know and trust each other. Anne & Lynn Wheeler <[EMAIL PROTECTED]> > in the traditional, ongoing relationship scenario, > relying parties directly record authentication > information of the parties they are dealing with. if a > relying party were to directly record the public key > of the people they are communicating with ... it is > the trusting of that public key and the validating of > associated public key operations that provide for the > countermeasure for man-in-the-middle attacks and > phishing attacks. This was the scenario envisaged when PKI was created, but I don't see it happening, and in fact attempting to do so using existing user interfaces is painful. They don't seem designed to do this. My product, Crypto Kong, http://echeque.com/Kong was designed to directly support this scenario in a more convenient fashion - it keeps a database of past communications and their associated keys, but there did not seem to be a lot of interest. I could have made it more useful, given it more capabilities, but I felt I was missing the point --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 4ostZwIWJbNX6/eRYYX4QMLG5GGNUaPJao5ZKKGB 4Bt20kCp2fkd6wgjBDjYMz5ZqUEnTYL4O3aTalDOB - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
On Fri, 9 Dec 2005, Ed Gerck wrote: > [...] at least the grand > picture should exist beforehand. This is what this thread's subject > paper is about, the grand picture for secure email and why aren't > we there yet (Phil's PGP is almost 15 years old) -- what's missing. > and Bill Stewart wrote: > Popularity of a product is critical to its security; > you don't gain anonymity if the Feds can recognize that > you're one of the dozen users of a given application. > Your mom can use Skype, but nobody she knows uses Crypto Kong, > and I only know a few people who use PGP to email their mom. > But some of the Instant Messaging systems use crypto; > too bad that they're continually trying to be incompatible > with each other to gain market share. I think what's missing is the understanding that there cannot be secure email without the persons involved acting responsible and knowing their role in the process. Your mother will probably expect the computer to do the job for her (mine will never expect anything from computers) rejecting any responsibility for her email's security. In my opinion establishing secure email this way is impossible despite the fact that encryption is (relatively) easy if our algorithms work as expected and you have the correct high-quality public key. And even if Instant Messaging systems would use the same crypto people will use them like cell phones without any consciousness of their own responsibility for key validation. Getting good crypto into mass products can help but does not eliminate the necessity for checking essential properties of the system they use. How we can make this job as reliable as possible is the question at the heart of the problem. Ralf Senderek *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.* * Ralf Senderek <[EMAIL PROTECTED]> http://senderek.com* What is privacy * * Sandstr. 60 D-41849 Wassenberg +49 2432-3960 * without * * PGP: AB 2C 85 AB DB D3 10 E7 CD A4 F8 AC 52 FC A9 ED *Pure Crypto? * 49466008763407508762442876812634724277805553224967086648493733366295231438448 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Anne & Lynn Wheeler wrote: OCSP provides for a online transaction which asks whether the stale, staic information is still usuable, attempting to preserve the facade that digital certificates serve some useful purpose when there is online, direct access capability. The alternative is to eliminate the digital certificates all together and rather than doing an OCSP transaction, do a direct, online transaction. The benefits of not always requiring direct online transactions has been pointed out before in this thread, in terms of anonymity, availability and reliability. What happens when you get a message and the direct, online connection isn't there? You can' decrypt it even though it you need to? Digital certs (X.509 and PGP) are useful when the key owner is not online. There is a world when this not only happens but is also useful. BTW, this is recognized in IBE as well. A couple additional comments: > the baseline analysis, threat/vulnerability models, etc ... start with > the simplest and then build the incremental pieces frequently > looking at justification for the additional complexity. > > when doing the original design and architecture you frequently start > with the overall objective and do a comprehensive design (to try and > avoid having things fall thru the cracks). Agreed, and that's where a baseline analysis really fails to reveal a design's pros and cons -- because it follows a different path. Seems logical but denies the design's own logic (which did NOT use a baseline approach to begin with, on purpose). Therefore, when I look into X.509 / PKI issues, or secure email issues, a baseline analysis is not so very useful. > the trusted third party certification authority is selling digital > certificates to key owners for the benefit of relying parties. The RPs are not part of the contract. Without CAs, there's no "key owner" in PKI. It's for the benefit (and reduction of liability) of the key owners. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Ed Gerck wrote: > I think that's where PKI got it wrong in several parts and not > just the CPS. It started with the simplest (because it was meant to > work for a global RA -- remember X.500?) and then complexity was > added. Today, in the most recent PKIX dialogues, even RFC authors > often disagree on what is meant in the RFCs. Not to mention the > readers. the baseline analysis, threat/vulnerability models, etc ... start with the simplest and then build the incremental pieces frequently looking at justification for the additional complexity. when doing the original design and architecture you frequently start with the overall objective and do a comprehensive design (to try and avoid having things fall thru the cracks). i would contend that the issue with PKI isn't as much that they started with simple and then did incremental piece-meal design (rather than complete, comprehensive design) ... but they actually did design something for a specific purpose ... and subsequently it was frequently tried to force-fit it for purposes for which it wasn't originally designed for. for example the traditional business model tends to have relying parties contracting directly with the parties they rely on (and there is contractual obligation between the two parties). the evolution of the trusted third party certification authority model violates most standard business practices that have grown up over hundreds of years. the trusted third party certification authority is selling digital certificates to key owners for the benefit of relying parties. there is a large disconnect where the parties that are supposedly going to rely on and benefit from the digital certificates aren't the ones contracting for the digital certificates. this disconnect from standard business practices can be considered the motivating factor for the invention of CPS ... even tho there may not be a direct business and contractual relationship between the relying parties and the certification authorities ... a CPS tries to fabricate a sense of comfort for the relying parties. A contractual relationship would otherwise provide for this sense of trust... the relying party pays the certification authority for something, and the certification authority then has some obligation to provide something in return to the relying party. In most trusted third party certification authority operations there is no legal, business or otherwise binding relationship between the relying party and the TTP/CA ... it is between the key owner and the TTP/CA. This could be further aggravated by RFC authors who possibly have no familiarity with standard business practices and attempt to write something just because they want it to be that way. Another example could be considered OCSP. Basically digital certificates are stale, static, r/o, armored copies of some information located someplace. A business process model has relying parties, relying on the information in stale, static, r/o copies of the information because they have no means for directly accessing the real, original information (basically the letters of credit/introduction from sailing ship days ... aka offline with no local resources). OCSP provides for a online transaction which asks whether the stale, staic information is still usuable, attempting to preserve the facade that digital certificates serve some useful purpose when there is online, direct access capability. The alternative is to eliminate the digital certificates all together and rather than doing an OCSP transaction, do a direct, online transaction. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
At 09:40 AM 12/8/2005, Aram Perez wrote: On Dec 7, 2005, at 10:24 PM, James A. Donald wrote: Software is cheaper than boats - the poorest man can afford the strongest encryption, but he cannot afford the strongest boat. If it is that cheap, then why are we having this discussion? Why isn't there a cheap security solution that even my mother can use? Usability is a hard problem, and security is a really broad field. PGP, for instance, did a pretty good job of security a decade ago, given Phil's threat models, (ignoring a few algorithm problems that were mostly related to trying to skimp on bits and the subsequent weaknesses in MD5), but the usability was pretty rough back then, and version compatibility has gotten enough worse that Hugh Daniel and I can no longer reliably communicate with PGP. But even if we both drop back to GPG on text files, and use remailers run by friends on Tor nodes run by random strangers, KGB-proof security would require protection against black-bag jobs on Hugh's keyboards and duping employees at my company's IT department into weakening my Windows XP configuration. (For cost-effectiveness and avoidance of detection, I'd recommend the latter strategy, probably by selling them some new nifty administration tool or Instant Messaging client :-) The real security issue for your mother is threat models. If your mom isn't using a Mac or administering her own Linux box, then her biggest security threat is that she's computing on a box made of Swiss cheese (though XP does seem to be noticeably better than Win95/98/ME) and probably using a browser that's happy to accept random software installed by spammers and phishers, and if she's not using webmail, she's probably running a mail client that happily displays clickable links to phishing sites purporting to be eBay or her bank. And that's mostly independent of whether she can trustably send email to other members of the Ladies' Sewing Circle and Terrorist Society without the Feds reading it, which is the kind of problem PGP was trying to solve, because her bank and eBay don't cryptographically sign their mail. Popularity of a product is critical to its security; you don't gain anonymity if the Feds can recognize that you're one of the dozen users of a given application. Your mom can use Skype, but nobody she knows uses Crypto Kong, and I only know a few people who use PGP to email their mom. But some of the Instant Messaging systems use crypto; too bad that they're continually trying to be incompatible with each other to gain market share. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Anne & Lynn Wheeler wrote: usually when you are doing baseline ... you start with the simplest, evaluate that and then incrementally add complexity. I think that's where PKI got it wrong in several parts and not just the CPS. It started with the simplest (because it was meant to work for a global RA -- remember X.500?) and then complexity was added. Today, in the most recent PKIX dialogues, even RFC authors often disagree on what is meant in the RFCs. Not to mention the readers. As another example, at least one IBE offer does not talk about key lifetime at all -- in fact, the documentation online talks about using the same key for _all_ future communications. When this, of course, fails and key expiration is introduced, it will be over an existing baseline... a patch. Key revocation will be even harder to introduce in IBE. As new capabilities conflict with the old, the end result of this approach seems to ne a lot of patched in complexity and vulnerabilities. It seems better to start with a performance specification for the full system. The code can follow the specs as close as possible for each version, the specs can change too, but at least the grand picture should exist beforehand. This is what this thread's subject paper is about, the grand picture for secure email and why aren't we there yet (Phil's PGP is almost 15 years old) -- what's missing. BTW, there's a new version out for the "X.509 / PKI, PGP, and IBE Secure Email Technologies" paper and Blog comments in the site as well, at http://email-security.net Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
James A. Donald wrote: > However, the main point of attack is phishing, when an > outsider attempts to interpose himself, the man in the > middle, into an existing relationship between two people > that know and trust each other. in the public key model ... whether it involves pgp, pki, digital certificates, what-ever; the local user (relying party) has to have a local trusted repository for public keys. in the pki model, this tends to be restricted to public keys of certification authorities ... so that the relying party can verify the digital signature on these message/document constructs called digital certificates. in the traditional, ongoing relationship scenario, relying parties directly record authentication information of the parties they are dealing with. if a relying party were to directly record the public key of the people they are communicating with ... it is the trusting of that public key and the validating of associated public key operations that provide for the countermeasure for man-in-the-middle attacks and phishing attacks. the issue that has been repeatedly discussed is that supposedly the existing SSL domain name digital certificates was to prevent impresonation and mitm-attacks. however, because of various infrastructure shortcomings ... an attacker can still operate with perfectly valid SSL domain name digital certificates ... and it doesn't stop the MITM-attack and/or phishing. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Ed Gerck wrote: > PGP is public-key email without PKI. So is IBE. And yet neither of them has > all the identical, same basic components that PKI also needs. Now, when you > look at the paper on email security at > http://email-security.net/papers/pki-pgp-ibe.htm > you see that the issue of what components PKI needs (or not) is not > relevant to the analysis. usually when you are doing baseline ... you start with the simplest, evaluate that and then incrementally add complexity. in that sense PGP is much closer to the simplest baseline ... and PKI becomes added complexity ... inverting you classification; email PKI is PGP with digital certificates added. you then could add various layers of public key operation where the relying parties have direct access to the information in one way or another and therefor don't require stale, static, armored cached copies (digital certificate) of the real information. then you can go thru numerous layers of PKI ... are the relying parties and the digital certificate creators part of the same business organizations ... and therefor require neither contractual relationship and/or CPS as a substitute for contractual relationship. then add trusted third party certification authority PKI ... where the relying parties and the certification authorities have direction contractual relationship and thefore don't require CPS as a substitute for contractual relationship. it is when you get to trusted third party certification authority PKI ... where the relying parties and the ttp/ca are part of totally different business operations and have no contractual relationship that you then get into the issue of how does a relying party actually know than it should be trusting a ttp/ca. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Ed Gerck wrote: > I believe that's what I wrote above. This rather old point (known to the > X.509 authors, as one can read in their documents) is why X.509 simplifies > what it provides to the least possible _to_automate_ and puts all the local > and > human-based security decisions in the CPS. > > (The fact that the CPS is declared to be out of scope of X.509 is both a > solution and a BIG problem as I mentioned previously.) i like the explanation that some attempted to give at the acm sigmod conference in san jose (circa 1992) of what was going on in the x.5xx standards activities; ... a bunch of network engineers trying to re-invent 1960s database technology ... the x.509 digital certificates being a stale, static cachable entry of something in x.500 ldap database ... that was armored for survival in potentially hostile environment and for relying parties that didn't have ability to access the real database entry. cps was something that was needed for trusted third party certification authority operation ... not for x.509 identity certificate itself. the issue is when you effectively have these stale, static cacheable, armored database entries that aren't part of an organization and business processes that relying parties belong to. traditional access to database entries (whether you are directly accessing the entry or a stale, static cached copy of the database entry) ... the business processes accessing the data and the businesses responsible for the data are part of the same operation and/or belong to organizations that have binding contractual relationships. it is only when you have parties responsible for the information (trusted third party certification authorities) that are 1) totally different from the parties relying on the information and/or 2) the different parties have no contractual relationships. one could hypothesize that the creation of CPS were to provide some sort of substitute for contractual relationship between different organizations/parties where the relying party has no means of directly accessing the information and must rely on a stale, static digital certificate representation (of that information), provided by an organization that the relying party has no contractual relationship (just claiming to be a trusted third party certification authority possibly wasn't enough of a sense of security for some relying parties and so CPS were invented to provide relying parties a higher sense of comfort in lieu of having something like an actual contractual relationship). that makes CPSs a substitute for contractual relationships when x.509 digital certificates are used for trusted third party certification authorities where the relying parties and the TTP/CAs are different organizations. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
On Thu, Dec 08, 2005 at 05:10:20PM -0800, Ed Gerck wrote: > PGP is public-key email without PKI. This is true for use in geodesic networks, but not true for inter-organization email, one ends up introducing gateway systems, that create an ad-hoc PKI of gateways that have exchanged keys and users that have authenticated to the gateways when one of the sides has no such gateway. Key management does not go away. > So is IBE. I disagree here, with IBE there still needs a way to securely obtain the site public key for each site. Granted, you don't need a per-user key, but this does not make the problem of key management go away. My *personal* view is that patent encumbered technologies don't have a major role to play in anything quite as ubiquitous as email. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
On Thu, Dec 08, 2005 at 09:40:22AM -0800, Aram Perez wrote: > On Dec 7, 2005, at 10:24 PM, James A. Donald wrote: >> Aram Perez >>> James A. Donald: We can, and should, compare any system with the attacks that are made upon it. As a boat should resist every probable storm, and if it does not it is a bad boat, an encryption system should resist every real threat, and if it does not it is a bad encryption system. >>> I'm sorry James, but you can't expect a (several >>> hundred dollar) rowboat to resist the same probable >>> storm as a (million dollar) yacht. >> Software is cheaper than boats - the poorest man can >> afford the strongest encryption, but he cannot afford >> the strongest boat. > If it is that cheap, then why are we having this discussion? Why > isn't there a cheap security solution that even my mother can use? Can your mother sail a boat? Worth noting that more expensive doesn't necessarily make the boat easier to sail (in fact there are more things to tune, in general), and at the point that you're getting a million pound yacht, you'll probably be hiring someone very qualified to skipper it for you... Is that a useful comparison then to security software? I would expect a competent sailor to be able to weather some storms in a rowboat, where, your mother (to use the example above) would fail. If we carry the discussion to its logical conclusion: I'd therefore expect someone who understands about security to be able to use available security software with a reasonable ability to keep their data safe. Useability and cost are not necessarily related. This discussion is conflating both things. In the security software case, the useability is not there yet at all, the cost is generally fine. The question you want to be asking is "what can be done to make the available software useable safely by my mother?" Cheers MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/ (Please use this address to reply) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- James A. Donald: > > > > We can, and should, compare any system with the > > > > attacks that are made upon it. As a boat > > > > should resist every probable storm, and if it > > > > does not it is a bad boat, an encryption system > > > > should resist every real threat, and if it does > > > > not it is a bad encryption system. Aram Perez > > > I'm sorry James, but you can't expect a (several > > > hundred dollar) rowboat to resist the same > > > probable storm as a (million dollar) yacht. James A. Donald: > > Software is cheaper than boats - the poorest man can > > afford the strongest encryption, but he cannot > > afford the strongest boat. Aram Perez > If it is that cheap, then why are we having this > discussion? Why isn't there a cheap security solution > that even my mother can use? Design is not cheap, and in particular cryptographic design is not cheap, because one has to see what attacks eventuate - one commonly discovers that one's cryptography was fine, but one's threat model was inadequate. But having been designed, and survived attack, it can then be supplied to everyone. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG J0TlTGnN72O7gpg1XX5GRDTi4nJ4wVeAa557yccN 44MC72QwGhBFeTainKp+spi3G6oGpfuNsPZYDSpwt - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Anne & Lynn Wheeler <[EMAIL PROTECTED]> > PKI is trying to offer some added value in first time > communication between two strangers However, the main point of attack is phishing, when an outsider attempts to interpose himself, the man in the middle, into an existing relationship between two people that know and trust each other. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG FYVMooN6NmFglw4lbAf5aNMCV9JMCU/ozMfXJMgI 4WWQ2pQAOpm3Ttro+Ga5AcJIyW4/gefQzmeVWEsPN - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Anne & Lynn Wheeler wrote: Ed Gerck wrote: Regarding PKI, the X.509 idea is not just to automate the process of reliance but to do so without introducing vulnerabilities in the threat model considered in the CPS. but that is one of the points of the article that as you automate more things you have to be extra careful about introducing new vulnerabilities I believe that's what I wrote above. This rather old point (known to the X.509 authors, as one can read in their documents) is why X.509 simplifies what it provides to the least possible _to_automate_ and puts all the local and human- based security decisions in the CPS. (The fact that the CPS is declared to be out of scope of X.509 is both a solution and a BIG problem as I mentioned previously.) the issue of public key email w/o PKI ... is you have all the identical, same basic components that PKI also needs. PGP is public-key email without PKI. So is IBE. And yet neither of them has all the identical, same basic components that PKI also needs. Now, when you look at the paper on email security at http://email-security.net/papers/pki-pgp-ibe.htm you see that the issue of what components PKI needs (or not) is not relevant to the analysis. > ... as in my oft repeated description of a crook attacking the authoritative agency that a certification authority uses for the basis of its certification, and then getting a perfectly valid certificate. What you say is not really about X.509 or PKI, it's about the CPS. If the CPS says it restricts the cert to the assertion that the email address was timely responsive to a random challenge when the cert was issued, then relying on anything else (e.g., that the email address is owned or operated by an honest person or by a person who bears a name similar to that mailbox's username) is unwarranted. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Ed Gerck wrote: Regarding PKI, the X.509 idea is not just to automate the process of reliance but to do so without introducing vulnerabilities in the threat model considered in the CPS. but that is one of the points of the article that as you automate more things you have to be extra careful about introducing new vulnerabilities (of course a business operation will make claims that while they may have introduced enormous additional complexity and number of business processes ... that they are all perfect and have no vulnerabilities). the issue of public key email w/o PKI ... is you have all the identical, same basic components that PKI also needs. there is a local trusted public key repository and a method of getting keys into/out of that trusted public key repository. in the non-PKI case, the trusted public key repository contains public keys that are used to directly authenticate messages from other entities. in the PKI case, the trusted public key repository also contains public keys that are used to authenticate messages from a certification authority; these messages are called digital certificates. the digital certificates, in turn contain other public keys that can be used in authenticating messages from directly communicating entities. the original PKI and digital ceritificate design point is the letters of credit/introduction (from the sailing ship days) ... addressing first time communication between two strangers. that a large volume of email doesn't involved first time communication between two strangers that have no prior relationship ... and so one possible question is does a PKI operation ... does the little or no added value for such communication possibly offset the drastically increased amount of complexity and increased number of business processes (that also contribute to possible enormous increase in potential for vulnerabilities). PKI is trying to offer some added value in first time communication between two strangers (say the bulk mailing advertising industry) ... and it is possibly acceptable the significant increase in business processes and complexity is justified in improving reliance in the bulk mailing advertising market segment. The question does the vast increase in business processes and complexity (with the possibility that the increased business processes and complexity also introduce significant new types of vulnerabilities) justify its use in the scenarios where first time communication between two strangers is not involved. This is business process analysis of what goes on in a basic public key email operation ... aka all the public key operations and the entity's trusted public key repository ... and then showing where PKI incrementally adds business processes and complexity to that basic infrastructure certification authority public keys added to the trusted public key repository, these new kind of messages called digital certificates and the indirection between the certification authority's public key (in the entity's trusted public key repository) and the public key of the other entities communicated with. The additional digital certificate verification technical steps that a PKI operation adds to a core fundamental public key email process (that directly has access to public keys of entities directly communicated with) ... also drags in the enormous amount of complexity and additional business processes that the certification authorities have to perform. It is some of this other complexity and business processes that may be attacked ... as in my oft repeated description of a crook attacking the authoritative agency that a certification authority uses for the basis of its certification, and then getting a perfectly valid certificate. The user (relying-party) then may have a perfectly valid public key for an entity that they've communicated with for years but this perfectly valid certificate (from a crook) now claims that the user must now automatically accept the crook's public key also as representing the same entity. so a traditional risk/threat analysis ... would frequently analyze the basic components ... establish a baseline threat/vulnerability profile ... and then consider what happens when additional complexity does to the baseline. I assert that a simple public key email operation can establish a baseline w/o any digital certificates ... and then you consider what happens when the baseline has digital certificates added (which then also drags in all the business process vulnerabilities that may exist at the certification authority ... and all dependencies that tthe certification authority has). we had to sort of look at this sort of stuff when we were asked to work with this small client/server startup that wanted to do payment transactions on their server http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 and we had to go arou
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Anne & Lynn Wheeler wrote: i've periodically written on security proportional to risk ... small sample http://www.garlic.com/~lynn/2001h.html#61 ... introductioin of PKI and certificates in such an environment may actually create greater vulnerabilities ... since it may convince the recipient to trust the PKI operation more than they trust their own, direct knowledge ... and the PKI operation opens up more avenues of compromise for the attackers. Regarding PKI, the X.509 idea is not just to automate the process of reliance but to do so without introducing vulnerabilities in the threat model considered in the CPS. What's a bit of a struggle, still, is that many people do not fully realize that the CPS is outside the scope of PKI. This is both a solution (makes the X.509 effort independent of local needs) and a big problem, as CAs (writers of the CPS) have the power to write almost anything they want, including their notorious DISCLAIMER (where _near_ everything of value to the subscriber is disclaimed, while _everything_ of value to the user is disclaimed). That's why its useful to compare X.509 / PKI, PGP, and IBE technologies for secure email, to know what are the trade-offs. By comparing the capabilities and faults of the secure email products per technology used, these and other problems come up in the score card. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
On Dec 7, 2005, at 10:24 PM, James A. Donald wrote: -- James A. Donald: We can, and should, compare any system with the attacks that are made upon it. As a boat should resist every probable storm, and if it does not it is a bad boat, an encryption system should resist every real threat, and if it does not it is a bad encryption system. Aram Perez I'm sorry James, but you can't expect a (several hundred dollar) rowboat to resist the same probable storm as a (million dollar) yacht. Software is cheaper than boats - the poorest man can afford the strongest encryption, but he cannot afford the strongest boat. If it is that cheap, then why are we having this discussion? Why isn't there a cheap security solution that even my mother can use? Respectfully, Aram Perez - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Ed Gerck <[EMAIL PROTECTED]> > Depends on your use. An X.509 identity cert or a PGP > cert can be made as secure as you wish to pay for. Many users are already using MUAs that check signatures. Why are phishing targets not already using signed mail? I conjecture that this is because true names don't really address the issue of true relationships. Does anyone have any market research information as to why phishing targets generally send out plain mail? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG CMjwBMx17XqegWEl4z+ZLdfTB+wFlQKrdm1516HH 4/HqDwhTaKRygswyOmR+oP41kfEhib7KJwyxDDq3p - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
"James A. Donald" <[EMAIL PROTECTED]> writes: > ... email should be sent by a direct connection from the client to > the recipient mail server, rather than this store and forward crap. This would eliminate the only available technique for strong anonymity or pseudonymity. Strong anonymity or pseudonymity cannot be achieved if there is a direct connection from the sender to the recipient because it can be traced. For strong anonymity or pseudonymity, the only available secure technology is anonymizing remailers with random latency store and forward. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- James A. Donald: > > We can, and should, compare any system with the > > attacks that are made upon it. As a boat should > > resist every probable storm, and if it does not it > > is a bad boat, an encryption system should resist > > every real threat, and if it does not it is a bad > > encryption system. Aram Perez > I'm sorry James, but you can't expect a (several > hundred dollar) rowboat to resist the same probable > storm as a (million dollar) yacht. Software is cheaper than boats - the poorest man can afford the strongest encryption, but he cannot afford the strongest boat. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /RDdl4GaftLppriBOAhXkSmzUWuV9JdpELHaG+Yq 4IZIPBnHPpNQYioKOhKdPdh6q6NwgwGDlLnbikvmA - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Ed Gerck wrote: > Depends on your use. An X.509 identity cert or a PGP cert > can be made as secure as you wish to pay for. The real > question, however, that is addressed by the paper is > how useful are they in terms of email security? How do > you compare them and which one or which product to choose > from? What are the trade-offs? i've periodically written on security proportional to risk ... small sample http://www.garlic.com/~lynn/2001h.html#61 then the issue is what security are you interested in and what are the threat models and corresponding countermeasures. in the security pain model P .. privacy A .. authentication I .. integrity N .. non-repudiation you may need authentication and integrity (say from digital signature) but not necessarily privacy/confidentiality. in normal ongoing email, there is a lot of repeated stuff and/or out-of-band stuff ... that makes certificates redundant and superfluous ... they are targeted at the letters of credit/introduction paradigm from the sailing ship days. certificates basically are representations of some certifying process performed by a certification authority. the integrity and security of the certificate itself may have absolutely nothing to do with the integrity and security of the certification business process ... minor drift in sci.crypt http://www.garlic.com/~lynn/2005u.html#9 PGP Lame question furthermore, the whole complexity and series of processes involved in a PKI-based infrastructure may have the certificates themselves totally redundant and superfluous because the recipient has numerous other indicators that they know who it is that they are dealing with. the introductioin of PKI and certificates in such an environment may actually create greater vulnerabilities ... since it may convince the recipient to trust the PKI operation more than they trust their own, direct knowledge ... and the PKI operation opens up more avenues of compromise for the attackers. ... there is even a slightly related article that i ran across yesterday: An Invitation to Steal; The more you automate your critical business processes, the more vigilant you need to be about protecting against fraud http://www.cio.com.au/index.php/id;1031341633;fp;4;fpid;18 . the other issue in digital signature based operation is that it is a part of 3-factor authentication http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are where the fundamental linchpin for the whole operation is the protection and confidentiality of the private key. unfortuantely almost all digital signature operations tend to talk about the integrity and security of the PKI operation and its certificates ... when they should be talking about the integrity and security of the private keys and the integrity and security of the digital signing environment. i've sporadically gone so far as to assert that the focus on the integrity and security of PKI and certificates results in obfuscating the fundamental integrity and security issues with private keys and digital signing environments (aka long before anybody is talking about the integrity of the certificates ... they should have resolved that the private keys are only available in hardware tokens of known and specific integrity characteristics). The whole PKI and certificate operation having a design point of resolving first time interaction between complete strangers (as in the letters of credit/introduction paradigm from sailing ship days) and should come after the basic underlying infrastructure isssues involving trusted communication between two entities has first been resolved (whether it is first time communication between complete strangers or not ... which then can be layered on top of a sound infrastructure that has its fundamental operations already resolved). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
James and Aram, thanks for your comments. My reply is inlined below. James A. Donald wrote: http://email-security.net/papers/pki-pgp-ibe.htm X.509 / PKI (Public-Key Infrastructure), PGP (Pretty Good Privacy) and IBE (Identity-Based Encryption) promise privacy and security for email. But comparing these systems has been like comparing apples with speedboats and wingbats. A speedboat is a bad apple, and so on. We can, and should, compare any system with the attacks that are made upon it. As a boat should resist every probable storm, Boats are storm rated, however. The point here is how can we "storm rate" secure email systems? For example, it might be a good idea to have different tables for attacks vs. problems (for boats: resisting pirates versus resisting high waves). For example P13 (must pre-enroll recipients) may be a problem and it really is something different compared to an attack, i.e., a problem leading to an attack such as P12 (open message headers). However, in order to make some progress in this, I felt a need to simplify things into + and -. This makes sense also in terms of attacks vs problems (for email, maybe not for boats!) because a secure email system that has a lot of problems will likely be used badly (insecurely) or not at all -- which opens room for attacks. So, both problems and attacks are negative for security. What I'm saying is that we can, and do in many other cases, compare different systems in terms of their features and shortcomings. Irrespectively of how we may further classify them, a feature is + and a shortcoming is -. For example, that's how your car value is estimated when you sell it -- by how many negative and positive points it gets. It doesn't matter if the negative points came from a dent or an absence of air bags, they all count negatively. I'm looking into each product individually and building a collective metric based on technologically-neutral specifications for + and -. To do this, the paper asks two questions: (1) what are the product's capabilities in terms of a list of desired features (the +), and (2) what are the product's shortcomings in terms of a list of attack/ problems (the -), for each main market product using those technologies and assigns each score (+ or -) to the technology used by that product. At the end of this algorithm, scanning enough products, we have a list of all capabilities and all shortcomings that affect each technology. Of course, each feature and problem/attack is intended as optional -- you can pick and choose what you want from the list, to make your own subset of the score card, valid for your needs (and amount of money you want to pay). These lists are an intrinsic "yardstick" that we can use to both rate each technology and also, if we want, each individual product. For example, a product that has 80% of the positive score and 20% of the negative score for that technology is possibly better than a product using the same technology that would have 20% of the positive and 80% of the negative for that technology. We can, in the same way, compare products using different technologies, comparing their score cards. Problem 1: The primary weakness of existent email is its vulnerability to after the fact investigations. For example P1: giving others the ability to get your private key at a server without your knowledge or consent. Anything we can do to negate "after the fact investigations" is useful , such as protecting the email headers (communication security, not just message security). The paper's score card reflects several aspects of this, in its positive and negative scores. Problem 2: The secondary weakness is ease of forgery. For example P1 to P8. Crap with certificate authorities or web of trust just is not flying, and is not going to fly. Depends on your use. An X.509 identity cert or a PGP cert can be made as secure as you wish to pay for. The real question, however, that is addressed by the paper is how useful are they in terms of email security? How do you compare them and which one or which product to choose from? What are the trade-offs? To limit the number of possible copies, email should be sent by a direct connection from the client to the recipient mail server, rather than this store and forward crap. Store and forward makes it reliable -- nothing needs to be 100% online 100% of the time (which is, of course, a totally improbable event). Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
Aram Perez wrote: > I'm sorry James, but you can't expect a (several hundred dollar) > rowboat to resist the same probable storm as a (million dollar) yacht. > There is no such thing as "one-size encryption system fits all cases". unfortunately there are more than a few counter-examples that are made enormously complex (and extremely expensive) and it turns out that the complexity itself introduces additional failure and threat vulnerabilities which aren't found in KISS-solutions. nearly ten years ago, i joked that i was going to take a $500 milspec part, cost reduce it by two orders of magnitude and at the same time improve its security (in part by eliminating unnecessary features that contributed to security vulnerabilities). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
On Dec 7, 2005, at 8:40 AM, James A. Donald wrote: -- From: Ed Gerck <[EMAIL PROTECTED]> Subject: X.509 / PKI, PGP, and IBE Secure Email Technologies http://email-security.net/papers/pki-pgp-ibe.htm X.509 / PKI (Public-Key Infrastructure), PGP (Pretty Good Privacy) and IBE (Identity-Based Encryption) promise privacy and security for email. But comparing these systems has been like comparing apples with speedboats and wingbats. A speedboat is a bad apple, and so on. We can, and should, compare any system with the attacks that are made upon it. As a boat should resist every probable storm, and if it does not it is a bad boat, an encryption system should resist every real threat, and if it does not it is a bad encryption system. I'm sorry James, but you can't expect a (several hundred dollar) rowboat to resist the same probable storm as a (million dollar) yacht. There is no such thing as "one-size encryption system fits all cases". Regards, Aram Perez - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
-- From: Ed Gerck <[EMAIL PROTECTED]> Subject: X.509 / PKI, PGP, and IBE Secure Email Technologies > http://email-security.net/papers/pki-pgp-ibe.htm > > X.509 / PKI (Public-Key Infrastructure), PGP (Pretty > Good Privacy) and IBE (Identity-Based Encryption) > promise privacy and security for email. But comparing > these systems has been like comparing apples with > speedboats and wingbats. A speedboat is a bad apple, > and so on. We can, and should, compare any system with the attacks that are made upon it. As a boat should resist every probable storm, and if it does not it is a bad boat, an encryption system should resist every real threat, and if it does not it is a bad encryption system. And no blaming the users. An encryption system must accommodate the user, not the user the system. Problem 1: The primary weakness of existent email is its vulnerability to after the fact investigations. Problem 2: The secondary weakness is ease of forgery. So far spammers are not making much effort to forge their way through your white lists, but phishers are forging the identities of organization's with which you are likely to have relationships. Most efforts have been directed at problem 2, but the true names approach as failed for web sites, and it is too burdensome for people even to try for email The user interface has to be a web page button "Please click here to us to send, and you to whitelist, our emails about blah blah " User clicks. Browser Chrome pops up. "Will you white list emails signed by public key YJQwlHzIzHP7nm04t3CFcrjFlMY, apparently controlled by website www.bankofadelaide.com, common name Bank of Adelaide, current favorite name /favorites/banks/Bank of Adelaide - Home - Personal, proposed petname banks/Bank of Adelaide - Home - Personal The spam filter has to pop up THE EXACT SAME BROWER CHROME, when the user tells it to whitelist a signed email that has been wrongly spam filtered. Crap with certificate authorities or web of trust just is not flying, and is not going to fly. But, of course, the really serious attack is problem 1, the problem that there are too damn many copies of email floating around, due to sending it in the clear and the store and forward architecture, which has got lots of people into really deep trouble. The only copies should be those that the sender, and the receiver, choose to keep, and they should be encrypted with the user's email passphrase, the user's email passphrase should be known only to the client, not to the server, and the user's passphrase should have all the usual strengthening to minimize the effectiveness of offline dictionary attack. To limit the number of possible copies, email should be sent by a direct connection from the client to the recipient mail server, rather than this store and forward crap. Of course this is not email as we know it. It is a new and wholly incompatible protocol, which can be transparently gatewayed to email as we know it. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG EHhbMLsVYHKM99sSClQYV0/o/XVA5PN4UrXpsU0v 4ca9QRhhmxSqwOK6ef12X8jbDKTR/AMD0r8RQzn9j - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
X.509 / PKI, PGP, and IBE Secure Email Technologies
http://email-security.net/papers/pki-pgp-ibe.htm X.509 / PKI (Public-Key Infrastructure), PGP (Pretty Good Privacy) and IBE (Identity-Based Encryption) promise privacy and security for email. But comparing these systems has been like comparing apples with speedboats and wingbats. A speedboat is a bad apple, and so on. To help develop a common yardstick, I would like feedback (also by private email) on a list of desirable secure email features as well as a list of attacks or problems, with a corresponding score card for the secure email technologies X.509 / PKI, PGP and IBE. The paper is at http://email-security.net/papers/pki-pgp-ibe.htm Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
