Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust
On 2014-05-05, at 1:12 PM, pjklau...@gmail.com pjklau...@gmail.com wrote: -Original Message- From: Jeffrey Goldberg [mailto:jeff...@goldmark.org] Just because you are talking to the right IP address doesn't mean you are talking the right host. You're right yes ( I did forget :), but if a DNS can somehow guarantee a correct hostname-IPAddress mapping, then it can also guarantee a correct hostname-public key ( or self signed certificate) mapping. Ah. OK. Thanks for spelling that out for me. Now it makes sense. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust
On 2014-05-03, at 3:22 AM, pjklau...@gmail.com pjklau...@gmail.com wrote: Frankly, if we could trust in DNS, we would not need to trust in web-PKIX [2] - since the one is just the bandaid for the other. Have you forgotten that routing can be subverted? Just because you are talking to the right IP address doesn’t mean you are talking the right host. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust
On May 4, 2014, at 6:39 PM, Jeffrey Goldberg jeff...@goldmark.org wrote: On 2014-05-03, at 3:22 AM, pjklau...@gmail.com pjklau...@gmail.com wrote: Frankly, if we could trust in DNS, we would not need to trust in web-PKIX [2] - since the one is just the bandaid for the other. Have you forgotten that routing can be subverted? Just because you are talking to the right IP address doesn’t mean you are talking the right host. That is why signatures exist. With DNSChain and DNSCrypt, for example, you will know whether you're talking to the right host, and no IP-based routing or filtering can affect that. Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust
In article eb40b06c-907f-42ee-be88-45361561e...@goldmark.org you write: On 2014-05-03, at 3:22 AM, pjklau...@gmail.com pjklau...@gmail.com wrote: Frankly, if we could trust in DNS, we would not need to trust in web-PKIX [2] - since the one is just the bandaid for the other. Have you forgotten that routing can be subverted? Just because you are talking to the right IP address doesn�t mean you are talking the right host. Sure, but if the cert it presents has the hash in the DNSSEC signed DANE record, it does. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust
Since we're on the subject of X509 history, I found Dr. Ed Gercks Definition of Trust at [1] very helpful in really figuring out what trust can mean. This work was done fairly early on the X509 timeline. Frankly, if we could trust in DNS, we would not need to trust in web-PKIX [2] - since the one is just the bandaid for the other. Therefore I support any alternative DNS mechanisms (Namecoin?) which could eventually make it into the mainstream. quoting Gerck... The provided trust definition leads to several consequences... 1) trust depends on the observer -- or, there is no absolute trust. What you may know can differ from what I may know. 2) trust only exists as self-trust. This means that only self-trust has zero information content, so trust on others always have information content (surprises or, unexpected behavior, either good or bad). 3) two different observers cannot equally trust any received information. Direct consequence of (1) and (2). 4) a self-declaration cannot convey trust to another entity when using one and the same communication channel. Direct consequence of the abstract definition. [1] http://mcwg.org/mcg-mirror/trustdef.htm [2] http://pjklauser.wordpress.com/2013/12/03/pkix-for-webserver-ssl-certificate s-will-eventually-die/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson - the definition of trust
On May 3, 2014, at 3:22 AM, pjklau...@gmail.com wrote: Frankly, if we could trust in DNS, we would not need to trust in web-PKIX [2] - since the one is just the bandaid for the other. Therefore I support any alternative DNS mechanisms (Namecoin?) which could eventually make it into the mainstream. That is precisely what we're working on with DNSChain, a project that combines DNS with the blockchain (any blockchain, and Namecoin specifically is supported): https://github.com/okTurtles/dnschain Yesterday we released 0.2.0, our 5th/6th release (0.2.1 is the same thing, just forgot to bump the NPM version string). This project represents as close to a practical form of self-trust as I'm aware of. It represents a flat P2P network topology, as opposed to a hierarchical one (like canonical DNS), that's based on the blockchain. Its last remaining problem is a solid solution to the 51% problem. The Ethereum project has proposed some interesting ones. There's also interesting discussion going on within the BitShares community. Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2/05/2014 06:41 am, Jeffrey Goldberg wrote: On 2014-05-01, at 8:49 PM, ianG i...@iang.org wrote: On 1/05/2014 02:54 am, Jeffrey Goldberg wrote: On 2014-04-30, at 6:36 AM, ianG i...@iang.org wrote: OK. So let me back peddle on “Ann trusts her browser to maintain a list of trustworthy CAs” and replace that with “Ann trusts her browser to do the right thing”. Right, with that caveat about choice. I think that we are in fierce agreement. At first I didn’t understand the significance of your insistence on *choice*, but I see it now. More below. I think the point of choice or competition comes down to feedback loops for improvement. There's no way to improve the situation, without a feedback loop. If we had used some system of continuous improvement since 1994 then the model might have been ready for the shift into phishing in 2003 and the threat ramp-up in 2011. We didn't, and we weren't. Dan also points at recourse which can be seen as a feedback loop. We need a way to punish those doing a bad job. Now, this was impossible with the CAs because the only punishment allowed was to drop the CA from the root list, and this was too big to work effectively. This was all known in advance, we discussed it in Mozo forum, and we actually did get some better ideas in place such as rules for dropping the CA, but still not enough to make the feedback loop work (for which we can thank CABForum, who isolated and destroyed the opportunities for feedback). In this context, we would claim that users b-trust because they know they can switch. With browsers they cannot switch. Their choice is to transmit private information using their browsers. Their choice is to not participate in e-commerce. Right, there is always in economics some form of substitute. But actually we've probably moved beyond that as a society. I would say that e-commerce is utility grade now, so it isn't a choice you can really call a choice in competition terms. I agree that the behavior in b-trust must be about “choice behavior” in that Ann behaves one way instead of another. But I don’t think that we should have some minimal threshold of choice before can call the behavior b-trust. As long as there is some non-zero amount of choice the behavior (in these cases) will exhibit a non-zero amount of trust. For me the sentence, “I had little choice but to trust X” is perfectly coherent. Yes, that still works. It is when it goes to no choice that it fails. For example, I have no choice but to use my browser for online banking. I'm too far from a branch, and their phone service is mostly about telling me how to use the browser. Is it possible that you are letting your righteous anger at what browser vendors have done interfere with how you are defining “trust”? Indeed, this is always possible. If you ask anyone at the vendors, I'm sure they'll dismiss it all as righteous anger, and why doesn't he just write patches instead? There is a curious parallel with web-PKI in the Wall Street / financial crisis. You have there a dominating cartel of huge players that successfully changed the rules to suit themselves (dropping of Glass-Steagall) purchasing of the regulators (revolving doors) and riding the wave of an innovation (securitization) all the way to doom. Now if you look at it in a structural sense, the debt overhang has broken the strength of the banking system. It's in deadly embrace; banks won't let the regulators or the prosecutors or the public do anything to clear out the debris, so here we sit, in the middle of a Japan-style lost decade. It's uncanny. Practically every structural element is the same between web-PKI and wall street. And, lots of righteous anger too... http://www.nytimes.com/2014/05/04/magazine/only-one-top-banker-jail-financial-crisis.html All I’m asking is that we consider the people we are asking to “b-trust” the system. Can we build a system that is b-trustworthy for the mass of individuals who are not going to make c-trust judgements. Right, this is the question, how do we do that? That is what Certificate Transparency and Perspectives seek to do, as well as other thoughts. First they make the c-trust available by setting up alternate groups and paths. Then the c-trusters develop their followings of b-trusters. I agree with that last bit. In a sense, if people see that experts trust the system they will too. But how will this play out with Certificate Transparency for most users? What do they actually need to know and do to follow some c-trusters? Most users will follow the c-trust shipped with their browsers. There likely needs to be a group of c-trusters in the middle that mediate the trust of the b-trusters. And how will that work without putting unrealistic expectations on the vast major of users. How do they pick which c-trusters to trust? If the system is put in place to allow a variation to be set up, then I suspect the
Re: [cryptography] Request - PKI/CA History Lesson
On 05/01/2014 10:25 AM, Ben Laurie wrote: On 1 May 2014 08:19, James A. Donald jam...@echeque.com wrote: On 2014-04-30 02:14, Jeffrey Goldberg wrote: On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? Ann should be logging on by zero knowledge password protocol, so that the entity that she logs on to proves it already knows the hash of her password. EXACTLY!!! ZKPP has to be in the browser chrome, not on the browser web page. This seems obvious, but experiments show users do not understand it. We have yet to find a satisfactory answer to a trusted path for ordinary users. So where it really mattered we got two-factor authentication (by mobile phone) instead. I like the trade-off. Using another untrusted path on a different network and machine for a probabilistic guarantee seems more reasonable to me than trying to build a trusted path on a single machine, which was ambitious at the best of times, before we knew for a fact that we can not trust a single embedded integrated circuit in any device in the world. And that is not even considering the usability and accessibility issues of all the fancy trusted path solutions that I've seen. Security researchers can not even guarantee that the status light of the camera is on when it is recording images. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2/05/2014 13:06 pm, Marcus Brinkmann wrote: On 05/01/2014 10:25 AM, Ben Laurie wrote: On 1 May 2014 08:19, James A. Donald jam...@echeque.com wrote: On 2014-04-30 02:14, Jeffrey Goldberg wrote: On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? Ann should be logging on by zero knowledge password protocol, so that the entity that she logs on to proves it already knows the hash of her password. EXACTLY!!! ZKPP has to be in the browser chrome, not on the browser web page. This seems obvious, but experiments show users do not understand it. We have yet to find a satisfactory answer to a trusted path for ordinary users. So where it really mattered we got two-factor authentication (by mobile phone) instead. Right, the European solution, send the Tx to the phone by SMS and get the user to type in a code that authenticates that Tx only. Pop quiz: does the SMS/Tx system still work if we strip HTTPS off the browser? I like the trade-off. Using another untrusted path on a different network and machine for a probabilistic guarantee seems more reasonable to me than trying to build a trusted path on a single machine, which was ambitious at the best of times, before we knew for a fact that we can not trust a single embedded integrated circuit in any device in the world. And that is not even considering the usability and accessibility issues of all the fancy trusted path solutions that I've seen. Security researchers can not even guarantee that the status light of the camera is on when it is recording images. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 05/02/2014 01:33 PM, ianG wrote: For me the sentence, “I had little choice but to trust X” is perfectly coherent. Yes, that still works. It is when it goes to no choice that it fails. For example, I have no choice but to use my browser for online banking. I'm too far from a branch, and their phone service is mostly about telling me how to use the browser. We must live in very different parts of the world, though. In Germany, if I am doing online-banking, I have to follow the rules set by the bank. The bank requires me not to pass the PIN to anybody, to check the browser status bar, to protect my TAN list, etc. All that good stuff. But I don't have to trust it. When I follow the rules, and my money is stolen, the bank has to put up for it. I am in the clear (minus the paperwork). So, I don't have to trust it, I just have to use it as it is provided to me. Moral dilemma avoided. For the bank, the story is a different one altogether. They don't care about IT security, or security research, or PKI, or CA, or browsers, or the users, or the meaning of the word trust. They care about profit margins and fraud quota, and if the fraud gets too much they ask a simple question: What can we do that costs us as little as possible to get the fraud quote down to the X percent that we allow? And if that means bumping the key size from 1024 to 1025 bits, then we get 1025 bits until the next bump. So, frankly, what's the big deal? We have credible end-to-end security story lines if your life depends on it (ask Snowden). For everything else, we have a bunch of patchworks, and insurances, and adjustable tolerances to protect against fraud. Not absolutely, but enough to keep the machine running. From a manager perspective, all is good and dandy, and nevermind the pain that is endured by the workers in the engine room. As long as you live in a country that makes the people responsible for the system pay for any damages, it's just not that big a deal, unless you are passionate about IT security, or are suffering from some other illness to similar effect :). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2/05/2014 13:42 pm, Marcus Brinkmann wrote: On 05/02/2014 01:33 PM, ianG wrote: For me the sentence, “I had little choice but to trust X” is perfectly coherent. Yes, that still works. It is when it goes to no choice that it fails. For example, I have no choice but to use my browser for online banking. I'm too far from a branch, and their phone service is mostly about telling me how to use the browser. We must live in very different parts of the world, though. We do. But to some extent it is a constructed example. Point being that choice is not always there, and it's not always easy to isolate quite whether choice is sufficient or not. Which means it is easy to manipulate. Which means that if you are in Germany, it probably makes little sense. Whereas if you are in US of A, it probably is a done deal that the bank is trying to manipulate you to be stuck in an unfair deal. In Germany, if I am doing online-banking, I have to follow the rules set by the bank. The bank requires me not to pass the PIN to anybody, to check the browser status bar, to protect my TAN list, etc. All that good stuff. But I don't have to trust it. When I follow the rules, and my money is stolen, the bank has to put up for it. I am in the clear (minus the paperwork). So, I don't have to trust it, I just have to use it as it is provided to me. Moral dilemma avoided. You have recourse, right? In UK, there is a case where the bank checked a transaction, and discovered that the person trying to make a transaction (buying a rolex in a jeweler's shop) provided unsure answers to the questions. E.g., in answer to how long have you had the account? he answered all my life. The correct answer was 4 years. The bank let the transaction happen, it was fraud. The judge and the appeal court both ruled the bank had done the right thing. http://financialcryptography.com/mt/archives/001478.html So yeah, people live in different worlds. For the bank, the story is a different one altogether. They don't care about IT security, or security research, or PKI, or CA, or browsers, or the users, or the meaning of the word trust. They care about profit margins and fraud quota, and if the fraud gets too much they ask a simple question: What can we do that costs us as little as possible to get the fraud quote down to the X percent that we allow? And if that means bumping the key size from 1024 to 1025 bits, then we get 1025 bits until the next bump. So, frankly, what's the big deal? I was there when the MITB thing swept through the European banking scene. There was outright fear in the banks. They were terrified. But in the end, they knuckled down and pushed out the two-factor thing that you mentioned earlier. http://financialcryptography.com/mt/archives/000758.html The point is: *the European banks responded*. They have a feedback loop. They took responsibility. E.g. (2), there is no phishing in Europe, more or less. Why is that? Over in USA, no such. That's the big deal. Where is web-PKI done? In the USA, according to USA rules, USA thinking, and USA-style liability dumping. We have credible end-to-end security story lines if your life depends on it (ask Snowden). For everything else, we have a bunch of patchworks, and insurances, and adjustable tolerances to protect against fraud. Not absolutely, but enough to keep the machine running. From a manager perspective, all is good and dandy, and nevermind the pain that is endured by the workers in the engine room. As long as you live in a country that makes the people responsible for the system pay for any damages, it's just not that big a deal, That point, right there. unless you are passionate about IT security, or are suffering from some other illness to similar effect :). :) iang ps; by Europe, I mean the geographically connected part, not the fogginess over the channel. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-04-30 02:14, Jeffrey Goldberg wrote: On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? Ann should be logging on by zero knowledge password protocol, so that the entity that she logs on to proves it already knows the hash of her password. ZKPP has to be in the browser chrome, not on the browser web page. How do you see that working assuming that Ann is an �ordinary user�? To the ordinary user, should not behave any different, and should only look different in that the ZKPP login screen looks different from any possible web page in a way that is quite difficult to fake for any software that does not already have total control of the users machine. Details of how to achieve unfakeable logon screen appearance depend on OS version. To make the ZKPP logon screen in Windows 7 different from any possible web page, have the browser web page vanish when the browser's genuine ZKPP logon screen is up. Analogous but different gimmicks are feasible in other operating systems and system versions. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 1 May 2014 08:19, James A. Donald jam...@echeque.com wrote: On 2014-04-30 02:14, Jeffrey Goldberg wrote: On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? Ann should be logging on by zero knowledge password protocol, so that the entity that she logs on to proves it already knows the hash of her password. EXACTLY!!! ZKPP has to be in the browser chrome, not on the browser web page. This seems obvious, but experiments show users do not understand it. We have yet to find a satisfactory answer to a trusted path for ordinary users. How do you see that working assuming that Ann is an �ordinary user�? To the ordinary user, should not behave any different, and should only look different in that the ZKPP login screen looks different from any possible web page in a way that is quite difficult to fake for any software that does not already have total control of the users machine. Details of how to achieve unfakeable logon screen appearance depend on OS version. To make the ZKPP logon screen in Windows 7 different from any possible web page, have the browser web page vanish when the browser's genuine ZKPP logon screen is up. Analogous but different gimmicks are feasible in other operating systems and system versions. Once more: technically unfakeable turns out to be a long way from usably unfakeable. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Thu, May 1, 2014 at 1:25 AM, Ben Laurie b...@links.org wrote: On 1 May 2014 08:19, James A. Donald jam...@echeque.com wrote: On 2014-04-30 02:14, Jeffrey Goldberg wrote: On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? Ann should be logging on by zero knowledge password protocol, so that the entity that she logs on to proves it already knows the hash of her password. EXACTLY!!! ZKPP has to be in the browser chrome, not on the browser web page. This seems obvious, but experiments show users do not understand it. We have yet to find a satisfactory answer to a trusted path for ordinary users. How do you see that working assuming that Ann is an �ordinary user�? To the ordinary user, should not behave any different, and should only look different in that the ZKPP login screen looks different from any possible web page in a way that is quite difficult to fake for any software that does not already have total control of the users machine. Details of how to achieve unfakeable logon screen appearance depend on OS version. To make the ZKPP logon screen in Windows 7 different from any possible web page, have the browser web page vanish when the browser's genuine ZKPP logon screen is up. Analogous but different gimmicks are feasible in other operating systems and system versions. Once more: technically unfakeable turns out to be a long way from usably unfakeable. And remember that on tablet and mobile devices the foreground program, without the user ever clicking maximize/full screen like on a desktop/laptop OS, has control of every pixel on the screen and do whatever it damned well pleases. -David Mercer ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson]
[actually to the list this time...] ZKPP has to be in the browser chrome, not on the browser web page. This seems obvious, but experiments show users do not understand it. We have yet to find a satisfactory answer to a trusted path for ordinary users. [some thoughts first, real question at the end] While not itself a full solution, it seems to me like this really needs to be integrated into the OS (although I think these same basic ideas could be applied at the application level as well, just less reliably). It seems to me that the only time a password should be used at all is user login; after that, the OS should generate random certificates to use for authentication and multiple identities should require using multiple user accounts. The login password itself should be useless without data not available to the logged in user, so that the trused path must be used to switch users and there would be no su(do) or click yes to use administrator privileges. Most users don't need remote login of arbitrary users, so (with some disk encryption) this would at least leave phish-and-steal-the-device as the possible user-level attack vector (of course, in many cases just stealing credentials would be easier and more valuable but with the user not directly interacting with credentials this would mostly mean remote code execution). If changing users is a necessary part of using the system and it only works if you do it right, users will necessarily learn to use the trusted path and the chance of phishing would hopefully be minimal. New logins should start from the configured system state rather than restoring state to prevent look like you entered your password wrong phishing (this startup state would need to be only configurable external to the particular user, from a system management account). Then make it easy to configure user accounts to do particular tasks, such as start a browser that connects to your bank and logs you in. To the extent that you want to separate remote credentials from each other, you would do that via separate local accounts. System management should make it possible to share or move credentials between user accounts (copy too for advanced users). This still leaves a few issues: to make it workable, there needs to be some method of multiple simultaneous logins with user switching, which could then be subject to phishing. Sessions could be detached with a single console user and a simple command/action to connect to the detached session after login, which goes to the default setup that confirms you logged in correctly. For most users, this could just be the system displaying login successful with some time delay (and cute animation) before restoring the session. Also the algorithms used would need to be local cross user (timing attack, etc.) safe. The main reson I can think of to want to be able to directly login to a remote system with a password you can remember is to be able to access an account via a random (but hopefully presumed to be trustworthy) system using only the contents of your memory. There are various options here but for now I'll leave it at saying that this is something that users often want to be able to do so there should be some way to do it but IMO it shouldn't usually be the default much less only option. Users should generally not need to do more than say yes, I want to create authenticaiton credentials with this site (with the option to bootstrap with externally provided credentials that might have e.g. been paper mailed to the user, which I suppose is another use case of passwords the user can enter reasonably easily). The credentials themselves would be stored by the OS not the particular application (but might be tagged to be for a particular application). Anyway, those are my thoughts but I mostly wanted to ask if there is a particular well described, patent free, and ready to implement (considered safe) ZKPP + PAKE system that folks would recommend? Are there significant issues beyond tradition that has prevented wider adoption? Why wasn't SRP more widely used? -Matt ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-05-01, at 8:49 PM, ianG i...@iang.org wrote: On 1/05/2014 02:54 am, Jeffrey Goldberg wrote: On 2014-04-30, at 6:36 AM, ianG i...@iang.org wrote: OK. So let me back peddle on “Ann trusts her browser to maintain a list of trustworthy CAs” and replace that with “Ann trusts her browser to do the right thing”. Right, with that caveat about choice. I think that we are in fierce agreement. At first I didn’t understand the significance of your insistence on *choice*, but I see it now. More below. In this context, we would claim that users b-trust because they know they can switch. With browsers they cannot switch. Their choice is to transmit private information using their browsers. Their choice is to not participate in e-commerce. Right, there is always in economics some form of substitute. But actually we've probably moved beyond that as a society. I would say that e-commerce is utility grade now, so it isn't a choice you can really call a choice in competition terms. I agree that the behavior in b-trust must be about “choice behavior” in that Ann behaves one way instead of another. But I don’t think that we should have some minimal threshold of choice before can call the behavior b-trust. As long as there is some non-zero amount of choice the behavior (in these cases) will exhibit a non-zero amount of trust. For me the sentence, “I had little choice but to trust X” is perfectly coherent. Is it possible that you are letting your righteous anger at what browser vendors have done interfere with how you are defining “trust”? All I’m asking is that we consider the people we are asking to “b-trust” the system. Can we build a system that is b-trustworthy for the mass of individuals who are not going to make c-trust judgements. Right, this is the question, how do we do that? That is what Certificate Transparency and Perspectives seek to do, as well as other thoughts. First they make the c-trust available by setting up alternate groups and paths. Then the c-trusters develop their followings of b-trusters. I agree with that last bit. In a sense, if people see that experts trust the system they will too. But how will this play out with Certificate Transparency for most users? What do they actually need to know and do to follow some c-trusters? There likely needs to be a group of c-trusters in the middle that mediate the trust of the b-trusters. And how will that work without putting unrealistic expectations on the vast major of users. How do they pick which c-trusters to trust? I think that we have a higher chance of success if we use a language that can talk about agents who do not have a deep or accurate understanding of why a system is supposed to work. And so, I think that, with some refinement, my notion of b-trust is worthwhile. Yes it could be. It might not be applicable to web-PKI because the vendors confuse X do the right thing by users with X' maintain a good CA list.” I’m confused. (Perhaps by the vendors?) Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
For me the sentence, “I had little choice but to trust X” is perfectly coherent. Is it possible that you are letting your righteous anger at what browser vendors have done interfere with how you are defining “trust”? That's the question with the elusive answer: how do you define trust. One of the better answers I have seen: X trust Y to do Z. Plug in PKI: Users trust CAs to abide by their CP and CPS. (Now policy (CP) and procedures (CPS) need to be accepted). Nonsensical counter example: Trustwave did not follow their CP, but they are still trusted. Does not compute... Jeff On Fri, May 2, 2014 at 1:41 AM, Jeffrey Goldberg jeff...@goldmark.org wrote: On 2014-05-01, at 8:49 PM, ianG i...@iang.org wrote: On 1/05/2014 02:54 am, Jeffrey Goldberg wrote: On 2014-04-30, at 6:36 AM, ianG i...@iang.org wrote: OK. So let me back peddle on “Ann trusts her browser to maintain a list of trustworthy CAs” and replace that with “Ann trusts her browser to do the right thing”. Right, with that caveat about choice. I think that we are in fierce agreement. At first I didn’t understand the significance of your insistence on *choice*, but I see it now. More below. In this context, we would claim that users b-trust because they know they can switch. With browsers they cannot switch. Their choice is to transmit private information using their browsers. Their choice is to not participate in e-commerce. Right, there is always in economics some form of substitute. But actually we've probably moved beyond that as a society. I would say that e-commerce is utility grade now, so it isn't a choice you can really call a choice in competition terms. I agree that the behavior in b-trust must be about “choice behavior” in that Ann behaves one way instead of another. But I don’t think that we should have some minimal threshold of choice before can call the behavior b-trust. As long as there is some non-zero amount of choice the behavior (in these cases) will exhibit a non-zero amount of trust. For me the sentence, “I had little choice but to trust X” is perfectly coherent. Is it possible that you are letting your righteous anger at what browser vendors have done interfere with how you are defining “trust”? All I’m asking is that we consider the people we are asking to “b-trust” the system. Can we build a system that is b-trustworthy for the mass of individuals who are not going to make c-trust judgements. Right, this is the question, how do we do that? That is what Certificate Transparency and Perspectives seek to do, as well as other thoughts. First they make the c-trust available by setting up alternate groups and paths. Then the c-trusters develop their followings of b-trusters. I agree with that last bit. In a sense, if people see that experts trust the system they will too. But how will this play out with Certificate Transparency for most users? What do they actually need to know and do to follow some c-trusters? There likely needs to be a group of c-trusters in the middle that mediate the trust of the b-trusters. And how will that work without putting unrealistic expectations on the vast major of users. How do they pick which c-trusters to trust? I think that we have a higher chance of success if we use a language that can talk about agents who do not have a deep or accurate understanding of why a system is supposed to work. And so, I think that, with some refinement, my notion of b-trust is worthwhile. Yes it could be. It might not be applicable to web-PKI because the vendors confuse X do the right thing by users with X' maintain a good CA list.” I’m confused. (Perhaps by the vendors?) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
As is so often found, there are multiple nuanced definitions of a word, trust being the word in the current case. Simply as a personal definition, trust is that state wherein I accept assertions at face value and do so because I have effective recourse should having let my guard down later prove to have been unwise. Restated as logic, If I can trust, then I have effective recourse. and in contrapositive If I have no effective recourse, then I cannot trust. YMMV, --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 30/04/2014 02:57 am, Jeffrey Goldberg wrote:
Hi Ian,
I will just respond to one of the many excellent points you’ve made.
Super, thanks!
On 2014-04-29, at 12:12 PM, ianG i...@iang.org wrote:
On 29/04/2014 17:14 pm, Jeffrey Goldberg wrote:
People do trust their browsers and OSes to maintain a list of trustworthy
CAs.
No they don't. Again, you are taking the words from the sold-model.
I will explain my words below.
People don't have a clue what a trustworthy CA is, in general.
I emphatically agree with you. I hadn’t meant to imply otherwise.
I have been using “trust” in a sort of behavioral way. For the sake of the
next few sentences, I’m going to introduce some terrible terminology.
“b-trust” is my “behavioral trust” which will defined in terms of “c-trust”
(“cognitive”).
So let’s say that A c-trusts B wrt to X when A is confident that B will act
in way X. (Cut me some slack on “act”). A “b-trusts” B wrt to X when she
behaves as if she c-trusts B wrt to X.
So when I say that users trust their browsers to maintain a list of
trustworthy CAs, I am speaking of “b-trust”. They may have no conscious idea
or understanding what they are actually trusting or why it is (or isn’t)
worthy of their trust. But they *behave* this way.
Right, but this is very dangerous. You have migrated the meaning of X
in the conversation.
Users trust their browsers to do the right thing by security.
Browsers trust their CAs to do the right thing by their ID verification.
This does not mean that users trust their browsers to maintain a list of
trustworthy CAs.
Trusting the browsers to do the right thing also includes the
possibility that the browsers throw the lot out and start again. Or
drop some CAs from the list, which they only do with small weak players
that won't sue them.
Also, one has to again refer to the nature of trust. It's a
choice-based decision. Trust is always founded on an ultimate choice.
In this context, we would claim that users b-trust because they know
they can switch. With browsers they cannot switch. There isn't a
browser that will offer a different model (they cartelised in 1994,
basically). And there isn't a browser vendor that will take user input
on this question.
So there is no choice for the user. Therefore, we need a new form;
m-trust perhaps? Mandated-trust? I don't know how far we want to go
into the doublespeak to interpret this, point being that m-trust
excludes {b,c}-trust by its nature.
Also, if you asked users whether they trust the browsers to secure their
connections to the online banks, then I'd reckon you'd have a bit more
of an uphill battle. It isn't done and users know it isn't done, thanks
to phishing. Users now use more than one browser, not because one does
a better job but because they are diversifying their risks, online
banking one one browser, the rest on another.
Which is where it gets more dangerous: we can frame the question to
gain the answer we want; but who are we framing the result for ?
A vampire bat may b-trust that its rook mates will give it a warm meal if
necessary. Life is filled with such trust relations even where there is no
c-trust.
Yes, and a vampire bat may choose which mate to get the meal from; it
has choice.
(c.f., the *real meaning of trust* being a human decision to take a risk
on available information.)
Which is what I am talking about. And I’m talking about it because it is what
matters for
human behavior. And I want a system that works for humans.
I see that you’ve written on financial cryptography. Well think about
conventional currency works. For all its problems currency works, and it is a
system that requires “trust”. But only a negligible fraction of the people
who successfully use the system do so through c-trust.
Right. Now add in hyperinflation to the mix; how many people really
trust their governments to not hyperinflate? Only ones with no
collective history of it.
It may well be that all of the problems with TLS are because the system is
trying to work for agents who don’t understand how the system works. But, as
I said at the beginning, that is the world we are living in.
Right, we're certainly in the world we are in. However, the problem
with this particular world is that it uses a language that is
'constructed' to appear to require this particular solution. In order
to find better solutions we have to unconstruct the constructions in the
language, so as to see what else is possible.
iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 04/30/2014 02:59 PM, d...@geer.org wrote: As is so often found, there are multiple nuanced definitions of a word, trust being the word in the current case. Simply as a personal definition, trust is that state wherein I accept assertions at face value and do so because I have effective recourse should having let my guard down later prove to have been unwise. Restated as logic, If I can trust, then I have effective recourse. and in contrapositive If I have no effective recourse, then I cannot trust. That's funny, because by far the most prevalent definition of trusted systems are those whose failure can break your security policy. They must be trusted, because they are the last line of defense. If you have effective recourse, then by that definition trust is not required. Think about the trust fall game that is played with children. It wouldn't be the same with a mattress. So, trust is something that you end up stuck with once you remove everything you don't have to trust. Trustworthiness on the other hand is something that can be established, for example by introduction (usually appealing to a higher authority), formal verification (requires transparency), or experience (at best probabilistic guarantees). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Wed, Apr 30, 2014 at 10:07 AM, Marcus Brinkmann marcus.brinkm...@ruhr-uni-bochum.de wrote: On 04/30/2014 02:59 PM, d...@geer.org wrote: As is so often found, there are multiple nuanced definitions of a word, trust being the word in the current case. Simply as a personal definition, trust is that state wherein I accept assertions at face value and do so because I have effective recourse should having let my guard down later prove to have been unwise. Restated as logic, If I can trust, then I have effective recourse. and in contrapositive If I have no effective recourse, then I cannot trust. ... If you have effective recourse, then by that definition trust is not required. Exactly. Trust is what is used when you don't have a security control to place. Or won't place... Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
M If you have effective recourse, then by that definition trust is not M required. J Exactly. J J Trust is what is used when you don't have a security control to place. Well, if nothing else, we now have proof by demonstration that the greater we do not agree on the meaning of trust hence, one might conclude, group-rating the trustworthiness of various options should now pause. --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-04-30, at 6:36 AM, ianG i...@iang.org wrote: On 30/04/2014 02:57 am, Jeffrey Goldberg wrote: I have been using “trust” in a sort of behavioral way. For the sake of the next few sentences, I’m going to introduce some terrible terminology. “b-trust” is my “behavioral trust” which will defined in terms of “c-trust” (“cognitive”). So let’s say that A c-trusts B wrt to X when A is confident that B will act in way X. (Cut me some slack on “act”). A “b-trusts” B wrt to X when she behaves as if she c-trusts B wrt to X. So when I say that users trust their browsers to maintain a list of trustworthy CAs, I am speaking of “b-trust”. They may have no conscious idea or understanding what they are actually trusting or why it is (or isn’t) worthy of their trust. But they *behave* this way. Right, but this is very dangerous. You have migrated the meaning of X in the conversation. Users trust their browsers to do the right thing by security. Browsers trust their CAs to do the right thing by their ID verification. This does not mean that users trust their browsers to maintain a list of trustworthy CAs. OK. So let me back peddle on “Ann trusts her browser to maintain a list of trustworthy CAs” and replace that with “Ann trusts her browser to do the right thing”. Trusting the browsers to do the right thing also includes the possibility that the browsers throw the lot out and start again. Or drop some CAs from the list, which they only do with small weak players that won't sue them. I am not saying that her trust is justified. Also, one has to again refer to the nature of trust. It's a choice-based decision. Trust is always founded on an ultimate choice. In this context, we would claim that users b-trust because they know they can switch. With browsers they cannot switch. Their choice is to transmit private information using their browsers. Sure, you and I know that what protects most people from credit card fraud has nothing to do with browsers, and all has to do with regulations of the liability. But I’ve encountered plenty of people over the last few weeks who have said that they will stop using their credit cards on-line because of heartbleed, while they continue to use entirely unprotected email for things that are genuinely sensitive. Their choice is to not participate in e-commerce. There isn't a browser that will offer a different model (they cartelised in 1994, basically). And there isn't a browser vendor that will take user input on this question. Again, I’m not saying that the trust that the browser will do the right thing is justified. But the ordinary users isn’t going to curate their own list of CAs. Even the extraordinary user is only going to tinker with these under rare circumstances. (Indeed, a bug in Apple’s trust chain logic was only discovered when individual users chose to distrust DigiNotar and found that things didn’t work as documented.) So there is no choice for the user. Again, people can chose to not participate in the system. It is a choice that has a high cost. But because the alternative to trusting the browser to do the right thing is costly, it means that people will lower their threshold. Which is where it gets more dangerous: we can frame the question to gain the answer we want; but who are we framing the result for ? All I’m asking is that we consider the people we are asking to “b-trust” the system. Can we build a system that is b-trustworthy for the mass of individuals who are not going to make c-trust judgements. I see that you’ve written on financial cryptography. Well think about conventional currency works. For all its problems currency works, and it is a system that requires “trust”. But only a negligible fraction of the people who successfully use the system do so through c-trust. Right. Now add in hyperinflation to the mix; how many people really trust their governments to not hyperinflate? Only ones with no collective history of it. Again, the point of that example was not to claim that people always put the appropriate amount of b-trust into a system, but simply that the on a day to day basis we all behave “as if” we trust things in the c-trust sense without that understanding. Or are you saying that we should insist that everyone develop a full and proper understanding of the system before using it? I think we should recognize that the vast majority of humanity are not as intensely curious about the particular things that we in this discussion are curious about. I also think that they shouldn’t be excluded from secure communication because of that. Right, we're certainly in the world we are in. However, the problem with this particular world is that it uses a language that is 'constructed' to appear to require this particular solution. In order to find better solutions we have to unconstruct the constructions in the language, so as to see what else is possible. I
Re: [cryptography] Request - PKI/CA History Lesson
the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. because that's the only use of certificates right? to protect against man in the middle? On Mon, Apr 28, 2014 at 6:25 PM, Jason Iannone jason.iann...@gmail.comwrote: If browsers are defeating the purpose of the chain of trust, by forcing trust in this example, why design them to freak out when a site self signs? On Apr 28, 2014 6:32 PM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Apr 28, 2014 at 8:20 PM, Ryan Carboni rya...@gmail.com wrote: One can always start with the difficult first step of uninstalling certificate authorities you do not trust. Opera will autorepair damage to the certificate repository, a missing Certificate Authority is considered damage. Opera ships with a list of frequently used certificates, and if any of these are missing they will be added the next time the repository is read from disk. Other certificates will be added from the online repository as needed. - http://my.opera.com/community/forums/topic.dml?id=1580452 Its not just Opera. Others are using similar innovative methods to reduce the support load and costs. Jeff On Mon, Apr 28, 2014 at 4:42 PM, ianG i...@iang.org wrote: On 29/04/2014 00:12 am, Ryan Carboni wrote: trust is outsourced all the time in the non-cryptographic world trust is built up all the time, risks are taken all the time, choice is taken all the time. unless you do not have a bank account That's not outsourced, that's direct, person to bank, the person has a choice, chooses to place her trust in that bank. Also, it is limited to defined things that are required, can't be done by the person, and bolstered by real backing such as FIDC. When you suggest it's probably best we trust authorities that is CA-playbook crapola meaning you must trust the authorities that have been picked for you. The vector has been reversed, people are told what has to happen, so there is no trust. Trust derives from choice. Where is the choice? On Mon, Apr 28, 2014 at 3:00 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: On 2014-04-29 05:58, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, however we find that diverse entities have very similar names, and a single entity may have many names. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 28/04/2014 23:00, James A. Donald wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, they are certifying they sold a certificate to someone that had Bob on it. Even for EV certificates, that isn't hard to do, even if you are actually Kevin. On 29/04/2014 02:25, Jason Iannone wrote: If browsers are defeating the purpose of the chain of trust, by forcing trust in this example, why design them to freak out when a site self signs? Mostly the value of the delusion in getting people to do things they wouldn't do on an insecure site. Getting a CA cert is more about the feelgood factor of they have a verified cert, so I can trust them than anything they can really assert given the body of evidence pointing to the real case of they have a verified cert, so clearly had a CC on hand with enough credit to buy a cert. This CC may even have been theirs - however, provided the vast majority of people believe it to be true, it is nearly as good as *being* true for commercial entities (and of course for the CAs) Most users wouldn't know what to do to verify a thumbprint, even if it were printed on the back of their debit card, but would just click OK regardless. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 29/04/2014 07:41 am, Ryan Carboni wrote: the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. because that's the only use of certificates right? Well. Certificates define their MITM as being the sort they can protect against, sure. to protect against man in the middle? Certs don't defend against *the MITM*, they only defend against _their MITM_. Subtle different, the MITM known as phishing is more or less unprotected. What to make of this? Security economics: there is zero point in investing anything in a form of MITM that is known to be so rare as statistically unmeasurable, even in unprotected environments, when there is another form of MITM that has clocked up billions in measurable losses. But jobs depend on that not being true, so it isn't. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? How do you see that working assuming that Ann is an “ordinary user”? This is exactly the kind of thing I was complaining about in my earlier comment. There are burdens that we cannot push onto the user. People do trust their browsers and OSes to maintain a list of trustworthy CAs. Sure, we might have the occasional case where some people manually remove or add a CA. But for the most part, we’ve outsourced trust to the browser vendors, how have outsourced trust to various CAs, etc. I am not saying that the system isn’t fraught with series problems. I’m saying that at least it tries to work for ordinary users. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. Yes, of course. Back in the before time (1990s), I had feared that this was going to be a big problem. That people would take the take “trust the authenticity” of a message to be “trust the veracity” of the message. But as it turns out, we haven’t seen a substantially higher proportion of fraud of this nature than in meatspace. I think it is because reputations are now so fragile. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Hi Jeffrey, On 29/04/2014 17:14 pm, Jeffrey Goldberg wrote: On 2014-04-28, at 5:00 PM, James A. Donald jam...@echeque.com wrote: Cannot outsource trust Ann usually knows more about Bob than a distant authority does. So should Ann verify the fingerprints of Amazon, and Paypal herself? How do you see that working assuming that Ann is an “ordinary user”? First, do a proper security analysis; don't accept some marketing dross from the sellers of stuff. If you look at the history of web commerce, there is nothing there that supports the notion that the in-protocol MITM is a risk to be mitigated. Even if you look at close analogues, the support is not there. And, if you look at the rest of the equation -- humans, banks, stores, remember them? -- you find they don't care either. That's because they're all ready for chargebacks, and always have been so Alice has no problem, ever. She does not *ever* need to worry about fingerprints. Then, what are they worried about? Mass raids of databases, that's what. By far the #1. The next issue, way behind, is phishing, the other MITM. (Which again they do little about.) It turns out -- and early simple analysis suggested -- that an in-protocol MITM is the worst possible attack, it's daft to an extraordinary level, and only security experts ever worry about it. Conclusion? Strawman. A real security analysis reveals all this. Question then, is where did the notion that you HAVE to defend yourself form the evil in-protocol MITM? Why are we all terrified? This is exactly the kind of thing I was complaining about in my earlier comment. There are burdens that we cannot push onto the user. People do trust their browsers and OSes to maintain a list of trustworthy CAs. No they don't. Again, you are taking the words from the sold-model. People don't have a clue what a trustworthy CA is, in general. That's because the same model hid it, and is still hiding it. Have a look at amazon today -- look Ma, no CA. In sight. The day the CA is in sight, the users might care. Until then they don't know so they cannot possibly trust. (c.f., the *real meaning of trust* being a human decision to take a risk on available information.) Sure, we might have the occasional case where some people manually remove or add a CA. But for the most part, we’ve outsourced trust to the browser vendors, how have outsourced trust to various CAs, etc. We the users have done nothing of the kind. Browsers have done what they've done, and you could claim that the browsers trust the CAs. Maybe. More so these days coz they actually do something about it, in CABForum, less so before then, before Mozo policy. I am not saying that the system isn’t fraught with series problems. I’m saying that at least it tries to work for ordinary users. Well. It tries to not interfere with ordinary users. In terms of working, one would need to establish the tangible benefit... A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. Yes, of course. Back in the before time (1990s), I had feared that this was going to be a big problem. That people would take the take “trust the authenticity” of a message to be “trust the veracity” of the message. But as it turns out, we haven’t seen a substantially higher proportion of fraud of this nature than in meatspace. I think it is because reputations are now so fragile. That last comment. Yes, either the system worked, or the system never worked, and wasn't needed. http://financialcryptography.com/mt/archives/001255.html Show which? The more things you do to it, and discover that nothing changes, is evidence to the latter. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking plug It would be blockchain-based solution like DNSChain: https://github.com/okTurtles/dnschain (Which is very much not abandoned.) /plug to protect against man in the middle? Certs don't defend against *the MITM*, they only defend against _their MITM_. Subtle different, the MITM known as phishing is more or less unprotected. I don't know what you mean by their MITM. Certs don't protect against MITM. Certs encourage Big-Brother MITM because they are intertwined with X.509 PKI: http://blog.okturtles.com/2014/02/introducing-the-dotdns-metatld/ - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Hi Jason, It's quite the coincidence that I saw this email of yours a few days ago when I was wondering the same thing. I've read through many of the replies to this thread but haven't been able to answer a related question that I have. I'm looking for a date that I could point to and call the birth of modern HTTPS/PKI. There is the Loren M Kohnfelder thesis from May of 1978, but that's not quite it because it wasn't actually available to anyone at the time. Perhaps an event along the lines of first modern HTTPS implementation in a public web browser was released, or something like that. Any leads? Maybe something from Netscape's history? Thanks, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Apr 16, 2014, at 10:30 AM, Jason Iannone jason.iann...@gmail.com wrote: The more I read, the more bewildered I am by the state of the PKI. The trust model's unwieldy system[1] of protocols, dependencies, and outright assumptions begs to be exploited. Add to that the browser behavior for a self-signed certificate (RED ALERT! THE SKY IS FALLING!) compared to a trusted site and we're in bizarro world. I'd rather we close the gap and appreciate a secure transaction with an unauthenticated party than proclaim all is lost when a self-signed key is presented. I see no reason to trust VeriSign or Comodo any more than Reddit. Assuming trust in a top heavy system of Certificate Authorities, Subordinate Certificate Authorities[2], Registration Authorities, and Validation Authorities[3] in a post bulk data collection partnership world is a non-starter. The keys are compromised. With that, I ask for a history lesson to more fully understand the PKI's genesis and how we got here. Maybe a tottering complex recursive heirarchical system of trust is a really great idea and I just need to be led to the light. [1]http://csrc.nist.gov/publications/nistpubs/800-15/SP800-15.PDF, http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf [2]https://www.eff.org/files/DefconSSLiverse.pdf, https://www.eff.org/files/ccc2010.pdf [3]http://en.wikipedia.org/wiki/Public-key_infrastructure ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 29 April 2014 07:41, Ryan Carboni rya...@gmail.com wrote: the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. Or Certificate Transparency. :-) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 29/04/2014 19:02 pm, Greg wrote: I'm looking for a date that I could point to and call the birth of modern HTTPS/PKI. There is the Loren M Kohnfelder thesis from May of 1978, but that's not quite it because it wasn't actually available to anyone at the time. Perhaps an event along the lines of first modern HTTPS implementation in a public web browser was released, or something like that. Any leads? Maybe something from Netscape's history? Yes, 1994, when Netscape invented SSL v1. Which had no MITM support, which was then considered to be a life and death issue by RSADSI ... which just happened to have invested big in a think called x.509. And the rest is history. Some commentary here, which is opinion not evidence. http://financialcryptography.com/mt/archives/000609.html iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Or Certificate Transparency. :-) Sorry Ben, But your Certificate Transparency is not a solution. It's an invitation to more trouble: - Your currently published RFC doesn't actually fix the MITM problem, it merely gives the illusion of a fix. It doesn't actually prevent governments from issuing fake certificates and MITMing connections, and your attempt to address this problem is a mere TBD. - Your RFC is an obvious attempt to preserve today's pay-for-protection system. It's clear from the RFC that Google is actually trying to lead the internet down a dangerous path where people *must* pay for security by not supporting self-signed certificates. I look forward to writing a more detailed post on it. Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Apr 29, 2014, at 1:11 PM, Ben Laurie b...@links.org wrote: On 29 April 2014 07:41, Ryan Carboni rya...@gmail.com wrote: the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. Or Certificate Transparency. :-) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
- Your RFC is an obvious attempt to preserve today's pay-for-protection system. It's clear from the RFC that Google is actually trying to lead the internet down a dangerous path where people *must* pay for security by not supporting self-signed certificates. Erm, sorry, that should read: where people *must* pay for insecurity, as it's, well, not actually secure. -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Apr 29, 2014, at 1:22 PM, Greg g...@kinostudios.com wrote: Or Certificate Transparency. :-) Sorry Ben, But your Certificate Transparency is not a solution. It's an invitation to more trouble: - Your currently published RFC doesn't actually fix the MITM problem, it merely gives the illusion of a fix. It doesn't actually prevent governments from issuing fake certificates and MITMing connections, and your attempt to address this problem is a mere TBD. - Your RFC is an obvious attempt to preserve today's pay-for-protection system. It's clear from the RFC that Google is actually trying to lead the internet down a dangerous path where people *must* pay for security by not supporting self-signed certificates. I look forward to writing a more detailed post on it. Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-04-29 18:18, ianG wrote: On 29/04/2014 19:02 pm, Greg wrote: I'm looking for a date that I could point to and call the birth of modern HTTPS/PKI. There is the Loren M Kohnfelder thesis from May of 1978, but that's not quite it because it wasn't actually available to anyone at the time. Perhaps an event along the lines of first modern HTTPS implementation in a public web browser was released, or something like that. Any leads? Maybe something from Netscape's history? Yes, 1994, when Netscape invented SSL v1. Which had no MITM support, which was then considered to be a life and death issue by RSADSI ... which just happened to have invested big in a think called x.509. And the rest is history. Some commentary here, which is opinion not evidence. http://financialcryptography.com/mt/archives/000609.html I guess the historic gap between Loren Kohnfelder thesis and Netscape SSL development has to be filled with due consideration of the OSI development, and notably the Network Layer Security Protocol (NLSP). Prior to the domination of IP protocols, the information highway was expected to be secured with the NLSP over an X.25 backbone. The payment industry was investing in SET (Secure Electronic Transactions), and the Netscape SSL was first perceived as a childish attempt for a quick and (very) dirty short term solution. Even then, in my understanding, there would still be a gap between Loren thesis and the NLSP development. I have some clues that the Digital Equipment DecNET protocols would fill this gap. Don't look at Microsoft. By 1995, their only IT security commitment seemed to be for a facsimile security protocol (even devoid of public key crypto). (This should have been a prior art against Data Treasury cheque imaging patent battle, but that's another lllooonng story.) In retrospect, the ASN.1 based X.509 security certificate has been salvaged from the OSI effort thanks to Verisign dedication to license their patents for some IETF protocols on easy terms. Lotus Notes security is special because it evolved from an RSA technology license acquired prior to RSADSI, and they use certificates without the ASN.1/X.509 paradigms. Regards, - Thierry Moreau ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
I suspect our current X.509 PKI was invented at Xerox … likely PARC. The first X.509 draft was a Xerox contribution in about 1984. I have it somewhere in my garage… Paul On Apr 29, 2014, at 1:45 PM, Greg g...@kinostudios.com wrote: On Apr 29, 2014, at 1:18 PM, ianG i...@iang.org wrote: Yes, 1994, when Netscape invented SSL v1. Which had no MITM support, which was then considered to be a life and death issue by RSADSI ... which just happened to have invested big in a think called x.509. And the rest is history. Some commentary here, which is opinion not evidence. http://financialcryptography.com/mt/archives/000609.html Fascinating. I especially liked the timelines there, thanks for the link! I'm now slowly coming to the conclusion that my search for a specific birthdate of modern PKI might be in vain. The way I phrased it in an email to Peter was: Do you happen to know of the date of the following event: when did the first publicly available web browser successfully connect over HTTPS to the a publicly available HTTPS website, and have the website's certificate validated by a CA in the same manner as it is done today? ..if that's not available, then simply the date of the release of the first implementation of HTTPS? There's also this little timeline graphic from the link: gp8.png Then there's the wiki: https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development Which says: The SSL protocol was originally developed by Netscape.[10] Version 1.0 was never publicly released; version 2.0 was released in February 1995 but contained a number of security flaws which ultimately led to the design of SSL version 3.0.[11] SSL version 3.0, released in 1996, was a complete redesign of the protocol produced by Paul Kocher working with Netscape engineers Phil Karlton and Alan Freier. Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by IETF as a historical document in RFC 6101. And there's the x509 wiki: https://en.wikipedia.org/wiki/X.509#Public-Key_Infrastructure_.28X.509.29_Working_Group The The Public-Key Infrastructure (X.509) working group (PKIX) was a working group of the Internet Engineering Task Force dedicated to creating RFCs and other standard documentation on issues related to public key infrastructure based on X.509 certificates. PKIX was established in Autumn 1995 in conjunction with the National Institute of Standards and Technology.[17] So... it sounds like Netscape either had a publicly available implementation of modern PKI before, or at about the same time as the standards were being published. In that case, while there doesn't appear to be a precise date, the birth year at least seems to be 1995. This monstrosity was born sometime late 1995. Is that about right? Or would I be mistaken to call that the birth year? Thanks much for the history lesson and fascinating references! - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Hi Ian, I will just respond to one of the many excellent points you’ve made. On 2014-04-29, at 12:12 PM, ianG i...@iang.org wrote: On 29/04/2014 17:14 pm, Jeffrey Goldberg wrote: People do trust their browsers and OSes to maintain a list of trustworthy CAs. No they don't. Again, you are taking the words from the sold-model. I will explain my words below. People don't have a clue what a trustworthy CA is, in general. I emphatically agree with you. I hadn’t meant to imply otherwise. I have been using “trust” in a sort of behavioral way. For the sake of the next few sentences, I’m going to introduce some terrible terminology. “b-trust” is my “behavioral trust” which will defined in terms of “c-trust” (“cognitive”). So let’s say that A c-trusts B wrt to X when A is confident that B will act in way X. (Cut me some slack on “act”). A “b-trusts” B wrt to X when she behaves as if she c-trusts B wrt to X. So when I say that users trust their browsers to maintain a list of trustworthy CAs, I am speaking of “b-trust”. They may have no conscious idea or understanding what they are actually trusting or why it is (or isn’t) worthy of their trust. But they *behave* this way. A vampire bat may b-trust that its rook mates will give it a warm meal if necessary. Life is filled with such trust relations even where there is no c-trust. (c.f., the *real meaning of trust* being a human decision to take a risk on available information.) Which is what I am talking about. And I’m talking about it because it is what matters for human behavior. And I want a system that works for humans. I see that you’ve written on financial cryptography. Well think about conventional currency works. For all its problems currency works, and it is a system that requires “trust”. But only a negligible fraction of the people who successfully use the system do so through c-trust. It may well be that all of the problems with TLS are because the system is trying to work for agents who don’t understand how the system works. But, as I said at the beginning, that is the world we are living in. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Apr 29, 2014, at 12:28 PM, Thierry Moreau thierry.mor...@connotech.com wrote: On 2014-04-29 18:18, ianG wrote: On 29/04/2014 19:02 pm, Greg wrote: I'm looking for a date that I could point to and call the birth of modern HTTPS/PKI. There is the Loren M Kohnfelder thesis from May of 1978, but that's not quite it because it wasn't actually available to anyone at the time. Perhaps an event along the lines of first modern HTTPS implementation in a public web browser was released, or something like that. Any leads? Maybe something from Netscape's history? Yes, 1994, when Netscape invented SSL v1. Which had no MITM support, which was then considered to be a life and death issue by RSADSI ... which just happened to have invested big in a think called x.509. And the rest is history. Some commentary here, which is opinion not evidence. http://financialcryptography.com/mt/archives/000609.html I guess the historic gap between Loren Kohnfelder thesis and Netscape SSL development has to be filled with due consideration of the OSI development, and notably the Network Layer Security Protocol (NLSP). Prior to the domination of IP protocols, the information highway was expected to be secured with the NLSP over an X.25 backbone. No. NLSP had two modes, connection-less and connection oriented. I was one of the authors … The connection oriented never went very far. NLSP was essentially the SP3 protocol developed as a research effort with NSA funding for a complete suite of protocols using public key based authentication in the Secure Data Network System (SDNS) project. it was the late 80’s and at the time NSA encouraged open publication of the work. NIST published the effort as the “SDN” series (e.g. SDN.301 for layer 3 security). The same work went into ISO (as NLSP) and the IETF. The SP3 and KMP were starting points of the IPsec work. In hind sight, the KMP specification is much better than what we ended up with IKE. However, some good improvements were added in the process. It’s interesting that I can not find any of the NIST published SDN specification on the NIST site :-( More digging required. The Message Security Protocol (MSP) work was also a SDNS effort for secure email. When taken public this morphed into our current Internet email security. Paul The payment industry was investing in SET (Secure Electronic Transactions), and the Netscape SSL was first perceived as a childish attempt for a quick and (very) dirty short term solution. Even then, in my understanding, there would still be a gap between Loren thesis and the NLSP development. I have some clues that the Digital Equipment DecNET protocols would fill this gap. Don't look at Microsoft. By 1995, their only IT security commitment seemed to be for a facsimile security protocol (even devoid of public key crypto). (This should have been a prior art against Data Treasury cheque imaging patent battle, but that's another lllooonng story.) In retrospect, the ASN.1 based X.509 security certificate has been salvaged from the OSI effort thanks to Verisign dedication to license their patents for some IETF protocols on easy terms. Lotus Notes security is special because it evolved from an RSA technology license acquired prior to RSADSI, and they use certificates without the ASN.1/X.509 paradigms. Regards, - Thierry Moreau ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Message du 29/04/14 20:11 De : Ben Laurie On 29 April 2014 07:41, Ryan Carboni wrote: the only logical way to protect against man in the middle attacks would be perspectives (is that project abandoned?) or some sort of distributed certificate cache checking. Or Certificate Transparency. :-) And how is that supposed to work? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Tue, Apr 29, 2014 at 7:10 PM, tpb-cry...@laposte.net wrote: Or Certificate Transparency. :-) And how is that supposed to work? Here, let me help you out: http://lmgtfy.com/?q=certificate+transparencyl=1 -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 28/04/2014 20:58 pm, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. cof it's them that have shown themselves totally incapable of doing anything about it. Indeed, it's them that stopped others doing anything about it. Although it should be easier establishing your own certificate authority. Oh, they fixed that too :) iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
trust is outsourced all the time in the non-cryptographic world unless you do not have a bank account On Mon, Apr 28, 2014 at 3:00 PM, James A. Donald jam...@echeque.com wrote: On 2014-04-29 05:58, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, however we find that diverse entities have very similar names, and a single entity may have many names. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 29/04/2014 00:12 am, Ryan Carboni wrote: trust is outsourced all the time in the non-cryptographic world trust is built up all the time, risks are taken all the time, choice is taken all the time. unless you do not have a bank account That's not outsourced, that's direct, person to bank, the person has a choice, chooses to place her trust in that bank. Also, it is limited to defined things that are required, can't be done by the person, and bolstered by real backing such as FIDC. When you suggest it's probably best we trust authorities that is CA-playbook crapola meaning you must trust the authorities that have been picked for you. The vector has been reversed, people are told what has to happen, so there is no trust. Trust derives from choice. Where is the choice? iang On Mon, Apr 28, 2014 at 3:00 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: On 2014-04-29 05:58, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, however we find that diverse entities have very similar names, and a single entity may have many names. _ cryptography mailing list cryptography@randombit.net mailto:cryptography@randombit.net http://lists.randombit.net/__mailman/listinfo/cryptography http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
One can always start with the difficult first step of uninstalling certificate authorities you do not trust. On Mon, Apr 28, 2014 at 4:42 PM, ianG i...@iang.org wrote: On 29/04/2014 00:12 am, Ryan Carboni wrote: trust is outsourced all the time in the non-cryptographic world trust is built up all the time, risks are taken all the time, choice is taken all the time. unless you do not have a bank account That's not outsourced, that's direct, person to bank, the person has a choice, chooses to place her trust in that bank. Also, it is limited to defined things that are required, can't be done by the person, and bolstered by real backing such as FIDC. When you suggest it's probably best we trust authorities that is CA-playbook crapola meaning you must trust the authorities that have been picked for you. The vector has been reversed, people are told what has to happen, so there is no trust. Trust derives from choice. Where is the choice? iang On Mon, Apr 28, 2014 at 3:00 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: On 2014-04-29 05:58, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, however we find that diverse entities have very similar names, and a single entity may have many names. _ cryptography mailing list cryptography@randombit.net mailto:cryptography@randombit.net http://lists.randombit.net/__mailman/listinfo/cryptography http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 29/04/2014 01:20 am, Ryan Carboni wrote: One can always start with the difficult first step of uninstalling certificate authorities you do not trust. Yup. And if you don't like your country, you can hand in your passport on the way out. Marketing lies aside, it is clear that the ordinary user has no choice. iang On Mon, Apr 28, 2014 at 4:42 PM, ianG i...@iang.org mailto:i...@iang.org wrote: On 29/04/2014 00:12 am, Ryan Carboni wrote: trust is outsourced all the time in the non-cryptographic world trust is built up all the time, risks are taken all the time, choice is taken all the time. unless you do not have a bank account That's not outsourced, that's direct, person to bank, the person has a choice, chooses to place her trust in that bank. Also, it is limited to defined things that are required, can't be done by the person, and bolstered by real backing such as FIDC. When you suggest it's probably best we trust authorities that is CA-playbook crapola meaning you must trust the authorities that have been picked for you. The vector has been reversed, people are told what has to happen, so there is no trust. Trust derives from choice. Where is the choice? iang On Mon, Apr 28, 2014 at 3:00 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com mailto:jam...@echeque.com mailto:jam...@echeque.com wrote: On 2014-04-29 05:58, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, however we find that diverse entities have very similar names, and a single entity may have many names. _ cryptography mailing list cryptography@randombit.net mailto:cryptography@randombit.net mailto:cryptography@randombit.net mailto:cryptography@randombit.net http://lists.randombit.net/__mailman/listinfo/cryptography http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net mailto:cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net mailto:cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Mon, Apr 28, 2014 at 8:20 PM, Ryan Carboni rya...@gmail.com wrote: One can always start with the difficult first step of uninstalling certificate authorities you do not trust. Opera will autorepair damage to the certificate repository, a missing Certificate Authority is considered damage. Opera ships with a list of frequently used certificates, and if any of these are missing they will be added the next time the repository is read from disk. Other certificates will be added from the online repository as needed. - http://my.opera.com/community/forums/topic.dml?id=1580452 Its not just Opera. Others are using similar innovative methods to reduce the support load and costs. Jeff On Mon, Apr 28, 2014 at 4:42 PM, ianG i...@iang.org wrote: On 29/04/2014 00:12 am, Ryan Carboni wrote: trust is outsourced all the time in the non-cryptographic world trust is built up all the time, risks are taken all the time, choice is taken all the time. unless you do not have a bank account That's not outsourced, that's direct, person to bank, the person has a choice, chooses to place her trust in that bank. Also, it is limited to defined things that are required, can't be done by the person, and bolstered by real backing such as FIDC. When you suggest it's probably best we trust authorities that is CA-playbook crapola meaning you must trust the authorities that have been picked for you. The vector has been reversed, people are told what has to happen, so there is no trust. Trust derives from choice. Where is the choice? On Mon, Apr 28, 2014 at 3:00 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: On 2014-04-29 05:58, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, however we find that diverse entities have very similar names, and a single entity may have many names. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
If browsers are defeating the purpose of the chain of trust, by forcing trust in this example, why design them to freak out when a site self signs? On Apr 28, 2014 6:32 PM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Apr 28, 2014 at 8:20 PM, Ryan Carboni rya...@gmail.com wrote: One can always start with the difficult first step of uninstalling certificate authorities you do not trust. Opera will autorepair damage to the certificate repository, a missing Certificate Authority is considered damage. Opera ships with a list of frequently used certificates, and if any of these are missing they will be added the next time the repository is read from disk. Other certificates will be added from the online repository as needed. - http://my.opera.com/community/forums/topic.dml?id=1580452 Its not just Opera. Others are using similar innovative methods to reduce the support load and costs. Jeff On Mon, Apr 28, 2014 at 4:42 PM, ianG i...@iang.org wrote: On 29/04/2014 00:12 am, Ryan Carboni wrote: trust is outsourced all the time in the non-cryptographic world trust is built up all the time, risks are taken all the time, choice is taken all the time. unless you do not have a bank account That's not outsourced, that's direct, person to bank, the person has a choice, chooses to place her trust in that bank. Also, it is limited to defined things that are required, can't be done by the person, and bolstered by real backing such as FIDC. When you suggest it's probably best we trust authorities that is CA-playbook crapola meaning you must trust the authorities that have been picked for you. The vector has been reversed, people are told what has to happen, so there is no trust. Trust derives from choice. Where is the choice? On Mon, Apr 28, 2014 at 3:00 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: On 2014-04-29 05:58, Ryan Carboni wrote: We happen to live on a planet where most users are ordinary users. given the extent of phishing, it's probably best we outsource trust to centralized authorities. Although it should be easier establishing your own certificate authority. Cannot outsource trust Ann usually knows more about Bob than a distant authority does. A certificate authority does not certify that Bob is trustworthy, but that his name is Bob. In practice, however we find that diverse entities have very similar names, and a single entity may have many names. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 25/04/2014 16:36 pm, Jeffrey Goldberg wrote: On 2014-04-25, at 4:09 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf In which Peter says: ... I hated X.509 when it was first being introduced, and much preferred PGP’s “Web of Trust”. I still hate X.509 for all of the usual reasons, but I now have much more sympathy for the design choices. It fails at its goal of not demanding unrealistic from ordinary users, but at least it tries attempts to do so. There is a slight problem with goals here. PKI was never designed for ordinary users. If you read the original documentation of how PKI was organised before the web-PKI was invented, it talks about how each relying party has to enter into a contract and verify that the CPS provides the answer they are looking for. In this context, it was reasonable to talk about the relying party trusting the results, because they had actually gone through the process of developing that trust. According to the theory. When they did the web-PKI however they threw away all of the reliance contract requirements, or buried them, but kept the language of trust. As you point out, they had to do this because ordinary users won't go through the process of CPS and contract review. So the result was trust-but-no-trust. We are not using PKI as it was designed and theorised. We're using some form of facade that originally had no proper contractual basis. The contracts are being sorted out now, over the last 5 years or so, in secret, but the joke of course is that we still all believe that we're using trust and PKI and so forth when none of that really applies. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 04/27/2014 07:43 AM, ianG wrote: There is a slight problem with goals here. PKI was never designed for ordinary users. If you read the original documentation of how PKI was organised before the web-PKI was invented, it talks about how each relying party has to enter into a contract and verify that the CPS provides the answer they are looking for. In this context, it was reasonable to talk about the relying party trusting the results, because they had actually gone through the process of developing that trust. According to the theory. When they did the web-PKI however they threw away all of the reliance contract requirements, or buried them, but kept the language of trust. As you point out, they had to do this because ordinary users won't go through the process of CPS and contract review. So the result was trust-but-no-trust. We are not using PKI as it was designed and theorised. I concur. If you consider that the early writings on PKI had more legal language and lawyers involved [1], [2] and [3], it becomes clear that PKI was designed more for B2B transactions than B2C. That it is being contorted for B2C transactions - without the consumer being sufficiently educated to understand the technology, personal responsibility and implications - is where PKI went down a slippery slope. The dozens of PKIs I have setup over the last 15 years have been fairly successful, primarily because the RP is also the issuer of the digital certificates (they are closed PKIs for internal use only). In those rare cases where PKI is being used for TLS ClientAuth across companies, it has been for B2B transactions where preexisting contracts exist. Arshad Noor StrongAuth, Inc. [1] http://www.americanbar.org/content/dam/aba/events/science_technology/2013/dsg_tutorial.authcheckdam.pdf [2] http://www.amazon.com/Secure-Electronic-Commerce-Infrastructure-Signatures/dp/0130272760 [3] https://www.ietf.org/rfc/rfc3647.txt ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 25/04/2014 18:40 pm, Tony Arcieri wrote: On Fri, Apr 25, 2014 at 3:10 AM, ianG i...@iang.org mailto:i...@iang.org wrote: Worse, consider Firefox's behaviour: it considers a certificate-secured site such as a self-cert'd site to be dangerous, but it does not consider a HTTP site to be dangerous. So it tells the user HTTP is safe, whereas an attempt to secure means that the user is being robbed! I actually brought this up with one of Chrome UX engineers, specifically how to Joe User the address bar makes it appear that plaintext HTTP is more secure than HTTPS with an untrusted cert. While one is MitM-able by an active attacker, the other is most certainly being passively MitMed by someone! :O The response was that users have an expectation of security when using HTTPS that they don't with HTTP, but I wonder, how many people just think they're safe because of the absence of scary warning signs and have no idea what HTTP vs HTTPS actually means? Right, that is their logic, and as usual it depends on their rather unique and personal assumptions which they are incapable of discussing. We know from phishing and from research that people do not have a reliable knowledge of whether they are in HTTP or HTTPS in the first place. We also know that prevalence of scary warnings for false negatives is O(100) times that of true negatives, and from statistics, this means that users are trained to click-thru scary warnings, and will miss any true negatives. Hence click-thru syndrome. We also know K6 that if the system is complicated, they'll choose to turn it off and go naked. So the 'expectation' which the developers image they are trying to meet is really rather hopeful, at best, cognitive dissonance in the middle and negligence at the sharp end. Yes, us lot here know about it. Yes, developers know about it. But the users? Not a lot of hope there, not enough to build a PKI promise on. I think plaintext HTTP should show an lock with a big no sign over it or something to highlight to users that the connection is insecure. I think colours are fine. White for HTTP. Light Blue for CA-HTTPS, Green for EV, and Light Pink for non-CA-HTTPS. But the point of the above mis-expectations is that it is aligned with CA notions of selling more certs. A self-signed cert is to them a lost CA-cert sale, so must be attacked. The fact that most CAs haven't the first clue about marketing (a rising tide lifts all boats) is a rabbit hole we'll refrain from today. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
Jason Iannone jason.iann...@gmail.com writes: With that, I ask for a history lesson to more fully understand the PKI's genesis and how we got here. http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf, chapter PKI. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 16/04/2014 16:30 pm, Jason Iannone wrote: The more I read, the more bewildered I am by the state of the PKI. No, not nearly enough: http://iang.org/ssl/pki_considered_harmful.html http://iang.org/ssl/ The trust model's unwieldy system[1] of protocols, dependencies, and outright assumptions begs to be exploited. Add to that the browser behavior for a self-signed certificate (RED ALERT! THE SKY IS FALLING!) compared to a trusted site and we're in bizarro world. Worse, consider Firefox's behaviour: it considers a certificate-secured site such as a self-cert'd site to be dangerous, but it does not consider a HTTP site to be dangerous. So it tells the user HTTP is safe, whereas an attempt to secure means that the user is being robbed! Go figure... Worse still, Firefox actually deceives and lies about the status of good certificates. If there is an ordinary SSL site, it shows it as white, same as HTTP. Icons and indicators are downplayed, lost in the noise. Worse again: If you click on the icon to ask, it says you are connected to www.example.com which is run by ( *UNKNOWN* ) even though the browser has a certificate that states clearly who runs the site. Try this site which is run by Google, as it says in the cert: https://developer.android.com/ Looking deeper it states: Owner: This website does not supply ownership information. One can only assume Firefox is upselling you to green certs, but lying and deceiving in the process. Chrome says something different, which I don't understand, but it doesn't seem to be quite so blatant. Is there any wonder nobody trusts any of it? I'd rather we close the gap and appreciate a secure transaction with an unauthenticated party than proclaim all is lost when a self-signed key is presented. I see no reason to trust VeriSign or Comodo any more than Reddit. Assuming trust in a top heavy system of Certificate Authorities, Subordinate Certificate Authorities[2], Registration Authorities, and Validation Authorities[3] in a post bulk data collection partnership world is a non-starter. The keys are compromised. With that, I ask for a history lesson to more fully understand the PKI's genesis and how we got here. Maybe a tottering complex recursive heirarchical system of trust is a really great idea and I just need to be led to the light. Sigh. You're thinking of it as a hierarchy of trust. That isn't what it is. There's no trust anywhere in the system, even the word 'trust' as used means a mandated obligatory acceptance, not trust as humans know it. [1]http://csrc.nist.gov/publications/nistpubs/800-15/SP800-15.PDF, http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf [2]https://www.eff.org/files/DefconSSLiverse.pdf, https://www.eff.org/files/ccc2010.pdf [3]http://en.wikipedia.org/wiki/Public-key_infrastructure I just ate breakfast, no thanks :( iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On 2014-04-25, at 4:09 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf In which Peter says: The major lesson that we’ve learned from the history of security (un-)usability is that technical solutions like PKI and access control don’t align too well with user conceptual models Exactly. If, for example, a user needs to understand the distinction between “trust as an introducer” versus “trust the identity of” in order to behave securely, then the system is going to fail. Or as I’ve said in http://blog.agilebits.com/2012/07/03/check-out-my-debit-card-or-why-people-make-bad-security-choices/ when we observe people systematically behaving insecurely, we have to ask not how can people be so stupid” but instead “how is the system leading them to behave insecurely.” I hated X.509 when it was first being introduced, and much preferred PGP’s “Web of Trust”. I still hate X.509 for all of the usual reasons, but I now have much more sympathy for the design choices. It fails at its goal of not demanding unrealistic from ordinary users, but at least it tries attempts to do so. Cheers, -j ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Request - PKI/CA History Lesson
On Fri, Apr 25, 2014 at 3:10 AM, ianG i...@iang.org wrote: Worse, consider Firefox's behaviour: it considers a certificate-secured site such as a self-cert'd site to be dangerous, but it does not consider a HTTP site to be dangerous. So it tells the user HTTP is safe, whereas an attempt to secure means that the user is being robbed! I actually brought this up with one of Chrome UX engineers, specifically how to Joe User the address bar makes it appear that plaintext HTTP is more secure than HTTPS with an untrusted cert. While one is MitM-able by an active attacker, the other is most certainly being passively MitMed by someone! :O The response was that users have an expectation of security when using HTTPS that they don't with HTTP, but I wonder, how many people just think they're safe because of the absence of scary warning signs and have no idea what HTTP vs HTTPS actually means? I think plaintext HTTP should show an lock with a big no sign over it or something to highlight to users that the connection is insecure. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Request - PKI/CA History Lesson
The more I read, the more bewildered I am by the state of the PKI. The trust model's unwieldy system[1] of protocols, dependencies, and outright assumptions begs to be exploited. Add to that the browser behavior for a self-signed certificate (RED ALERT! THE SKY IS FALLING!) compared to a trusted site and we're in bizarro world. I'd rather we close the gap and appreciate a secure transaction with an unauthenticated party than proclaim all is lost when a self-signed key is presented. I see no reason to trust VeriSign or Comodo any more than Reddit. Assuming trust in a top heavy system of Certificate Authorities, Subordinate Certificate Authorities[2], Registration Authorities, and Validation Authorities[3] in a post bulk data collection partnership world is a non-starter. The keys are compromised. With that, I ask for a history lesson to more fully understand the PKI's genesis and how we got here. Maybe a tottering complex recursive heirarchical system of trust is a really great idea and I just need to be led to the light. [1]http://csrc.nist.gov/publications/nistpubs/800-15/SP800-15.PDF, http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf [2]https://www.eff.org/files/DefconSSLiverse.pdf, https://www.eff.org/files/ccc2010.pdf [3]http://en.wikipedia.org/wiki/Public-key_infrastructure ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
