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
[cryptography] DNSChain 0.1.0 adds DANE/TLSA support for blockchain + canonical DNS
Good day list, We released 0.1.0 (and 0.1.1 the same day) a couple days ago. Thought it might interest the list: DNSChain is a DNS + HTTP(S) + Blockchain-proxy hybrid server designed to serve as a decentralized and distributed secure replacement for Certificate Authorities and X.509 PKI. It's also designed to act as a secure public key distribution system for both websites and identity systems. Today, with the help of various contributors, we released version 0.1.0: New Features: DANE/TLSA support for BOTH canonical DNS and blockchain DNS! Added NO_OLD_DNS option for oldDNSMethod (refuses all non-blockchain queries) Improvements: Redesigned dns.coffee and improved its structure Accurate ttl values now returned for namecoin DNS queries based on expires_in field Updated contributors, code and config examples in README.md Improved EDNS support Improved handling of ANY queries Updated dependencies to latest versions native-dns is now fetched from the dnschain branch of our fork. Comments added all over the place (to native-dns related projects also!) Many other code improvements both to DNSChain and the NodeJS native-dns module Some performance improvements Fixes: Fixed broken grunt example Fixed some uncaught exceptions (issues #1 and #2) Fixed broken NAPTR support Changes: DNSChain license is now MPL-2.0 (applies to version 0.1.0 onward) Default logging level is now info It's compatible with most UNIX-like systems (including OS X) and can be installed via the NPM package manager or manually via Git. Free public servers (including ones that support DNSCrypt), along with instructions for installing and running DNSChain, is available on its GitHub page: https://github.com/okTurtles/dnschain Cheers, Greg Slepak -- 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
[cryptography] Improving the state of end-to-end crypto
We are hiring to improve the state of end-to-end crypto: http://www.links.org/files/SimplySecureProgramDirectorJobPosting.pdf http://www.links.org/files/SimplySecure.pdf ___ 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] Improving the state of end-to-end crypto
On 04/27/2014 10:33 AM, Ben Laurie wrote: http://www.links.org/files/SimplySecure.pdf Ben, As noble as the goals are of this initiative, the solution is likely to be accepted only in UK and the USA - only because it appears that the people behind this effort are from those two countries. Given Snowden's revelations, why should anyone outside these two countries trust anything crypto emanating from the US UK? If we really want to see a universal crypto-protocol that works across the internet, the team that designs it must have representation from the US/UK's allies and enemies. If there are weaknesses in the design, then everyone stands to lose (and hopefully, the protocol never sees the light of day); if it is strong enough, then everyone is protected. I believe Bruce Schneier wrote that the US has proven itself to be a poor steward of the internet; to that extent if we want (reasonably) universal trust in a new crypto-protocol, its design must have representation from anyone that has a stake in it; anything less will only end up in balkanizing the internet from a crypto perspective. Arshad Noor StrongAuth, Inc. P.S. Note that the solution to the problem cannot merely be a technical one; crypto is a political tool, and in a borderless internet, the solution to the problem must account for the politics of trust. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Improving the state of end-to-end crypto
On 27/04/2014 18:33 pm, Ben Laurie wrote: We are hiring to improve the state of end-to-end crypto: http://www.links.org/files/SimplySecureProgramDirectorJobPosting.pdf http://www.links.org/files/SimplySecure.pdf To paraphrase, work with ... Advisory Board, developer communities, academics, funders, civil society, private partners, existing contacts - yours and others’ - developers, designers, academics, complimentary efforts, security experts, academics, and partners, auditors, conferences, venues,... Everyone *but the users* !! Shake it up, Ben. You can't improve the lot of the users unless you actually meet some of them. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] making money secure, was The Best 419 Message I've Seen
when you give someone your ABA routing number and account number. An account number for incoming funds only (drop box?) would solve a number of these problems. Actually there are inbound-only ACH account numbers, but only businesses use them. ACH transfers are reversible, so they're not very useful for fraud unless you can ensure that the victim won't notice before you have time for the transfer to complete and for you to clean out the account. Unfortunately, the brain dead payment geniuses in (for instance) the United States manage to design a payment system that permits third parties to order drafts (e-checks) against arbitrary account numbers in order to (for instance) enable e-payments to be pulled from checking accounts at the prompting of the payee. Same thing, they're reversible. One security model is to make sure that nothing bad ever happens, the other is to admit that bad things will happen and make provision for reversing them. In the US at least, bank security is mostly the latter and only a little bit the former. Bank wires are not usually reversible, which is why there's no such thing as a pull bank wire, and why crooks like to break into business web accounts and send wires to their overseas selves. My bank does fairly credible 2FA for wires. I have to punch the last digits of the recipient account number into my physical security token and enter the code it provides, which I'd think would make it pretty hard to do most of the MITM tricks. http://obvious.services.net/2013/07/better-have-big-pockets-if-you-want.html R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
