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
On Jul 27, 2010, at 21:14, d...@geer.org wrote: > >> False metrics are rampant in the security industry. We really need >> to do something about them. I propose that we make fun of them. > > > You might consider joining us in D.C. on 10 August at > http://www.securitymetrics.org/content/Wiki.jsp?page=Metricon5.0 If you are in Europe, you might also want to consider joining us in Madrid on (very likely) February 11, 2011 at http://distrinet.cs.kuleuven.be/events/essos2011/program/SecurityPredictions.html > --dan, program committee Stephan, program committee - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Ben Laurie 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 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 > Date: July 28, 2010 1:52:28 AM AST > To: agile-banking > 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 ins
Re: A mighty fortress is our PKI, Part II
Ben Laurie 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 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 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 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 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 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 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 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 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 wrote: > On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie 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
Ben Laurie 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. >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. 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://.downloadsite.com, where 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. 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. - 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 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 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://.downloadsite.com, where 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 issuer&serial, 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 wrote: > On 28 July 2010 15:05, Perry E. Metzger wrote: > > On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie 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]" 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 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 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 > 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: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams 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. OCSP is hung on to the side of X.509 as an afterthought, so it cannot be enforced as part of the system. In Kerberos, the online aspect is burned into the protocol and cannot be avoided. There is no such thing as a Kerberos installation that chooses not to use KDCs. > > 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). There are two parts to the SSH model that should be segregated in discussions. One part is the "I've seen this one before" key validation model. I think there is merit in parts of that for many sorts of systems (say, secure email), and it is also worth discussing, but there is a second thing here which is usually ignored that I would prefer to concentrate on for now. The other part, which is very important, is the "we authorize keys by storing them in a database, we de-authorize them by removing them" model. This is typically used by Kerberized apps as well, though Kerberos doesn't generally impose a particular authorization model. Now, to some people, the "the key is in the database" model might seem trivial, or obvious, or otherwise insignificant. I think that's a mistake -- it is a critical part of what makes SSH work so well. The system is not relying on an old signature on a data structure around the key to say that the key is authorized. The system relies on something much simpler: keeping an up to date database of what keys are allowed. We can change that database at will, in real time. In this model, some external protocol might or might not be available to automate maintenance of that database, and the database might or might not be local to the host, but that part is conceptually entirely separate. The important part is that we are not relying on cryptography to handle the authorization -- we are not going to let someone in because a third party signed something last year. Cryptography handles only proving that someone holds a particular private key -- it isn't even handling authentication of a party per se. We decide to give privileges to the holder of that private key because a database check performed right now showed the particular key was in the database as authorized. I believe this way of doing things deserves much closer scrutiny. It is far simpler. It is far easier to understand the security properties of such a system. There are far fewer systems whose compromise will compromise the authorization decision. These are under-appreciated features. Perry -- Perry E. Metzgerpe...@piermont.com - 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 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, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
> 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. In Kerberos (traditional,
pre-PKINIT Kerberos) the long-term credential is {principal name,
long-term secret key} or {principal name, password}, and the temporary
credential is the Kerberos Ticket. In PKI+OCSP the long-term credential
is {certificate, private key}, and the temporary credentials is
{certificate, private key, fresh OCSP Response}.
Both, Kerberos and PKI+OCSP replace a long-term credential with a
short-lived, temporary credential authenticating the same principal.
> OCSP is hung on to the side of X.509 as an afterthought, so it cannot
> [...]
Yes, but it's still "morally equivalent" to Kerberos as described above,
but with PK instead of KDCs and shared secret keys.
Also, PKI+OCSP is somewhat less dependent on online infrastructure than
Kerberos because: a) just one OCSP Response will do[*], vs. a multitude
of service Tickets, b) OCSP Responders don't need access to the CA's
private key, whereas the KDCs do need access to the TGS keys. Also,
OCSP Responses can be cached by the network, whereas Kerberos Tickets
cannot be (since they are useless[**] without the corresponding session
key).
[*] It helps to have protocols where subjects can send OCSP responses
for their own certs to their peers. It also helps to have
protocols where client subjects can get OCSP Responses for their
own certs from their peers and then re-use those Responses later.
[**] I'm ignoring user-to-user authentication here.
-
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 03:51:33AM +1200, Peter Gutmann wrote: > Nicolas Williams 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). 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. 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 10:50:52 -0500 Nicolas Williams 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 > > 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
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. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Nicolas Williams 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 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 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="
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 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 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 wrote: > Nicolas Williams 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 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 Jul 28, 2010, at 10:23 AM, Peter Gutmann wrote: > Nicolas Williams 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. It might not be hard to determine whose OCSP responders are CRL based and whose are database backed instead. > 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). Yes we can, and some actually do. >> 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. Even the most savvy of relying parties probably has no way of caring. They want to know when something is positively revoked, and having a definitive Yes is a nice distinction, but having a definitive Not-Revoked appears to be good enough for most. > 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. You're right: a manufactured-cert attack is going to really hurt that kind of an OCSP responder. Is a manufactured-cert a trivial thing to create? 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 Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote: > On Wed, 28 Jul 2010 11:20:52 -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. > > 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." True, if you don't have that checkbox marked, then Firefox will take a failed OCSP check attempt (connection refused, socket timeout, etc) as a success. What it ought to do is try the CRL(s) listed in the certificate too, and if both don't work then it really ought to error. 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 Jul 28, 2010, at 10:37 AM, Perry E. Metzger wrote: > 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. "it will CLEARLY not solve the browser security problem." "the certifications made by even the best of those CAs are effectively MEANINGLESS" "the users are well trained to ignore EVERY browser warning they EVER get" "the ENTIRE question of OCSP is somewhat irrelevant." "spritzing the SKUNK with eau de cologne." "hanging garlands from the corpses ears." That's all expressed in very certain terms. Is OCSP _that_ hopeless? You were kind enough to suggest Orwell to Jay at Edgecast (and possibly also to me.) I read it, liked it, and I'm glad you sent it. I sincerely think we can all learn from these two references: A great essay by Neil Postman: http://criticalsnips.wordpress.com/2007/07/22/neil-postman-bullshit-and-the-art-of-crap-detection/ And Ben Franklin's advice, with one paragraph excerpted below: http://grammar.about.com/b/2009/06/01/how-to-argue-like-ben-franklin-and-lieutenant-columbo.htm And as the chief Ends of Conversation are to inform or to be informed, to please or to persuade, I wish well-meaning sensible men would not lessen their Power of doing Good by a Positive assuming Manner that seldom fails to disgust, tends to create Opposition, and to defeat every one of those Purposes for which Speech was given to us, to wit, giving or receiving Information or Pleasure: For If you would inform, a positive dogmatical Manner in advancing your Sentiments, may provoke Contradiction & prevent a candid Attention. If you wish Information and Improvement from the Knowledge of others and yet at the same time express your self as firmly fix'd in your present Opinions, modest sensible Men, who do not love Disputation, will probably leave you undisturb'd in the Possession of your Error; and by such a Manner you can seldom hope to recommend your self in pleasing your Hearers, or to persuade those whose Concurrence you desire. (Part One of The Autobiography of Benjamin Franklin, 1793; from The Library of America edition of Benjamin Franklin: Writings, 1987) 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 14:40:14 -0600 Paul Tiemann wrote: > > On Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote: > > > On Wed, 28 Jul 2010 11:20:52 -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. > > > > 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
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 15:30:08 -0600 Paul Tiemann wrote: > > 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. > > "it will CLEARLY not solve the browser security problem." > "the certifications made by even the best of those CAs are > effectively MEANINGLESS" "the users are well trained to ignore > EVERY browser warning they EVER get" "the ENTIRE question of OCSP > is somewhat irrelevant." "spritzing the SKUNK with eau de cologne." > "hanging garlands from the corpses ears." I stand by all the things I said above, other than the apparent lack of an apostrophe in "corpse's". I realize it isn't moderate language, but on the other hand, my meaning is unmistakable. > That's all expressed in very certain terms. We've been watching the slow motion accident very closely for a couple of decades now. If that isn't long enough to develop certainty, I don't know how many years would suffice. To believe we can fix the mess now would be to ignore twenty years of experience. > Is OCSP _that_ hopeless? I believe you misunderstand me. I'm not talking about OCSP. I'm saying the entire X.509 certificate infrastructure used in web browsers is hopeless. OCSP is just one small hopeless component of a hopeless whole. (I don't think things are particularly better in other applications of the system, but there are almost no other widely used applications beyond code signing anyway. S/MIME and the rest are not merely dead but nearly forgotten.) There are multiple completely fatal flaws in the system. Any one of them alone would suffice. To repeat just a few: 1) The user's security depends on the security of the worst CA in the system. If there is any dispute about this, I would like to know on what basis. There should be no dispute that CAs have certified things they should not have, and will do so again. There should be no dispute that some CAs have been sold and their keys subsequently passed around under less than ideal circumstances. There should be no dispute that not all CAs are what would be universally considered trustworthy organizations. 2) Users have been trained by too many false alarms to ignore all browser warnings. If you don't believe me, there are fine papers about what real users do when exposed to warnings, and they ignore them. Users also have no real ability to understand the error messages even if they did still care about them. 3) Revocation in the face of compromise is, as a practical matter, nearly impossible. 4) CAs as a practical matter disclaim all liability and are not, in fact, insuring anything in the sense of insurance. 5) The third party attestation idea is wrong as it does not properly model the actual trust relationships and liability among the parties. 6) The entire idea of signed attestations that last for years is based on a pre-Internet, largely offline model of security. There is more, but why should we belabor it? The parrot is not pining for the fjords. I'm only surprised that the nails have kept it vertical for so long. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
A slight modification of my comments on PKI.
A coda on today's voluminous discussion of X.509, browser security, etc. It is important to remember what we're trying to defend against. As many of us have learned through bitter experience, the costs and benefits of security systems we deploy are the important part. No one needs perfect security in the face of no attackers at all, and even if attackers are numerous, if a system has low enough failure/fraud rates, no one will complain much. The problem is that the system we've built to date is, in fact, yielding pretty high fraud rates. Attacking people is a full time profitable business for a lot of people, not a rare sort of thing. Stolen credentials are sold in the market for very low prices because there is a glut of them. Yes, the majority of online transactions are trouble free, but a shocking fraction of them are not, and the majority of people I know have had a card stolen at least once online. Things like bank account credential phishing are not only possible but prevalent. All this may get worse. The cost is a large fraction of the fees we all end up paying, directly and indirectly, to do business. What we would like is to get from the situation we are in now (which reminds me in certain ways of the days of analog cellphone service where cloning was trivial) to a situation where fraud still happens but is much more difficult to pull off. (Certainly phone fraud still happens, but it is no longer anything like it was in the NAMPS days and the cost is manageably low.) This would also have the benefit of radically reducing the number of people who can make a living as professional attackers, which would have all sorts of salutary effects. To lower the fraud rate by significant margins, I think we'll need to make some serious changes in the security systems we deploy. Logging in to your bank's web site using a password protected by an SSL session requires that too many things all go right and that the user pay attention to whether they have all gone right. We need simpler systems where, if the user is not paying attention, nothing much bad can happen to them anyway. No system can be perfect, but we could do a lot better than we are doing now. I think this is achievable in theory. Whether it can happen in practice, I have my doubts, though we can but try. 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 Jul 28, 2010, at 9:22 29AM, Peter Gutmann wrote: > Steven Bellovin 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. When I look at this, though, little of the problem is inherent to PKI. Rather, there are faulty communications paths. You note that at t+2-3 days, the CA read the news. Apart from the question of whether or not "2-3 days" is "shortly after" -- the time you suggest the next step takes place -- how should the CA or Realtek know about the problem? Did the folks who found the offending key contact either party? Should they have? The AV companies are in the business of looking for malware or reports thereof; I think (though I'm not certain) that they have a sharing agreement for new samples. (Btw -- I'm confused by your definition of "t" vs. "t-lots". The first two scenarios appear to be "t == the published report appearing"; the third is confusing, but if you change the timeline to "t+lots" it works for "t == initial, unnoticed appearance in the wild". Did the AV companies push something out long before the analysis showed the stolen key?) Suppose, though, that Realtek has some Google profile set up to send them reports of malware affecting their anything. Even leaving aside false positives, once they get the alert they should do something. What should that something be? Immediately revoke the key? The initial reports I saw were not nearly specific enough to identify which key was involved. Besides, maybe the report was not just bogus but malicious -- a DoS attack on their key. They really need to investigate it; I don't regard 2-3 days as unreasonable to establish communications with an malware analysis company you've never heard of and which has to verify your bonafides, check it out, and verify that the allegedly malsigned code isn't something you actually released N years ago as release 5.6.7.9.9.a.b for a minor product line you've since discontinued. At that point, a revocation request should go out; delays past that point are not justifiable. The issue of software still accepting it, CRLs notwithstanding, is more a sign of buggy code. The point about the communications delay is that it's inherent to anything involving the source company canceling anything -- whether it's a PKI cert, a pki cert, a self-validating URL, a KDC, or magic fairies who warn sysadmins not to trust certain software. What's interesting here is the claim that AV companies could respond much faster. They have three inherent advantages: they're in the business of looking for malware; they don't have to complete the analysis to see if a stolen key is involved; and they can detect problems after installation, whereas certs are checked only at installation time. Of course, speedy action can have its own problems; see http://www.pcworld.com/businesscenter/article/194752/few_answers_after_mcafee_antivirus_update_hits_intel_others.html for a recent example, but there have been others. Note that I'm not saying that PKI is a good solution. But it's important to factor out the different contributing factors in order to understand w
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 10:03:08PM +0200, Alexandre Dulaunoy wrote: > On Wed, Jul 28, 2010 at 5:51 PM, Peter Gutmann > wrote: > > Nicolas Williams 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% > > [...] The protocol allows for more than simple proxy checking of CRLs. What implementations do is another matter (which matters, of course, but be sure to know what you're condemning, the implementations or the protocol, as they're not the same thing). > 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 ;-) This is a rather astounding misunderstanding of the protocol. An OCSPResponse does contain unauthenticated plaintext[*], but that plaintext says nothing about the status of the given certificates -- it only says whether the OCSP Responder was able to handle the request. If a Responder is not able to handle requests it should respond in some way, and it may well not be able to authenticate the error response, thus the status of the responder is unauthenticated, quite distinctly from the status of the certificate, which is authenticated. Obviously only successful responses are useful. The status of a certificate (see SingleResponse ASN.1 type) most certainly is covered by the signature: SingleResponse is part of ResponseData, which is the type of tbsResponseData, which is what the signature covers. Don't take my word for it, nor that paper's author's. Read the RFC and decide for yourself. [*] It's not generally possible to avoid unauthenticated plaintext completely in cryptographic protocols. The meaning of a given bit of unauthenticated plaintext must be taken into account when analyzing a cryptographic protocol. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A slight modification of my comments on PKI.
> It is important to remember what we're trying to defend against. As > many of us have learned through bitter experience, the costs and > benefits of security systems we deploy are the important part. No one > needs perfect security in the face of no attackers at all, and even if > attackers are numerous, if a system has low enough failure/fraud > rates, no one will complain much. The design goal for any security system is that the number of failures is small but non-zero, i.e., N>0. If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Calibration requires differing outcomes. Regulatory compliance, on the other hand, stipulates N==0 failures and is thus neither calibratable nor cost effective. Whether the cure is worse than the disease is an exercise for the reader. --dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 2010-07-28, Jerry Leichter wrote: There is, of course, the problem of knowing when a signature was stolen! Or in economic terms, asymmetric information. Can we for example learn something from the way insurers and the like who've been dealing with that for centuries solve the problem? And then apply it to protocol/market design? -- Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: A slight modification of my comments on PKI.
d...@geer.org wrote: Regulatory compliance, on the other hand, stipulates N==0 failures and is thus neither calibratable nor cost effective. Whether the cure is worse than the disease is an exercise for the reader. I do not believe regulations require that there be zero compromises to systems, Dan. On the contrary, I believe the goal of any regulation is to ensure that there is a minimum level of calibration across the industry. In the absence of regulation, calibration would be all over the map; while experienced companies with adequate resources might be better calibrated, the less-experienced or less-resourceful companies would start the dominoes falling and inadvertently bring down even the well calibrated companies. Regulations can help with preventing that first domino from falling if implemented effectively. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
