Re: A mighty fortress is our PKI
On Jul 26, 2010, at 10:22 PM, Chris Palmer wrote: Perry E. Metzger writes: All major browsers already trust CAs that have virtually no security to speak of, ...and trust any of those CAs on any (TCP) connection in the (web app) session. Even if your first connection was authenticated by the right CA, the second one may not be. Zusmann and Sotirov suggested SSL pinning (like DNS pinning, in which the browser caches the DNS response for the rest of the browser process' lifetime), but as far as I know browsers haven't implemented the feature. I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) cpf.digicert.com IN TXT v=cpf1 /^DigiCert/ -all Get the top 5 browsers to support it, and a lot of that any CA can issue to any domain risk goes way down. Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only) Is there a reason that opportunistic crypto (no cert required) hasn't been done for https? Would it give too much confidence to people whose DNS is being spoofed? A presentation I've given at a few security gatherings may be of interest. I cover some specific security, UI/UX, and policy problems, as well as some general observations about incentives and barriers to improvement. Our overall recommendation is to emulate the success of SSH, but in a browser-y, gentle-compliance-with-the-status-quo-where-safe way. https://docs.google.com/present/view?id=df9sn445_206ff3kn9gs Great slides! The TOFU/POP is nice, and my favorite concept was to translate every error message into a one sentence, easy-to-understand statement. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Wow, I was just going to recommend Dan's book, Security Metrics. It is actually Andy Jaquith's book, I only wrote the intro. In the meantime, though, couple of years ago I did a tutorial on security metrics which you may find useful http://geer.tinho.net/measuringsecurity.tutorial.pdf Best, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann writes: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) That's along the lines of what EFF and I propose, yes. As I state in the slides, a key problem is how to smooth over the adaptation problem by various heuristics. We don't necessarily think that our mechanism is best, just that it's one of a family of likely approaches. Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) Even if anyone other than spammers had adopted SPF, we should still be seeking to reduce cruft, not increase it. Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only) Sure, or simply put the cert in the DNS itelf. But, DNS is not secure, so in doing so we would not actually be solving the secure introduction problem. Some people think that DNSSEC can fill in here, but it hasn't yet. Is there a reason that opportunistic crypto (no cert required) hasn't been done for https? As you can see, I am a firm advocate that we should emulate and improve on SSH's success. On one of my computers I use the HTTPS Everywhere and Perspectives plugins for Firefox; the latter renders CAs pretty much moot and the former gets me HTTPS by default at least some of the time. It's a fine thing. Remember when we all dropped telnet like a hot potato and migrated to SSH pretty much overnight? Let's do that again. Browsers should use secure transport by default in a way that is meaningful to humans and cheap to deploy. Would it give too much confidence to people whose DNS is being spoofed? I believe it would be a vast improvement in such a scenario. It would be hard to do worse than the status quo. Great slides! The TOFU/POP is nice, and my favorite concept was to translate every error message into a one sentence, easy-to-understand statement. Thank you. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Ben Laurie b...@links.org writes: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. This wouldn't make any difference, except for the special case of x64, signatures are only verified on install, so existing installed code isn't affected and anything new that's being installed is, with either form of sig-checking. In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). The way to revoke a cert for signed malware is to wait 0-12 hours for the malware signature to be added to AV databases, not to actually expect PKI to work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 28/07/2010 01:07, Paul Tiemann wrote: There is a long list of flyblown metaphors which could similarly be got rid of if enough people would interest themselves in the job; and it should also be possible to laugh the not un- formation out of existence*... *One can cure oneself of the not un- formation by memorizing this sentence: A not unblack dog was chasing a not unsmall rabbit across a not ungreen field. Had he succeeded in this mission, then we could never have had John Major on Spitting Image being not inconsiderably incandescent. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 00:14, Paul Tiemann wrote: On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. I like that idea, as long as a verifiable timestamp is included. Without a trusted timestamp, would the bad guy be able to backdate the signature? Note that I avoided this issue by using the date of receipt. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 09:57, Peter Gutmann wrote: Ben Laurie b...@links.org writes: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. This wouldn't make any difference, except for the special case of x64, signatures are only verified on install, so existing installed code isn't affected and anything new that's being installed is, with either form of sig-checking. Obviously if you are going to change revocation you can also change when signatures are checked. This hardly seems like a show-stopper. In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). Again, citing the failure to use revocation correctly right now does not tell us anything much about the possibility of using it correctly in the future. The way to revoke a cert for signed malware is to wait 0-12 hours for the malware signature to be added to AV databases, not to actually expect PKI to work. At which time they release another version? Doesn't sound like the optimal answer to me. I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 27, 2010, at 5:34 PM, Ben Laurie wrote: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. There is, of course, the problem of knowing when a signature was stolen! You can know that it was definitely stolen *by* a particular date, but never that it wasn't stolen earlier. Given that it was stolen, what evidence could you produce that it wasn't stolen - and simply kept around for later use - at the moment it was created? Beyond that, you it's often hard to know when you received a file. Perhaps the actual attack was to stick it on your system and backdate it! A forensic examination could look at backups, but we're talking about how to decide whether to accept a signature in an operational setting. You can't, of course, rely on any dates within the file itself, as they are protected from fakery only by the signature that you can't trust. You could rely on a digital time-stamping service ... but that just brings into sharper focus the absurdity that actually began the moment you needed to check an on-line CRL. The only conceivable purpose for using a signature is that you can check it *offline*. If you assume you can connect to the network, and that you can trust what you get from the network - why bother with a signature? Simply check a cryptographic hash of the driver against an on-line database of known good drivers. This is right in line with Lynn Wheeler's frequent mention here that the use case for offline verification of certs for commerce basically doesn't exist. It was a nice theory to develop 30 years ago, but today the rest of the framework assumes connectivity, and you buy nothing but additional problems by focusing on making just one piece work off-line. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Fwd: Introduction, plus: Open Transactions -- digital cash library
Anyone out there with a coding.clue wanna poke inside this thing and see if it's an actual bearer certificate -- and not yet another book-entry -- transaction system? Thanks. Cheers, RAH Who sees lucre down there in the mousetype and takes heart... Begin forwarded message: From: Fellow Traveler f3llowtrave...@gmail.com Date: July 28, 2010 1:52:28 AM AST To: agile-banking agile-bank...@googlegroups.com Subject: Introduction, plus: Open Transactions -- digital cash library Hello, I am Fellow Traveler, and I just found this group. I have written a digital cash library and transaction processor (server and test client) and just released it open source. You can read more about my project here: Articles: http://github.com/FellowTraveler/Open-Transactions/wiki Source code: http://github.com/FellowTraveler/Open-Transactions I am hoping that my work can contribute in some way to your own, and also that anyone who is working on client software would check out what I have built and possibly integrate with it. It would be easy to include my library into your client, and simply copy whatever code you need from my test wallet. Thank you for your efforts to fix our broken monetary system. I hope that my contribution is useful to everyone. -Fellow Traveler WHAT IS Open Transactions ? -- It's a solid, easy-to-use, CRYPTO and DIGITAL CASH LIBRARY. -- Including a FULLY OPERATIONAL client and server (command line for now--that's where you come in)... -- It's OPEN SOURCE, and encapsulates a COMPLETE PROTOCOL FOR TRANSACTIONS. -- It's object-oriented, and written in C++ on Mac/UNIX using OpenSSL. -- Including: SECURE NUMBERED ACCOUNTS UNTRACEABLE DIGITAL CASH TRIPLE-SIGNED RECEIPTS BASKET CURRENCIES SIGNED XML CONTRACTS, and more... IN DETAIL, THE SOFTWARE FEATURES: -- ANONYMOUS, NUMBERED ACCOUNTS, secured by public key cryptography. Your PGP key is your key, and the hash of it is your User ID. Each user can create an unlimited number of asset accounts, of any type, each with its own randomly-generated ID. No other information is stored. As long as you connect over Tor and take other similar precautions, there's no way to connect any of those accounts to you. You can also create as many User IDs as you wish, with your wallet software managing all your Pseudonyms and Asset Accounts across multiple transaction servers and multiple asset types. -- UNTRACEABLE DIGITAL CASH: Fully implemented! Cash withdrawals of any asset type, using Lucre. (Ben Laurie's implementation of Wagner's variant on Chaumian blinding.) Once cash is withdrawn, the server has no way of tracking it or linking it back to its next deposit. I've got Lucre wrapped up in C+ + classes and XML contracts and all the rest of the protocol, and it's fully functional with denominations and everything. -- PGP FOR MONEY. The idea is to build this so that it supports many cash algorithms, not just Lucre. I'd like to add Chaum's version, Brands' version, etc. So that, just like PGP, the software should support as many of the top algorithms as possible, and make it easy to swap them out when necessary. -- TRIPLE-SIGNED RECEIPTS for account-to-account transfers. This allows the client and server to agree on balances while simultaneously not storing any transaction history. (Client may choose to store his own transaction history.) No money can ever be transferred or withdrawn without an authorizing signature from the account owner. See Trubanc for an example of this, as well as, I presume, Ricardo by Systemics. -- EVERYONE A POTENTIAL ISSUER. Any user can design and issue his own currency: Simply upload the currency contract to any server. Anyone else with a copy of that contract can open an asset account denominated in the new currency type. The currency contract is simply an XML file with your digital signature on it, and the new currency ID is a hash of that same contract. The currency ID is unique to each contract and consistent across all servers. It's impossible to change any details of the contract, including the URL, the signature, or the public key, without entirely changing the contract's ID. -- BASKET CURRENCIES. My new server software allows you to distribute the risk of a single currency across MULTIPLE ISSUERS. How is this possible? Users can define basket currencies, which the server treats the same as any other currency, but which, behind the scenes, are each simply a list of 5, 10, or 100 OTHER currency contracts. The issuance is simply delegated to a basket of other currencies. Users can easily exchange in and out of these basket currencies using their wallet software. (Or define their own baskets.) This means that the currency which ends up in general use will not have 1 trusted issuer, but instead 10 or 100 issuers! Basket currencies are already
Re: A mighty fortress is our PKI, Part II
Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? It's not just that the world doesn't work that way now, it's quite likely that it'll never work that way (for the case of PKI/revocations mentioned in the message, not the original SNI). We've been waiting for between 20 and 30 years (depending on what you define as the start date) for PKI to start working, and your reponse seems to indicate that we should wait even harder. If I look at the mechanisms we've got now, I can identify that commercial PKI isn't helping, and revocations aren't helping, and work around that. I'm after effective practical solutions, not just a solution exists, QED solutions. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 13:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? It's not just that the world doesn't work that way now, it's quite likely that it'll never work that way (for the case of PKI/revocations mentioned in the message, not the original SNI). We've been waiting for between 20 and 30 years (depending on what you define as the start date) for PKI to start working, and your reponse seems to indicate that we should wait even harder. If I look at the mechanisms we've got now, I can identify that commercial PKI isn't helping, and revocations aren't helping, and work around that. I'm after effective practical solutions, not just a solution exists, QED solutions. The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I don't know why it should help that we find different solutions for the world to ignore? -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Tue, Jul 27, 2010 at 10:10:54PM -0600, Paul Tiemann wrote: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) My preference would be for doing something like SCRAM (and other SASL/GSS mechanisms) with channel binding (using tls-server-end-point CB type). It has the effect that the server can confirm that the certificate seen by the client is the correct one -- whereas the server cannot do that in the SSL pinning approach. It'd have other major benefits as well. The problem is: there's no standard way to do this in web browser applications. Worse, there's not even any prototypes. I also like the Moonshot approach. Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) Better yet: use DNSSEC and publish TLS EE certs in the DNS. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 01:21:33PM +0100, Ben Laurie wrote: On 28/07/2010 13:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? [...]. I'm after effective practical solutions, not just a solution exists, QED solutions. The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I don't know why it should help that we find different solutions for the world to ignore? Solutions at higher layers might have a better chance of getting deployed. No, I'm not suggesting that we replace TLS and HTTPS with application-layer crypto over HTTP, not entirely anyways. I am suggesting that we use what little TLS does give us in ways that don't require changing TLS much or at all. Application-layer authentication with tls-server-end-point channel bindings seems like a feasible candidate. This too would require changes on clients and servers, which makes it not-that-likely to get implemented and deployed, but not changes at the TLS layer (other than an API by which to extract a TLS connection's server cert). It could be deployed incrementally such that users who can use it get better security. Then if the market gives a damn about security, it might get closer to fully deployed in our lifetimes. The assumption here is that improvements at the TLS and PKI layers occur with enormous latency. If this were true at all layers then we could just give up, or aim to fix not just today's problems, but tomorrow's, a decade or three from now (ha). It'd be nice if that assumption were not true at all. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 28, 2010, at 8:21 33AM, Ben Laurie wrote:
On 28/07/2010 13:18, Peter Gutmann wrote:
Ben Laurie b...@links.org writes:
I find your response strange. You ask how we might fix the problems, then
you
respond that since the world doesn't work that way right now, the fixes
won't
work. Is this just an exercise in one-upmanship? You know more ways the
world
is broken than I do?
It's not just that the world doesn't work that way now, it's quite likely
that
it'll never work that way (for the case of PKI/revocations mentioned in the
message, not the original SNI). We've been waiting for between 20 and 30
years (depending on what you define as the start date) for PKI to start
working, and your reponse seems to indicate that we should wait even harder.
If I look at the mechanisms we've got now, I can identify that commercial
PKI
isn't helping, and revocations aren't helping, and work around that. I'm
after effective practical solutions, not just a solution exists, QED
solutions.
The core problem appears to be a lack of will to fix the problems, not a
lack of feasible technical solutions.
I don't know why it should help that we find different solutions for the
world to ignore?
There seem to be at least three different questions here: bad code (i.e., that
Windows doesn't check the revocation status properly), the UI issue, and the
conceptual question of what should replace the current PKI+{CRL,OCSP} model.
For the last issue, I'd note that using pki instead of PKI (i.e., many
different per-realm roots, authorization certificates rather than identity
certificates, etc.) doesn't help: Realtek et al. still have no better way or
better incentive to revoke their own widely-used keys.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/28/2010 12:10 AM, Paul Tiemann wrote: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) cpf.digicert.com IN TXT v=cpf1 /^DigiCert/ -all Get the top 5 browsers to support it, and a lot of that any CA can issue to any domain risk goes way down. Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only) Is there a reason that opportunistic crypto (no cert required) hasn't been done for https? Would it give too much confidence to people whose DNS is being spoofed? Part of SSL was countermeasure to perceived weakness in domain name infrastructure ... is the server that I think I'm talking to really the server I'm talking to (things like ip-address hijacking). Now Certification Authorities typically aren't the authoritative agency for the information they are certifying ... they ask for a whole bunch of information from an SSL certificate applicant and then perform and expensive, time-consuming, and error-prone identification process, x-checking the supplied information with the information on-file at the domain name infrastructure as to the true owner of a domain (the same domain name infrastructure that has the weaknesses that SSL is designed as countermeasure). So ... something that could be backed by the Certification Authority industry as part of DNSSEC is to ask that all domain name applicants also register a public key as part of obtaining a domain name. domain name infrastructure then can required that all subsequent communication be digitally signed ... and can be verified with the onfile public key (as countermeasure to various kinds of domain name hijacking exploits, hijack domain and then apply for valid SSL certificate using dummy front company which matches the corrupted onfile information). The Certification Authority industry then could take advantage of the same infrastructure and require that all SSL domain name certificate applications, also be digitally signed (and can be verified with the onfile public key at the domain name infrastructure); replacing a time-consuming, expensive, error-prone identification process with an efficient, inexpensive, reliable authentication process. The catch-22 for the industry is if the Certification Authority industry could start doing real-time, online retrieval of public keys for authentication ... then maybe the rest of the world might also ... changing SSL to a certificateless, real-time, online publickey infrastructure. One of the possible reasons that it hasn't happened is there no startup, venture capital, IPO ... etc, gorp associated with such an incremental enhancement to the existing domain name infrastructure (it is a pure security/integrity play with no big financial motivation for anybody). W/o startup, venture capital, IPO play ... there is no big marketing budget to blitz the public on how much more comforting things would be (i.e. part of the reason that I coined the term merchant comfort certificates back in the early days). In the late 90s, we got visited by somebody that wanted to explain about the downside our comments could have on some pending Certification Authority IPO (much of internet hype from the period was actually part of IPO-mill money generating machine). I've posted frequently in the past about the catch-22 scenario for the certification authority industry. disclaimer: the inventor of domain name infrastructure did a stint at the science center a decade earlier ... working on various and sundry projects. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:38:17 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 09:57, Peter Gutmann wrote: In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). Again, citing the failure to use revocation correctly right now does not tell us anything much about the possibility of using it correctly in the future. The US Securities and Exchange Commission has long forced companies to state, when selling advisory services, that past performance is no indicator of future performance. However, I think that's pretty much clearly untrue in most disciplines. Empirical reasoning is entirely about observing and drawing conclusions based on what we observe. Virtually all of modern science comes, in fact, from observing what happens in the real world and extrapolating from it. After a few decades of trying to get PKI to work, we have failed to do so. At some point, one has to have very firm justifications for the belief that these decades of experience should be dismissed as mere experimental error. In another message you say: The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I'm unsure whether you are correct here, but I will point out that any solution which can never be deployed *is*, in fact, infeasible, and that if human beings cannot be convinced to use a particular solution (which is one form of the lack of will problem), then we might as well dismiss that solution. Now, I've been saying PKI can never be made to work for something like the last fifteen years. I was on a panel with Steve Kent at a Usenix workshop long ago, where I expressed the opinion that PKI very poorly models the actual legal and de facto relationships between parties, and I think that experience has borne that out. We've watched the rise and fall of substantial companies dedicated to trying to get PKI sold into enterprises, and the best efforts that Certco and Entrust and the like made were not enough. There is also considerable evidence that many of the technologies PKI requires, like reliable revocation, cannot be made to work, and whether that is because of a lack of will or because of something deeper, the fact is that these techniques have failed in practice over the course not of months or years but of decades, and we cannot ignore that forever. It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. I think we are at or even past that point with PKI. The odor of putrefaction is unmistakable. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Peter, In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. I can confirm that, at least for XP SP3: revocation just doesn't matter. What's even more worrying is the fact that one of the stuxnet/tmphider variants used the lnk exploit to install a dll signed w/ the (expired) Realtek key but w/ a *broken* signature in the first place. Still, it doesn't matter altough, as wireshark tells me, the host connects to microsoft.com in order to fetch certificates. When looking at the file properties, though, Windows tells you that this digital signature is not valid ... :-( Cheers, Stefan. -- Stefan Kelm sk...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Steven Bellovin s...@cs.columbia.edu writes: For the last issue, I'd note that using pki instead of PKI (i.e., many different per-realm roots, authorization certificates rather than identity certificates, etc.) doesn't help: Realtek et al. still have no better way or better incentive to revoke their own widely-used keys. I think the problems go a bit further than just Realtek's motivation, if you look at the way it's supposed to work in all the PKI textbooks it's: Time t: Malware appears signed with a stolen key. Shortly after t: Realtek requests that the issuing CA revoke the cert. Shortly after t': CA revokes the cert. Shortly after t'': Signature is no longer regarded as valid. What actually happened was: Time t: Malware appears signed with a stolen key. Shortly after t: Widespread (well, relatively) news coverage of the issue. Time t + 2-3 days: The issuing CA reads about the cert problem in the news. Time t + 4-5 days: The certificate is revoked by the CA. Time t + 2 weeks and counting: The certificate is regarded as still valid by the sig-checking software. That's pretty much what you'd expect if you're familiar with the realities of PKI, but definitely not PKI's finest hour. In addition you have: Time t - lots: Stuxnet malware appears (i.e. is noticed by people other than the victims) Shortly after t - lots: AV vendors add it to their AV databases and push out updates (I don't know what lots is here, it seems to be anything from weeks to months depending on which news reports you go with). So if I'm looking for a defence against signed malware, it's not going to be PKI. That was the point of my previous exchange with Ben, assume that PKI doesn't work and you won't be disappointed, and more importantly, you now have the freedom to design around it to try and find mechanisms that do work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann paul.tiemann.use...@gmail.com writes: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) That's the key-continuity model, which has been proposed a number of times for Firefox, for example here's a discussion by a FF developer from over two years ago on this, http://blog.johnath.com/2008/04/16/security-ui-in-firefox-3plus1/ (that's specific to FF, I don't know what the IE, Opera, Safari, ... guys talk about). There's no sign of it gaining any traction. I hate to be the perpetual wet blanket here but the problem isn't a lack of ideas (many backed by extensive real-world research) but a lack of motivation in browsers to change the security mechanisms and UI, most of which have remained essentially unchanged (except for cosmetic rearrangement of the chrome every release or so) since the debut of SSL in 1995. That's the mastodon in the room, we can debate ideas pretty much forever but if no browser vendor is interested in adopting any of them it isn't going to help secure users. (Having said that, it's fun to throw around ideas, so I'm not complaining about that bit). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. And still needs revocation. Is there a good replacement for pk for this purpose? -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. I agree with that fully. And still needs revocation. Does it? I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all. Is there a good replacement for pk for this purpose? I think public key cryptography is a wonderful thing. I'm just not sure I believe at all in PKI -- that is, persistent certification via certificates, certificate revocation, etc. PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28 July 2010 15:05, Perry E. Metzger pe...@piermont.com wrote: On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. I agree with that fully. And still needs revocation. Does it? I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all- The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote: PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. PKI alone is certainly not the answer to all our problems. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 10:05 AM, Perry E. Metzger wrote: I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all. long ago and far away ... one of the tasks we had was to periodically go by project athena to audit various activities ... including Kerberos. The original PK-INIT for kerberos was effectively certificateless public key ... aka replace registering a shared-secret password (for authentication) with a public key. There was then some amount of lobbying by the certification authority interests for pk-init to include certificate-based mode of operation (I wrote the draft-words for PK-INIT for inclusion of certificateless ecdsa). An issue with Kerberos (as well as RADIUS ... another major authentication mechanism) ... is that account-based operation is integral to its operation ... unless one is willing to go to a strictly certificate-only mode ... where all information about an individuals authority and access privileges are also carried in the certificate (and eliminate the account records totally). As long as the account record has to be accessed as part of the process ... the certificate remains purely redundant and superfluous (in fact, some number of operations running large Kerberos based infrastructure have come to realize that they have large redundant administrative activity maintaining both the account-based information as well as the duplicate PKI certificate-based information). The account-based operations have sense of revocation by updating the account-based records. This can be done in real-time and at much finer levels of granularity than the primitive, brute-force (PKI) revocation (and replacement). For instance, have you gone over your outstanding balance or credit-limit? ... are you up-to-date with you ISP account? ... or should it just be temporarily suspended bending receipt of funds. Account records can carry other kinds of real-time information ... like whether currently logged on ... and should duplicate, simultaneous logons be prevented (difficult to achieve with redundant and superfluous, stale, static certificates). The higher-value operations tend to be able to justify the real-time, higher quality, and finer grain information provided by an account-based infrastructure ... and as internet and technology has reduced the costs and pervasiveness of such operations ... it further pushes PKI, certificate-based mode of operation further and further into no-value market niches. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Perry, I think public key cryptography is a wonderful thing. I'm just not sure I believe at all in PKI -- that is, persistent certification via certificates, certificate revocation, etc. I'm sure you remember Peter Honeyman's PK-no-I talk from the '99 USENIX Security Symposium? :-) Cheers, Stefan. -- Stefan Kelm sk...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 15:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. And still needs revocation. It depends on what you mean by revocation, traditional revocation in the PKI sense isn't needed because (well apart from the fact that it doesn't work, you can't un-say something after you've already said it) if you look at what a PK or a cert is, it's just a capability, and the way to revoke (in the capability sense) a capability is to do something like rename the object that the capability refers to or use a level of indirection and break the link when you want to revoke (in the capability sense) the access. This means that no matter how many copies of the capability are floating around out there and whether the relying party checks CRLs or not, they're not going to be able to get in. Now you are talking my language! Have I mentioned that my new project at Google is all about finding good UI for exposing capabilities to users? Is there a good replacement for pk for this purpose? Which purpose? If you mean securing the distribution channel for binaries, here's a very simple one that doesn't need PK at all, it's called a self-authenticating URL. To use it you go to your software site, and here's a real-world example that uses it, the Python Package Index, and click on a download link, something like http://pypi.python.org/packages/package.gz#md5= (yeah, I know, it uses MD5...). This link can point anywhere, because the trusted source of the link includes a hash of the binary (and in this case it's a non-HTTPS source, you can salt and pepper it as required, for exammple make it an HTTPS link and use key continuity to manage the cert). In this form the concept is called link fingerprints, it was actually implemented for Firefox as a Google Summer of Code project, but then removed again over concerns that if it was present people might actually use it (!!). It's still available in DL managers like DownThemAll. The problem here is that it doesn't directly give me an upgrade path. Of course, I agree that this is sufficient to give me a link to the right binary, but what about its successors? Another option is to cryptographically bind the key to the URL, so you again have a trusted link source for your download and the link is to https://base64.downloadsite.com, where base64 is a fingerprint of the cert you get when you connect to the site. This does away with the need for a CA, because the link itself authenticates the cert that's used. Yes, this is of course the YURL scheme. Then there are other variations, cryptographically generated addresses, ... all sorts of things have been proposed. The killer, again, is the refusal of any browser vendor to adopt any of it. In the case of FF someone actually wrote the code for them, and it was rejected. Without support from browser vendors, it doesn't matter what cool ideas people come up with, it's never going to get any better. Peter. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 08:48:14AM -0400, Steven Bellovin wrote:
There seem to be at least three different questions here: bad code
(i.e., that Windows doesn't check the revocation status properly),
the UI issue, and the conceptual question of what should replace the
current PKI+{CRL,OCSP} model. For the last issue, I'd note that
using pki instead of PKI (i.e., many different per-realm roots,
authorization certificates rather than identity certificates, etc.)
doesn't help: Realtek et al. still have no better way or better
incentive to revoke their own widely-used keys.
With a sufficiently fine grained authorization model inside the OS,
there is no reason in principle that something like attribute
certificates couldn't work - RealTek would have a code signing cert
only valid for drivers that talked to network cards with specific PCI
vendors IDs, and UI tools that talked to that driver - the signature
on the worm binary in question would be valid, but the worm would not
be given the permissions it wants to actually do its thing. (Eg, when
was the last time you had a network driver that needed to access an
MSSQL db). Windows is not that OS. (Neither is Linux or BSD of
course). It looks like Singularity has some features which could
support this sort of model [1].
This is not to suggest this is at all an easy course of action to
take; my point is just that it's possible to do much better here
without having to alter anyone's incentives: the CAs still collect
their rent, and RealTek's drivers still work. Fixing the OS is
probably easier than somehow fixing PKI to do what we'd nominally want
it to do here (though actually revoking the cert would have been a
good start) or modifying the obvious incentives.
-Jack
[1] http://research.microsoft.com/apps/pubs/default.aspx?id=59976
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 03:16:32PM +0100, Ben Laurie wrote: Maybe it doesn't, but no revocation mechanism at all makes me nervous. I don't know Kerberos well enough to comment. DNSSEC doesn't have revocation but replaces it with very short signature lifetimes (i.e. you don't revoke, you time out). Kerberos too lacks revocation, and it also makes up for it with short ticket lifetimes. OCSP Responses are much like a PKI equivalent of Kerberos tickets. All you need to do to revoke a principal with OCSP is to remove it from the Responder's database or mark it revoked. To revoke an individual certificate you need only mark a date for the given subject such that no cert issued prior to it will be considered valid. An OCSP Responder implementation could be based on checking a real CRL or checking a database of known subjects (principals). Whichever is likely to be smaller over time is best, though the latter is just simpler to administer (since you don't need to know the subject public key nor the issuerserial, nor the actual TBSCertificate in order to revoke, just the subject name and current date and time). SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. This doesn't scale very well to SSL-style systems. The SSH ad-hoc pubkey model is a public key pre-sharing (for user keys) and pre-sharing and/or leap-of-faith (for host keys) model. It doesn't scale without infrastructure. Add infrastructure and you're back to a PKI-like model (maybe with no hierarchy, but still). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie b...@google.com wrote: On 28 July 2010 15:05, Perry E. Metzger pe...@piermont.com wrote: On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: And still needs revocation. Does it? I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all Maybe it doesn't, but no revocation mechanism at all makes me nervous. I think that is because you are thinking in terms of certificates, which naturally would require such a mechanism. I don't know Kerberos well enough to comment. In kerberos, tickets are short lived -- one can simply fail to give the person who stole a credential new ones, and in the interim, one can remove the authorization that a particular principal has. DNSSEC doesn't have revocation but replaces it with very short signature lifetimes (i.e. you don't revoke, you time out). Yes. Precisely. SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. No, that's not what SSH does, or rather, it confuses the particular communications channel (i.e. some out of band mechanism) with the method that actually de-authorizes the key. The point is that in SSH, if a key is stolen, you remove it from the list of keys allowed to log in to a host. The key now need never be thought about again. We require no list of revoked keys be kept, just as we required no signed list of keys that were authorized. We just had some keys in a database to indicate that they were authorized, and we removed a key to de-authorize it. This doesn't scale very well to SSL-style systems. I believe it does scale. Pretty much by definition, if you can get to a web site, your Internet connectivity is working. That means that there is no need for methods like having a signed key that lasts for years so you can cache it for offline use. I'm sure you remember the 1960s and 1970s well, as we are both a bit past our youth. In the US, at least, every store clerk had in their hands an unwieldy, telephone-book sized list of stolen credit card numbers they had to consult at each credit card transaction. In those days, there were no cheap modems and doing on-line verification was impossible. The whole point of Kohnfelder's thesis was, in effect, to turn the 1970s era books of stolen numbers into an offline machine readable list. You signed a long-lived credential so that it could be checked offline, and you kept a big book of withdrawn credentials around so you could check them offline as well. It was a model from the era in which everyone had a paper phone book. It was designed for the era where networks were a rarity. We no longer live in that era. The models used by Kerberos, DNSSEC, SSH, and such, make far more sense. We no longer need revocation. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
deliberately crashing ancient computers (was: Re: A mighty fortress is our PKI)
On Tue, 27 Jul 2010, Jack Lloyd suggested: http://www.crashie.com/ - if you're feeling malicious, just include the one line JavaScript that will make IE6 crash, maybe eventually the user will figure it out. (Or maybe not). Please stop and think about the consequences before using something like this! People who are still using IE6, Windows 95, etc, are usually doing so for reasons which make sense in their lives, things like (a) very low computer literacy (b) slow/unreliable internet connections (dialup?) (c) old/small/slow computer ( lack of money to buy a better one) (d) English not her/his native language (to read your how-to-upgrade msg) (e) that's what all their friends professional colleagues use These people are unlikely to change just because your site makes their computer crash. (They're also unlikely to distinguish between IE6 crashed and the computer crashed, and yes, they're likely to blame your website for the problem.) I too would love to see IE6 die. Ditto Windows 95. But I don't think actively trying to crash my colleague Professor X's computer is either ethical or an appropriate solution to her ancient computer environment. (She is elderly, retired, lives in a very poor country in South America, and has only dialup internet. The local computer shops/geeks where she lives usually recommend Windows 95 for upgrades/reinstalls. I don't know what web browser they pitch...) Ultimately though, the only thing that's going to get some people off IE6 is the machines they are running it off of finally dying, either due to hardware failure or being so badly owned by worms that the machine becomes inoperable, at which point it goes into the trash and they buy a new one. Yup. -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 10:42:43AM -0400, Anne Lynn Wheeler wrote:
On 07/28/2010 10:05 AM, Perry E. Metzger wrote:
I will point out that many security systems, like Kerberos, DNSSEC and
SSH, appear to get along with no conventional notion of revocation at all.
long ago and far away ... one of the tasks we had was to periodically
go by project athena to audit various activities ... including
Kerberos. The original PK-INIT for kerberos was effectively
certificateless public key ...
And PKINIT today also allows for rp-only user certs if you want them.
They must be certificates, but they needn't carry any useful data beyond
the subject public key, and the KDC must know the {principal,
cert|pubkey} associations.
An issue with Kerberos (as well as RADIUS ... another major
authentication mechanism) ... is that account-based operation is
integral to its operation ... unless one is willing to go to a
strictly certificate-only mode ... where all information about an
individuals authority and access privileges are also carried in the
certificate (and eliminate the account records totally).
This is true time you have rp-only certs or certs that carry less
information than the rp will require. The latter almost always true.
The account can be local to each rp, however, or centralized -- that's
up to the relying parties.
As long as the account record has to be accessed as part of the
process ... the certificate remains purely redundant and superfluous
(in fact, some number of operations running large Kerberos based
infrastructure have come to realize that they have large redundant
administrative activity maintaining both the account-based information
as well as the duplicate PKI certificate-based information).
Agreed. Certificates should, as much as possible, be rp-only.
The account-based operations have sense of revocation by updating the
account-based records. [...]
Exactly. OCSP can work in that manner. CRLs cannot. In terms of
administration updating an account record is much simpler than updating
a CRL (because much less information needs to be available for the
former than for the latter).
The higher-value operations tend to be able to justify the real-time,
higher quality, and finer grain information provided by an
account-based infrastructure ... and as internet and technology has
reduced the costs and pervasiveness of such operations ... it further
pushes PKI, certificate-based mode of operation further and further
into no-value market niches.
Are you arguing for Kerberos for Internet-scale deployment? Or simply
for PKI with rp-only certs and OCSP? Or other federated
authentication mechanism? Or all of the above? :)
Nico
--
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 16:01, Perry E. Metzger wrote: On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie b...@google.com wrote: SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. No, that's not what SSH does, or rather, it confuses the particular communications channel (i.e. some out of band mechanism) with the method that actually de-authorizes the key. The point is that in SSH, if a key is stolen, you remove it from the list of keys allowed to log in to a host. The key now need never be thought about again. We require no list of revoked keys be kept, just as we required no signed list of keys that were authorized. We just had some keys in a database to indicate that they were authorized, and we removed a key to de-authorize it. I am referring to the SSH host key. Fully agree for user keys. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote: PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. PKI alone is certainly not the answer to all our problems. Infrastructure Let me interrupt here and say that when I refer to PKI, I mean the Kohnfelder model which we have been following, which is the model of very long lived phone books of hierarchically issued certificates along with very long lived lists of revoked certificates, all designed with an offline world in mind. I have no objections to infrastructure -- bridges, the Internet, and electrical transmission lines all seem like good ideas. However, lets avoid using the term Public Key Infrastructure for things that depart radically from the Kohnfelder and subsequent X.509 models. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. Well, it depends a lot on what kind of trust. Let me remind everyone of one of my long-standing arguments. Say that Goldman Sachs wants to send Morgan Stanley an order for a billion dollars worth of bonds. Morgan Stanley wants to know that Goldman sent the order, because the consequences of a mistake on a transaction this large would be disastrous. Should they trust Verisign's ExtraSuperHighValue certificate presented by Goldman? No. Why? Because Verisign disclaims all effective liability for the use of its certs. It is not a party to the transaction being conducted. If it was actually insuring all transactions conducted with the certificate, then Morgan could trust them, because the counterparty who's credit would be at issue would no longer be Goldman but Verisign. However, Verisign won't even pay out if it turned out that they gave signed a Goldman cert and it was in fact held by a scammer. The problem with Certification Authorities is they certify NOTHING. There can be no reliance on them, because they have no liability of any sort in any transaction. So, in the real world, Goldman and Morgan come up with ways of making sure they trust each other's communications and credit lines. Even when we're dealing with small transactions, like buying a book at a book store with a credit card, if you trace it out, we're dealing with nothing but a web of bilateral commercial relationships. So, I have no trouble with various kinds of trust. What I have trouble with is the sort of false trust that a CA implies. CAs certify nothing in a real world business sense -- they are just toll collectors. However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. I believe we may, in fact, be in violent agreement here. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: deliberately crashing ancient computers (was: Re: A mighty fortress is our PKI)
On Wed, Jul 28, 2010 at 11:04:30AM -0400, Jonathan Thornburg wrote: On Tue, 27 Jul 2010, Jack Lloyd suggested: http://www.crashie.com/ - if you're feeling malicious, just include the one line JavaScript that will make IE6 crash, maybe eventually the user will figure it out. (Or maybe not). Please stop and think about the consequences before using something like this! People who are still using IE6, Windows 95, etc, are usually doing so for reasons which make sense in their lives, things like [...] Personally I'm not planning on doing anything one way or another to encourage or discourage people using IE6. In the spectram of social badness, I'd view using IE6 roughly on par with using heroin - a bad idea that mostly hurts oneself with some limited (albeit real) negative externalities. As with using drug rehabilitation versus prison sentences to reduce use, the real solution to IE6 is education and assistance for those who want it, not punishment. Some will, for whatever reason, choose to ignore said educational/assistance efforts, and eventually will take the consequences of their actions without any antics by you or I. And certainly I have better things to do with my time than crash a decade-old browser. Thanks, Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 11:13:36AM -0400, Perry E. Metzger wrote: On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: I have no objections to infrastructure -- bridges, the Internet, and electrical transmission lines all seem like good ideas. However, lets avoid using the term Public Key Infrastructure for things that depart radically from the Kohnfelder and subsequent X.509 models. Well, OK. But PKI no longer means that, not with bridges and what not in the picture. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. Well, it depends a lot on what kind of trust. Let me remind everyone of one of my long-standing arguments. Say that Goldman Sachs wants to send Morgan Stanley an order for a billion dollars worth of bonds. Morgan Stanley wants to know that Goldman sent the order, because the consequences of a mistake on a transaction this large would be disastrous. Indeed. They must first establish a direct trust relationship. They might leverage transitive trust to bootstrap direct trust if doing so makes the process easier (which it almost certainly does, and which we use in the off-line world all the time using pieces of paper or plastic issued by various authorities, such as drivers' licenses, passports, ...). However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. I believe we may, in fact, be in violent agreement here. We are. Perhaps I hadn't made my point obvious enough: transitive trust is necessary, but primarily as a method of bootstrapping direct trust relationships. I really should have used that specific formulation. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 11:05 AM, Nicolas Williams wrote: Are you arguing for Kerberos for Internet-scale deployment? Or simply for PKI with rp-only certs and OCSP? Or other federated authentication mechanism? Or all of the above? :) as i've mentioned ... the relying-party-only certificates are almost always redundant and superfluous ... except in cases where the relying party can't justify their own repository of information and/or distributed access to such a repository of information. I previously mentioned that in the payment transaction case, even a relying-party-only certificate was a factor of 100-times payload size bloat for typical payment transactions ... aka not only was the certificate redundant and superfluous ... but it represented an enormous (redundant and superfluous) processing burden. I've mentioned a number of times that OCSP appeared after I had repeatedly ridiculed revokation process being archaic backwards step for real-time payment processes. And that even OCSP (with a certificate) is still redundant and superfluous when real-time transaction is being performed using the real information. the other scenario for rpo-certs ... besides for no-value operations ... is when the real infrastructure is down and/or not accessible. But that usually is matter of cost also, some of the higher-value operations have gone to significant redundancy and claim 100% availability. The certificate analogy is still the letters of credit/introduction from sailing ship days ... when the relying-party had no (other) access to first time interaction with complete stranger (and has to fall back to much cruder and lower quality information). There is also some scenario if the respository and the service are co-located ... that when the repository is unavailable the service will also be unavailable ... so there is no requirement for independent source of information. The catch22 for certification authority operation ... is that as they move further further into the no-value market niches (and/or market niches that can't justify the expense of higher quality operation with real-time repository) ... they are forced to cut their fees and indirectly the quality of their operation. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Introduction, plus: Open Transactions -- digital cash library
On Jul 28, 2010, at 8:56 AM, Patrick Chkoreff wrote: Yeah, it does blinding. Cool. Thanks. Cheers, RAH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. Specifically, if I submit a freshly-issued, valid certificate to an OCSP responder and ask is this a valid certificate then it can't say yes, and if I submit an Excel spreadsheet to an OCSP responder and ask is this a valid certificate then it can't say no. It takes quite some effort to design an online certificate status protocol that's that broken. (For people not familiar with OCSP, it can't say yes because a CRL can't say yes either, all it can say is not on the CRL, and it can't say no for the same reason, all it can say is not on the CRL. The ability to say vslid certificate or not valid certificate was explicitly excluded from OCSP because that's not how things are supposed to be done). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 10:50:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote: On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: OCSP Responses are much like a PKI equivalent of Kerberos tickets. All you need to do to revoke a principal with OCSP is to remove it from the Responder's database or mark it revoked. Actually, that's untrue in one very important respect. In a Kerberos style system, you actively ask for credentials to do things at frequent intervals, and if the KDCs refuse to talk to you, you get no credentials. In OCSP, we've inverted that. You have the credentials, for years in most cases, and someone else has to actively check that they're okay -- and in most instances, if they fail to get through to an OCSP server, they will simply accept the credentials. No, they really are semantically equivalent. Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Peter Gutmann has pointed out other critical distinctions, but I'll let his message stand for itself. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Nicolas Williams nicolas.willi...@oracle.com writes: Sorry, but this is wrong. The OCSP protocol itself really is an online certificate status protocol. It's not an online certificate status protocol because it can provide neither a yes or a no response to a query about the validity of a certificate. (For an online status protocol I want to be able to submit a cert and get back a straight valid/not valid response, exactly as I can for credit cards with their authorised/declined response. Banks were doing this twenty years ago with creaky mainframes over X.25 and (quite probably) wet bits of string, but we still can't do this today with multicore CPUs and gigabit links if we're using OCSP). Responder implementations may well be based on checking CRLs, but they aren't required to be. They may be, or they may not be, but you as a relying party have no way of telling. OCSP covers not only the three incompatible business models of the different authors' employers but, for good measure, an extra anything else you may care to do option if the first three aren't enough. A decade after it was published, PKI experts are still arguing over what various bits of the OCSP spec actually mean (the PKIX list has only just gone through yet another round of this... *ten years* later and domain experts still can't agree on how it's supposed to work). So given the schizophrenic nature of the RFC you can easily claim but you can do X because chances are if you read it just right you probably can. Unfortunately this doesn't give a relying party much to rely on, because they have absolutely no idea what they're getting, it could be anything from a live database query to a value from a month-old CRL to (thanks to the removal of nonces from the protocol a few years ago) an attacker replaying an old not-revoked value (although I don't know why they'd even bother with that, given the state of revocation checking in client software). In any event though since OCSP can't say yes or no, it doesn't matter whether the response is coming from a live database or a month-old CRL, since it's still a fully CRL-bug-compatible blacklist I can trivially avoid it with a manufactured-cert attack. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Jul 27, 2010, at 10:58 PM, d...@geer.org wrote: Wow, I was just going to recommend Dan's book, Security Metrics. It is actually Andy Jaquith's book, I only wrote the intro. Ouch, I'm sorry for the mistake! (I knew I remembered your name in connection with the book, but it's on my bookshelf in the office and I was at home.) In the meantime, though, couple of years ago I did a tutorial on security metrics which you may find useful http://geer.tinho.net/measuringsecurity.tutorial.pdf Thanks, my favorite so far is page 45 with the table on Risk Management Culture. I need to tape that to the wall for inspiration. Pathologic: Don't want to know Bureaucratic: May not find out Generative: Actively seek Pathologic: Failures punished Bureaucratic: Local repairs only Generative: Failures beget reforms From my point of view: The security community is being Generative (Actively seek) about finding the flaws in systems, but it's too often in the Pathologic (Failures punished) stage about how to handle those flaws once they're discovered. My suspicion: It's fun to Actively seek, and hard to find solutions, and it can be downright frustrating to champion reforms. If the vulnerability isn't gigantic, it's hard to even get people to listen. Reform is maybe 20x harder and 1/5th as fun as poking the holes. That said, here's an experience worth talking about: Dan Kaminsky did a pretty good job of being Generative in _both_ categories. He found a hole in DNS, and then worked with LOTS of vendors and even with people not directly tied to DNS to collaborate on reforms. He even called me (at a smaller CA) to make sure we were aware of the risks and to verify that we don't only rely on automated forms of verification. I really appreciated the call--it felt like my chance to talk to a rock star. All the best, Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:23:16 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 11:20:51AM -0500, Nicolas Williams wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. Also, requiring OCSP will probably take less effort than switching from PKI to Kerberos. In other words: eveything sucks. I wouldn't suggest that everything on earth move to Kerberos. I mentioned Kerberos only to show that entirely different models are possible. As to OCSP being a reasonable solution because it can be deployed easily, it clearly will not solve the browser security problem. So long as security depends on reliance on the lowest common denominator among the policies of hundreds of CAs, many of which are quite questionable, and so long as the certifications made by even the best of those CAs are effectively meaningless, and so long as the users are well trained to ignore every browser warning they ever get, the entire question of OCSP is somewhat irrelevant -- it would just be a way of spritzing the skunk with eau de cologne. I fully recognize that the odds we will fix the browser security problem are very low, if only because no one can deploy a truly new solution in a world where we can't even get IE 6 to die. However, in discussing this at a high level, as though we could improve things, we shouldn't kid ourselves about the current model. It is fatally broken. Hanging garlands from the corpse's ears will not convince anyone that it has a vibrant future ahead. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 12:02 PM, Nicolas Williams wrote: Sorry, but this is wrong. The OCSP protocol itself really is an online certificate status protocol. Responder implementations may well be based on checking CRLs, but they aren't required to be. Don't be confused by the fact that OCSP borrows some elements from CRLs. my OCSP analogy was turning authentication into an end in itself ... basically a new kind of retail store ... instead of retail store that sells some product ... you go in and buy something ... doing a real-time payment transaction; ... there is an authentication store ... convince everybody that they need to walk into their (OCSP) authentication retail store at least once a day to perform an authentication operation (for no other reason that people should get a lot of comfort out of being authenticated at least once a day or more if necessary) ... totally divorced and unrelated to any actual business purpose. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Thu, Jul 29, 2010 at 04:23:52AM +1200, Peter Gutmann wrote:
Nicolas Williams nicolas.willi...@oracle.com writes:
Sorry, but this is wrong. The OCSP protocol itself really is an online
certificate status protocol.
It's not an online certificate status protocol because it can provide neither
a yes or a no response to a query about the validity of a certificate.
You should be more specific. I'm looking at RFC2560 and I don't see
this.
OCSP Responses allow the Responder to assert:
- A time at which the given cert was known to be valid (thisUpdate;
REQUIRED).
Relying parties are free to impose a freshness requirement (e.g.,
thisUpdate must be no more than 5 minutes in the past).
Perhaps you're concerned that protocols that allow for carrying OCSP
Responses don't provide a way for peers to indicate what their
freshness requirements are?
- A time after which the given OCSP Response is not to be considered
valid (nextUpdate, which is OPTIONAL).
- The certificate's status (certStatus, one of good, revoked, unknown;
REQUIRED).
How is responding certStatus=good, thisUpdate=now - a few minutes
not a yes response to a query about the validity of a certificate?
What am I missing?
(For an online status protocol I want to be able to submit a cert and get back
a straight valid/not valid response, exactly as I can for credit cards with
their authorised/declined response. Banks were doing this twenty years ago
with creaky mainframes over X.25 and (quite probably) wet bits of string, but
we still can't do this today with multicore CPUs and gigabit links if we're
using OCSP).
OCSP gives you that. Seriously. In fact, an OCSP Responder either must
not respond or it must give you at least {certStatus, thisUpdate}
information about a cert. Yes, certStatus can be unknown, but a
Responder that regularly asserts certStatus=unknown would be a rather
useless responder.
Responder implementations may well be based on checking CRLs, but they aren't
required to be.
They may be, or they may not be, but you as a relying party have no way of
telling.
And why would a relying party need to know internal details of the OCSP
Responder?
In any event though since OCSP can't say yes or no, it doesn't matter whether
the response is coming from a live database or a month-old CRL, since it's
still a fully CRL-bug-compatible blacklist I can trivially avoid it with a
manufactured-cert attack.
Manufactured cert attack? If you can mint certs without having the CA's
private key then who cares about OCSP. If you can do it only as a
result of hash collisions, well, switch hashes. Let's not confuse hash
collision issues with whether OCSP does what it's advertised to do.
Nico
--
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? I mention this only because your language here is quite sticky. Saying it is up to the relying parties is incorrect. It is really up to a host of people who are nowhere near the relying parties. In most cases, the relying parties aren't even capable of understanding the issue. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 01:25:21PM -0400, Perry E. Metzger wrote: My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? I mention this only because your language here is quite sticky. Saying it is up to the relying parties is incorrect. It is really up to a host of people who are nowhere near the relying parties. In most cases, the relying parties aren't even capable of understanding the issue. Precise and concise language in a fast moving thread with participants with diverse backgrounds is going to be hard to come by. Better to quit than hold out for that (unless you enjoy being disappointed). I'm hardly the only sinner here on that score. up to the relying parties means up to the browsers, where users-as- relying-parties are concerned. That also means getting software updated, which to some degree means getting my mom to do stuff she doesn't and shouldn't have to know how. It shouldn't mean getting my mom to enable OCSP -- that would be hopeless. up to the relying parties means up to the server as well, since servers too are relying-parties. Again, if everything is too hard, why do we bother even talking about any of this? ETOOHARD cannot usefully be a retort to every suggestion. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 12:38:10 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: Again, if everything is too hard, why do we bother even talking about any of this? ETOOHARD cannot usefully be a retort to every suggestion. Well, not everything is too hard. In fact, one of the important characteristics of systems that work is that they're simple, and thus tractable. We were just discussing the problem of needing users to make fine grained security decisions. Several obvious solutions exist here. For example, the there should be one mode, and it should be secure rule lowers the complexity users encounter quite a bit. I know of at least one project to fix the browser PKI mess which claims that they want to involve the users more, not less. This would seem to be a big mistake to me. On the other edge of the spectrum, many people now use quite secure protocols (though I won't claim the full systems are secure -- implementation bugs are ubiquitous) for handling things like remote login and file transfer, accessing shared file systems on networks, etc., with little to no knowledge on their part about how their systems work or are configured. This seems like a very good thing. One may complain about many issues in Microsoft's systems, for example, but adopting Kerberos largely fixed the distributed authentication problem for them, and without requiring that users know what they're doing. Yet another reason (one of dozens) that X.509 has never worked right for most users is the sheer number of knobs. There are too many choices for mortals, and there will always be subtle configuration failures that can catch even experts. (I am reminded of the similar death-by-complexity of the IPSec protocol's key management layers, where I am sad to report that even I can't easily configure the thing. Some have proposed standardizing on radically simplified profiles of the protocol that provide almost no options -- I believe to be the last hope for the current IPSec suite.) Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 02:41:35PM -0400, Perry E. Metzger wrote: On the other edge of the spectrum, many people now use quite secure protocols (though I won't claim the full systems are secure -- implementation bugs are ubiquitous) for handling things like remote login and file transfer, accessing shared file systems on networks, etc., with little to no knowledge on their part about how their systems work or are configured. This seems like a very good thing. One may complain about many issues in Microsoft's systems, for example, but adopting Kerberos largely fixed the distributed authentication problem for them, and without requiring that users know what they're doing. Hear, hear! But... great for corporate networks, not quite for Internet-scale, but a great example of how we can make progress when we want to. (I am reminded of the similar death-by-complexity of the IPSec protocol's key management layers, where I am sad to report that even I can't easily configure the thing. Some have proposed standardizing on radically simplified profiles of the protocol that provide almost no options -- I believe to be the last hope for the current IPSec suite.) IPsec is a great example of another kind of failure: lack of APIs. Applying protection to individual packets without regard to larger context is not terribly useful. Apps have no idea what's going on, if anything, in terms of IPsec protection. Worse, the way in which IPsec access control is handled means that typically many nodes can claim any given IP address, which dilutes the protection provided by IPsec as the number of such nodes goes up. Just having a way to ask that a TCP connection's packets all be protected by IPsec, end-to-end, with similar SA pairs (i.e., with same peers, same transforms) would have been a great API to have years ago. The lack of APIs has effectively relegated IPsec to the world of VPN. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 5:51 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. Specifically, if I submit a freshly-issued, valid certificate to an OCSP responder and ask is this a valid certificate then it can't say yes, and if I submit an Excel spreadsheet to an OCSP responder and ask is this a valid certificate then it can't say no. It takes quite some effort to design an online certificate status protocol that's that broken. OCSP is even better for an attacker. As the OCSP responses are unauthenticated[1], you can be easily fake the response with what ever the attacker likes. http://www.thoughtcrime.org/papers/ocsp-attack.pdf [1] Would be silly to run OCSP over SSL ;-) -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance -- that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 28, 2010, at 9:51 AM, Peter Gutmann wrote: Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. This isn't true for all OCSP services. For example, DigiCert's is not CRL based, so it really can say Yes and it really can say Unknown meaningfully. (For people not familiar with OCSP, it can't say yes because a CRL can't say yes either, all it can say is not on the CRL, and it can't say no for the same reason, all it can say is not on the CRL. The ability to say vslid certificate or not valid certificate was explicitly excluded from OCSP because that's not how things are supposed to be done). True for off-the-shelf OCSP responders that base themselves on CRL. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 14:40:14 -0600 Paul Tiemann paul.tiemann.use...@gmail.com wrote: On Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote: On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? That might depend. I tell Firefox to use OCSP if a responder is referenced in the certificate, and I check that little checkbox that says When an OCSP connection fails, treat the certificate as invalid. I believe you've missed an important point. First, my mother would never understand what that box means. Second, my mother has no control over whether the CA provides OCSP. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
