Re: A mighty fortress is our PKI, Part III
On 2010-09-16 6:12 AM, Andy Steingruebl wrote: The malware could just as easily fake the whole UI. Is it really PKI's fault that it doesn't defend against malware? Did even the grandest supporters ever claim it could/did? That is rather like having a fortress with one wall rather than four walls, and when attackers go around the back, you quite correctly point out that the wall is only designed to stop attackers from coming in front. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: A mighty fortress is our PKI, Part III
I, too, would love to get the details, but Peter is right here. The flaw he reported was in the PKI itself, not in the UI. If there were a bulletproof OS with perfect non-confusing UI, once the malware has a valid signature that traces to a valid certificate, it's the PKI that failed. As for EV being as meaningless as ordinary certificates, that's the point Peter is making. Of course, neither of them certifies the qualities of the publisher that the end user cares about. That would be too expensive and open to liability (therefore, more expensive still). But, in a verbal shell game, the CAs make it sound like someone with an expensive certificate is trustworthy (in the end-user's value system). -Original Message- From: owner-cryptogra...@metzdowd.com [mailto:owner-cryptogra...@metzdowd.com] On Behalf Of Andy Steingruebl Sent: Wednesday, September 15, 2010 4:12 PM To: Peter Gutmann Cc: cryptography@metzdowd.com Subject: Re: A mighty fortress is our PKI, Part III On Wed, Sep 15, 2010 at 8:39 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Some more amusing anecdotes from the world of PKI: Peter, Not to be too contrary (though at least a little) - not all of these are really PKI failures are they? - There's malware out there that pokes fake Verisign certificates into the Windows trusted cert store, allowing the malware authors to be their own Verisign. The malware could just as easily fake the whole UI. Is it really PKI's fault that it doesn't defend against malware? Did even the grandest supporters ever claim it could/did? - CAs have issued certs to cybercrime web sites like https://www.pay-per-install.com (an affiliate program for malware installers), because hey, the Russian mafia's money is as good as anyone else's. Similarly here - non-EV CAs bind DNS names to a field in a certificate. No more. They don't vouch for the business being run, and in any case any such audit would be point in time anyway. I suppose way back when people promised that certs would do this, but does anyone believe that anymore and have it as an expectation? Perhaps you're setting the bar a bit high? BTW - do you have pointers to most of the things you've reported? I'd love to get the full sordid details :) - Andy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part III
On Wed, Sep 15, 2010 at 8:39 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Some more amusing anecdotes from the world of PKI: Peter, Not to be too contrary (though at least a little) - not all of these are really PKI failures are they? - There's malware out there that pokes fake Verisign certificates into the Windows trusted cert store, allowing the malware authors to be their own Verisign. The malware could just as easily fake the whole UI. Is it really PKI's fault that it doesn't defend against malware? Did even the grandest supporters ever claim it could/did? - CAs have issued certs to cybercrime web sites like https://www.pay-per-install.com (an affiliate program for malware installers), because hey, the Russian mafia's money is as good as anyone else's. Similarly here - non-EV CAs bind DNS names to a field in a certificate. No more. They don't vouch for the business being run, and in any case any such audit would be point in time anyway. I suppose way back when people promised that certs would do this, but does anyone believe that anymore and have it as an expectation? Perhaps you're setting the bar a bit high? BTW - do you have pointers to most of the things you've reported? I'd love to get the full sordid details :) - Andy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Aug 17, 2010, at 4:20 AM, Peter Gutmann wrote: Your code-signing system should create a tamper-resistant audit trail [0] of every signature applied and what it's applied to. Peter. [0] By this I don't mean the usual cryptographic Rube-Goldbergery, just log the details to a separate server with a two-phase commit protocol to minimise the chances of creation of phantom non-logged signatures. ...thus once again demonstrating how much of good cryptographic practice is just good engineering/release management practice. A number of years ago, in addition to being in charge of much of the software development, I had the system management organization of the small software maker I worked at reporting to me. I formalized a process that the (already well run) organization already had in place. Any time *any* build of the software left the building, even if just for a demo, we marked that build as locked. We would never delete a locked build without a careful determination that it was, in fact, dead: No longer in use at any customer. We also, within 24 hours, did a special backup of the build onto a tape that went into permanent off-site storage. The one time I know of that we didn't follow these procedures (before they were officially put into place), a very large customer, at their insistence and after the sales guy who dealt with them swore they agreed to delete the copy we gave them, got a snapshot of a build from a developer's workstation just to see how the new version would look. Without telling us, the customer proceeded to roll this out at hundreds of sites, resulting in years of support grief, since it was impossible for us to determine exactly what went into the code they were running. We were later acquired by a much larger company that claimed they would teach us how to do big-league software engineering. Hah. That company was shipping software built on developer workstations as a day-to-day practice - they were just beginning to develop mechanisms to ensure that the stuff they shipped came through traceable, reproducible builds. Oh ... but their stuff was in Java, so was signed The signing was tightly controlled at a central location. Cue classic joke about using an armored car to deliver an envelope to someone living in a cardboard box. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Aug 04, 2010 at 10:46:44PM -0700, Jon Callas wrote: I think you'll have to agree that unlike history, which starts out as tragedy and replays itself as farce, PKI has always been farce over the centuries. It might actually end up as tragedy, but so far so good. I'm sure that if we look further, the Athenians had the same issues with it that we do today, and that Sophocles had his own farcical commentary. If you want to see a PKI tragedy in the making, have a look at the CRLs used by the US DoD. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Thor Lancelot Simon t...@rek.tjls.com writes: If you want to see a PKI tragedy in the making, have a look at the CRLs used by the US DoD. Only in the making? Actually it's all relative, in Japan the Docomo folks turned off CRLs because they found that even a relatively modest CRL (not just the DoD monsters) presented a nice DoS when sent over cellular data links. What happened was that as the CRLs grew, performance got worse and worse as the phone downloaded the CRL. It took them quite some time to diagnose that they were being DoS'd by their own PKI. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Zeus malware used pilfered digital certificate http://www.computerworld.com/s/article/9180259/Zeus_malware_used_pilfered_digital_certificate Zeus Malware Used Pilfered Digital Certificate http://www.pcworld.com/businesscenter/article/202720/zeus_malware_used_pilfered_digital_certificate.html Zeus malware used pilfered digital certificate http://www.networkworld.com/news/2010/080610-zeus-malware-used-pilfered-digital.html from above: The version of Zeus detected by Trend Micro had a digital certificate belonging to Kaspersky's Zbot product, which is designed to remove Zeus. The certificate -- which is verified during a software installation to ensure a program is what it purports to be -- was expired, however. ... snip ... Certificate Snatching—ZeuS Copies Kaspersky’s Digital Signature http://blog.trendmicro.com/certificate-snatching-zeus-copies-kasperskys-digital-signature/ ... there was another scenario of certificate-copying ( dual-use vulnerability) discussed in this group a while ago. The PKI/certificate bloated payment specification had floated the idea that that when payment was done with their protocol, dispute burden-of-proof would be switched placed on the consumer (from the current situation where burden-of-proof is on the merchant/institution; this would be a hit to REG-E ... and also apparently what has happened in the UK with the hardware token point-of-sale deployment). However, supposedly for this to be active, the payment transaction needed a consumer appended digital certificate that indicated they were accepting dispute burden-of-proof. The issue was whether the merchant could reference some public repository and replace the digital certificate appended by the consumer ... with some other digital certificate for the same public key (possibly digital certificate actually obtained by the consumer for that public key at some time in the past ... or an erroneous digital certificate produced by a sloppy Certification Authority that didn't adequately perform check for applicant's possession of the corresponding private key). Of course, since the heavily bloated PKI/certificate payment specification, performed all PKI-ops at the internet boundary ... and then passed a normal payment transaction with just a flag claiming that PKI-checking had passed ... they might not need to even go that far. There was already stats on payment transactions coming thru with the flag on ... and they could prove no corresponding PKI-checking had actually occurred. With the burden-of-proof on consumer ... the merchant might not even have to produce evidence that the appended digital certificates had been switched. -- 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 2010-08-05 11:30 AM, David-Sarah Hopwood wrote: Signatures are largely a distraction from the real problem: that software is (unnecessarily) run with the full privileges of the invoking user. By all means authenticate software, but that's not going to prevent malware. A lot of devices are locked down so that you cannot install bad software. This is somewhat successful in preventing bad software from being installed, and highly successful in irritating users. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
And what else should Windows say? We put this through our time machine and noticed that at some time in the past it was signed and now it isn't? Absolutely, on initial install there's no way to know it was originally signed (if you're smart about it). But in another architecture Microsoft makes available (ClickOnce) software _upgrades_ that _were_ initially signed - but now are not - do not give indication that something fishy is going on. -tom - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
David-Sarah Hopwood david-sa...@jacaranda.org writes: Huh? I don't understand the argument being made here. It's a bogus argument, the text says: He took a legitimate software package and removed the signature of the digital certificate it contained, then installed the package on his computer. The Installer application didn't indicate that the certificate had been modified. The certificate wasn't modified, they just stripped the signature from the executable. Only an expert will be able to detect a problem, Schouwenberg said. And all Microsoft will tell you is that the file is not signed. And what else should Windows say? We put this through our time machine and noticed that at some time in the past it was signed and now it isn't? The rest of the story isn't much better: The Stuxnet worm, which surfaced last month, used fake Verisign digital certificates No, they were genuine certs, just in the wrong hands. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 30, 2010, at 4:58 AM, Peter Gutmann wrote: [0] I've never understood why this is a comedy of errors, it seems more like a tragedy of errors to me. That is because a tragedy involves someone dying. Strictly speaking, a tragedy involves a Great Person who is brought to their undoing and death because of some small fatal flaw in their otherwise sterling character. In contrast, comedies involve no one dying, but the entertaining exploits of flawed people in flawed circumstances. PKI is not a tragedy, it's comedy. No one dies in PKI. They may get embarrassed or lose money, but that happens in comedy. It's the basis of many timeless comedies. Specifically, PKI is a farce. In the same strict definition of dramatic types, a farce is a comedy in which small silly things are compounded on top of each other, over and over. The term farce itself comes from the French to stuff and is comedically like stuffing more and more feathers into a pillow until the thing explodes. So farces involve ludicrous situations, buffoonery, wildly improbable / implausible situations, and crude characterizations of well-known comedic types. Farces typically also involve mistaken identity, disguises, verbal humor including sexual innuendo all in a fast-paced plot that doesn't let up piling things on top of each other until the whole thing bursts at the seams. PKI has figured in tragedy, most notably when Polonius asked Hamlet, What are you signing, milord? and he answered, OIDs, OIDs, OIDs, but that was considered comic relief. Farcical use of PKI is far more common. We all know the words to Gilbert's patter-song, I Am the Very Model of a Certificate Authority, and Wilde's genius shows throughout The Importance of Being Trusted. Lady Bracknell's snarky comment, To lose one HSM, Mr. Worthing, may be regarded as a misfortune, but lose your backup smacks of carelessness, is pretty much the basis of the WebTrust audit practice even to this day. More to the point, not only did Cyrano issue bogus short-lived certificates to help woo Roxane, but Mozart and Da Ponte wrote an entire farcical opera on the subject of abuse of issuance, EV Fan Tutti. There are some who assert that he did this under the control of the Freemasons, who were then trying to gain control of the Austro-Hungarian authentication systems. These were each farcical social commentary on the identity trust policies of the day. Mozart touched upon this again (libretto by Bretzner this time) in The Revocation of the Seraglio, but this was comic veneer over the discontent that the so-called Aluminum Bavariati had with the trade certifications in siding sales throughout the German states, as well as export control policies since Aluminum was an expensive strategic metal of the time. People suspected the Freemasons were behind it all yet again. Nonetheless, it was all farce. Most of us would like to forget some of the more grotesque twentieth-century farces, like the thirties short where Moe, Larry, and Shemp start the Daddy-O DNS registration company and CA or the 23 Skidoo DNA-sequencing firm as a way out of the Great Depression. But S.J. Perleman's Three Shares in a Boat shows a real-world use of a threshold scheme. I don't think anyone said it better than W.C. Fields did in Never Give a Sucker an Even Break and You Can't Cheat an Honest Man. I think you'll have to agree that unlike history, which starts out as tragedy and replays itself as farce, PKI has always been farce over the centuries. It might actually end up as tragedy, but so far so good. I'm sure that if we look further, the Athenians had the same issues with it that we do today, and that Sophocles had his own farcical commentary. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Jon Callas j...@callas.org writes: But S.J. Perleman's Three Shares in a Boat Uhh. minor nitpick, it was Jerome K.Jerome who wrote Three Shares in a Boat. He followed it up with Three Certificates on the Bummel, a reference to the sharing of commercial vendors' code-signing keys with malware authors. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Aug 4, 2010, at 11:29 PM, Peter Gutmann wrote: Jon Callas j...@callas.org writes: But S.J. Perleman's Three Shares in a Boat Uhh. minor nitpick, it was Jerome K.Jerome who wrote Three Shares in a Boat. He followed it up with Three Certificates on the Bummel, a reference to the sharing of commercial vendors' code-signing keys with malware authors. Oh, well. You are, of course, correct. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
TLS/SSL Survey (Ristic/Qualsys) (was: Re: A mighty fortress is our PKI)
Internet SSL Survey 2010 is here! (blog post) http://blog.ivanristic.com/2010/07/internet-ssl-survey-2010-is-here.html Actual report: Qualys Internet SSL Survey 2010 v1.6 (PDF, 3.2 MB) http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf =JeffH - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Kaspersky: Sham Certificates Pose Big Problem for Windows Security http://www.ecommercetimes.com/story/70553.html from above .. Windows fails to clearly indicate when digital security certificates have been tampered with, according to Kaspersky Lab's Roel Schouwenberg, and that opens a door for malware makers. ... snip ... -- 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
Anne Lynn Wheeler wrote: Kaspersky: Sham Certificates Pose Big Problem for Windows Security http://www.ecommercetimes.com/story/70553.html from above .. Windows fails to clearly indicate when digital security certificates have been tampered with, according to Kaspersky Lab's Roel Schouwenberg, and that opens a door for malware makers. Huh? I don't understand the argument being made here. Obviously Windows can't distinguish an unsigned executable from one where the was a signature that has been stripped. How could it possibly do that? Signatures are largely a distraction from the real problem: that software is (unnecessarily) run with the full privileges of the invoking user. By all means authenticate software, but that's not going to prevent malware. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com signature.asc Description: OpenPGP digital signature
Re: A mighty fortress is our PKI, Part II
On 7/28/10 at 8:52 PM, pfarr...@pfarrell.com (Pat Farrell) wrote: When was the last time you used a paper Yellow Pages? Err, umm, this last week. I'm in a place where cell coverage (ATT, Verizon has a better reputation) is spotty and internet is a dream due to a noisy land line. I needed to find a ceramic tile store. The paper yellow pages had survived being left in the driveway in the rain and I used it. However, I agree that this is the 2% case for many parts of the world. Cheers - Bill --- Bill Frantz|Web security is like medicine - trying to do good for 408-356-8506 |an evolved body of kludges - Mark Miller www.periwinkle.com | - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/28/2010 08:55 AM, Anne Lynn Wheeler wrote: disclaimer: the inventor of domain name infrastructure did a stint at the science center a decade earlier ... working on various and sundry projects. other public key science center trivia; former RSA CEO also at science center ... following recent entry from his blog: http://smartphonestechnologyandbusinessapps.blogspot.com/2010/05/bob-creasy-invented-virtual-machines-on.html lots of past posts mentioning science center, 4th flr, 545 tech sq http://www.garlic.com/~lynn/subtopic.html#545tech a couple old emails from 1981 ... discussing a certificate-less, PGP-like implementation for the internal network http://www.garlic.com/~lynn/2007d.html#email810506 http://www.garlic.com/~lynn/2006w.html#email810515 ... aka the internal network was larger than the arpanet/internet from just about the beginning until sometime late '85 or early '86. one big difference from arpanet/internet was corporation required all links to be encrypted ... and in the mid-80s there was the claim that the internal network had over half of all hardware link encryptors in the world ... only practical solution at the time. I was running multiple T1 links in the period ... and DES-encryption processing for sustained full-duplex traffic from a single T1 link was more than enough to consume multiple mainframe processors. old email on the subject (regarding doing some benchmarking of DES software encrypt/decrypt) http://www.garlic.com/~lynn/2006n.html#email841115 past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet -- 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
At 07:16 AM 7/28/2010, 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. This doesn't scale very well to SSL-style systems. Unfortunately, there _are_ ways that it can scale adequately. Bank of America has ~50 million customers, so J. Random Spammer sends out 500 million emails saying Bank of America is updating our security procedures, please click on the following link to update your browser. It's more efficient for BofA to send out the message themselves, only to actual subscribers, with the actual keys, helping to train them to accept phishing mail in the process, but apparently even doing it the hard way scales well enough for some people to make money. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann paul.tiemann.use...@gmail.com writes: What if... Firefox (or other) could introduce a big new feature (safety controls) and ask you up front: Do you want to be safer on the internet? The problem is that neither the browser vendor nor the users will see it like this. For the user its: Do you want to have lots of sites that you normally use break? For the browser vendor its: Do you want lots of your users to become frustrated when things stop working for them so that they switch to another browser? Is there a good reason Firefox and other browsers shouldn't just get tough about [various sensible security measures] None of the non-IE browsers can afford to do this because people will just switch back to IE, and this has been observed in usability testing of proposed browser security features by HCI researchers, as soon as anything goes wrong the users switch back to IE, which allows pretty much anything through. You can even get IE as a plugin for other browsers (shudder) in order to make things work. So you'd need to get the change made in IE (or at least get it made in such a manner that fallback-to-IE is no longer an option). I don't know what size hammer you'd need to wield in order to get that done. This isn't true for all OCSP services. For example, DigiCert's is not CRL based, so it really can say Yes It can't say yes because the only thing OCSP can say is not revoked (and in more general terms the only thing a blacklist can say is not on the blacklist). Not revoked doesn't mean valid, it just means not in the blacklist. and it really can say Unknown meaningfully. Unknown is generally treated by client apps as good, because if revoked maps to bad then anything else must map to good (OCSP's muddle of non- orthogonal response types is yet another perpetual motion-machine debate topic among PKI people). It might not be hard to determine whose OCSP responders are CRL based and whose are database backed instead. How can you do this? Note that the various timestamps in OCSP responses are as big a mess as the rest of OCSP, and can't be relied upon for any decision- making. More importantly, how can you possibly make any meaningful decisions in time- critical protocols based on a system for which your responses can have come from any time in the past? As one security architect commented some years ago, learning in 80ms that the certificate was good as of a week ago and to not hope for fresher information for another week seems of limited, if any, utility to us or our customers. The problem here is best seen by looking at certificates as capabilities. 1. You have an abitrary and unknown number of capabilities floating around out there. 2. Some of those capabilities (CA certs) have the ability to mint new capabilities. 2a. These capabilities can impersonate existing capabilities, and because of (1) the real issuer of the capabilities has no idea that they exist. And the means of dealing with these unknown numbers of arbitraily-identified capabilities is... a blacklist. There's no way this can possibly, ever work. It's the 1960s credit-card model that Perry mentioned with the added twist that there are an unknown number of cards and issuers involved, and some of the cards can invent new cards whenever they feel like it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Steven Bellovin s...@cs.columbia.edu writes: When I look at this, though, little of the problem is inherent to PKI. Rather, there are faulty communications paths. Oh no my Lord, I assure you that parts of it are excellent! :-). [...] how should the CA or Realtek know about the problem? [...] That was the whole point, that the whole system doesn't work, and it's the system as a whole that has to work, not just some parts of it. Here's another description, without the possibly confusing 't +/- x' stuff: Shortly after the malware appeared (or at least got noticed) it was added to anti-virus vendor databases and pushed out to users via updates. Some time later when it made headlines because of its use of the Realtek certificate, the CA that had issued it read about it in the news, contacted the certificate owner, and revoked it. However due to the dysfunctional nature of revocation handling, the certificate was still regarded as valid by Windows systems after it had been revoked, and of a range of machines running Windows 7, Vista, and XP, all with the latest updates and hotfixes applied and with automatic updates turned on, the first machine to notice the revocation and treat the signature as invalid didn't do so until a full week after the revocation had occurred, and some machines still regard the signature as valid even now (I've heard this before a number of times in software developer forums and mailing lists, plaintive complaints from users to the effect that I know this certificate is revoked, but no matter what I do I can't get the software to stop using it!). So while PKI and code-signing promise the user a fairly deterministic series of events in which A occurs, the B occurs, then C occurs, and then the user is safe, what actually happens in practice is that A occurs, then a comedy of errors ensues [0], and then the user is still unsafe while possibly being under the mistaken impression that they're actually safe. [0] I've never understood why this is a comedy of errors, it seems more like a tragedy of errors to me. A real-world demonstration of the relative effectiveness of various protection mechanisms occurred when I wanted to evaluate the ability of code-signing to protect users. A researcher sent me a copy of the signed malware (thanks!), and because of its nature encrypted it with AES using the RAR archiver. Because RAR (and indeed most other archivers) don't protect file metadata, the message was blocked by email scanners that identified the overall contents from the metadata even though the file contents themselves were encrypted. After some discussion with the IT people (yes, I am certain what the file is, it's a rather nasty piece of Windows malware, and I trust the sender to have sent me malware) they forwarded the email to the PowerPC Linux machine on which I read email, and which is rather unlikely to be affected by x86 Windows malware. Unfortunately I never could check it on the Windows system that I wanted to test it on because the instant it appeared on there the resident malware protection activated and deleted it again, despite various attempts to bypass the protection. Eventually I got it onto a specially-configured Windows system, which reported that both the signature and its accompanying certificate were valid (this is now two weeks after the CA had declared the certificate revoked). So it actually proved quite difficult to see just how ineffective PKI and code-signing actually was in protecting users from malware because the real protection mechanisms were so effective at doing their job. (It's also rather an eye-opener about the effectiveness, at least in some cases, of malware-protection software, no matter what I did I couldn't get the malware files onto a Windows PC in order to have the code-signing declare them valid and, by implication, perfectly safe). What's interesting here is the claim that AV companies could respond much faster. I'd say it's more than just a claim, the malware was first detected around 1 1/2 months ago and added to AV vendor databases, a full month later the certificate was declared revoked by the CA, and currently the majority of Windows systems still regard the signature as valid (I've had a report from someone else of one machine that records it as revoked, so at least one machine has been belatedly protected by the code signing, assuming the user doesn't just click past the warning as pretty much all of them will). So yes, I'd say the AV companies respond a helluva lot faster, and a helluva lot more effectively. The bigger lesson, for people who ever believed this to be the case, is don't rely on code signing to protect you from malware. Peter. - 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:52 PM, Pat Farrell wrote: A lot of the smart card development in the mid-90s and beyond was based on the idea that the smart card, in itself, was the sole authorization token/algorithm/implementation. some ssl, payment, smartcard trivia ... those smartcards were used for the offline authorization (not just authentication) ... which, in at least one major product, led to the YES CARD ... relatively trivial to skim replicated a static digital certificate for a counterfeit card ... then the counterfeit card was programmed to answer YES to 1) was the correct PIN entered, 2) should the transaction be performed offline, and 3) was the transaction approved. Once the static digital certificate was skimmed, it was no longer even necessary to know the PIN, since the counterfeit card accepted every possible PIN as valid. misc. past posts mentioning YES CARD http://www.garlic.com/~lynn/subintegrity.html#yescard In a 2003, at an ATM Integrity task force meeting ... there was presentation by some LEO explaining the yes card ... and how there was little or no countermeasure once a YES CARD was in existence ... somebody in the audience loudly observed that billions were spent on proving smartcards are less secure than magstripe. In the YES CARD timeframe there was even a rather large pilot of the cards in the US ... but seemed to disappear after the YES CARD scenario was publicized (it was actually explained to the people doing the pilot, before the pilot started ... but apparently they didn't appreciate the significance). much earlier, we had been working on our ha/cmp product and cluster scaleup. we had meeting on cluster scaleup meeting during jan92 sanfran usenet (in ellison's conference room) ... past posts mentioning the jan92 meeting http:www/garlic.com/~lynn/95.html#13 this was just a few weeks before cluster scaleup was transferred (announced as supercomputer for numerical intensive only) and we were told we couldn't work on anything with more than four processors. some old email from the period on cluster scaleup http://www.garlic.com/~lynn/lhwemail.html#medusa we then leave a couple months later. two of the other people named in the jan92 meeting also leave and show up at small client/server startup responsible for something called commerce server. we get brought in to consult because they want to do payment transactions on the server ... the small client/server startup has also invented some technology called SSL they want to use. The results is now frequently called electronic commerce. Then apparently because of the work on electronic commerce ... we also get invited to participate in the x9a10 financial standard working group ... which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. About the same time there is a pilot program for magstripe-based online stored-value cards (uses existing POS magstripe terminals but the payment network routes the transactions to different backend processor, original program of its kind in the US). At the time, the US didn't have the telco connectivity availability and cost issues that many places in the rest of the world were dealing with ... and therefor didn't have that requirement to move to offline smartcard payment paradigm. However, it turns out their backend, high-availability, no-single-point-of-failure platform developed a glitch ... and even tho it was from a different vendor (than our ha/cmp product) we were asked to investigate at the various failure modes. Somewhat as a result of all of the above, when one of the major offline, smartcard, european, stored-value payment operators was looking at making an entry into the US in the 90s ... we were asked to design, size, and cost their backend dataprocessing infrastructure. Along the way, we took an indepth look at the business process and cost structure of such payment products. Turns out that the major financial motivation for that generation of smartcard stored-value payment products ... was that the operators got to keep the float on the value resident in the stored-value cards. Not too long later ... several of the major european central banks announced that the smartcard, stored-value operators would have to start paying interest on value in the smartcards (eliminating the float financial incentive to those operators). It wasn't too long after that most of the programs disappeared. The major difference between that generation of smartcard payment products and the AADS chip strawman ... was that rather than attempting to be a complex, loadable, multi-function issuer card the objective was changed to being a person-centric, highest-possible integrity, lowest-possible cost, hard-to-counterfeit authentication ... which could be registered (publickey) for arbitrary number of different environments (something you have authentication registered in manner analogous to
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 08:44 PM, Steven Bellovin wrote: 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? [snip] 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. While I'm quoting Steve, his comment really drives me to a bigger break. I'd like to build on this and make a more fundamental change. The concept of a revocation cert/message was based on the standard practices for things like stolen credit cards in the early 1990s. At the time, the credit card companies published telephone book sized listings of stolen and canceled credit cards. Merchant's had the choice of looking up each card, or accepting a potential for loss. A lot of the smart card development in the mid-90s and beyond was based on the idea that the smart card, in itself, was the sole authorization token/algorithm/implementation. How about we posit that there is networking everywhere? People carry cell phones that are serious computers and are connected to serious networks. When was the last time you used a paper Yellow Pages? How about thinking of a solution that addresses 98% of all transactions for 98% of all people in the places where 98% of business is done. At some point, the perfect is the enemy of the good. If you have a selling hut in the middle of nowhere, well, you probably don't have a lot of computer power either. So calculating to do an RSA signature is out of the question anyway. A risk based approach would have an algorithm that looks at the value of the transaction. Buying a meal at a fast food place is not worth a lot of effort, so the definition of shortly after can be a second or so. Buying new 3D TV can have a longer time, with the time allowance, and expected/acceptable response time, perhaps time for automated actuarial analysis. When you are signing a contract to buy a house, you can take a day to verify that everything is proper. We have fast computers and ubiquitous networking. Why are we still thinking about systems based on 3 inch think paper books? We seem to be solving a problem that no longer exists when you look at it from first principals. Pat -- Pat Farrell http://www.pfarrell.com - 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 3:09 AM, Nicolas Williams nicolas.willi...@oracle.com wrote: 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. I agree on this and but the implementation of OCSP has to deal with all non definitive (to take the wording of the RFC) answers. That's where the issue is. All the exception case, mentioned in 2.3, are all unauthenticated and it seems rather difficult to provide authenticated scheme for that part as you already mentioned in [*]. That's why malware authors are already adding fake entries of OCSP server in the host file... simple and efficient. I just wanted to raise the point that a model like PK-i relying on complex scheme for security will easily fail at the obvious as the attacker is often choosing the shortest/fastest path to reach his goal. [*] 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. -- -- 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 2010-07-29 12:18 AM, Peter Gutmann wrote: 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. Bittorrent links have this property. A typical bittorent link looks like magnet:?xt=urn:btih:2ac7956f6d81bf4bf48b642058d31912479d8d8edn=South+Park+S14E06+201+HDTV+XviD-FQM+%5Beztv%5Dtr=http%3A%2F%2Fdenis.stalker.h3q.com%3A6969%2Fannounce It is the equivalent of an immutable file in Tahoe. 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. The browser vendors are married to the CAs - 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 Jul 28, 2010, at 11:04 AM, Jonathan Thornburg wrote: 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 I agree 100% with the statement that deliberately crashing other people's computers is inappropriate. Don't do that. But the reasons you give for why there are still IE6 installations out there (low computer literacy, slow connections, etc.) aren't quite right. Apparently there are many internally-developed applications at companies that are IE6-only. Often, these were developed by outside consultants for customers who have no internal development staff. These things keep the business running, and replacing them would be a large expense that the companies involved are not in a position to incur. One of the biggest and most visible of such applications was the one that the national realtor's organization used to allow its members to get access to listings. They resisted doing anything about that for many years. (I understand that within the last year or so, they finally had to respond to complaints from their members and redo the site.) It will be many years before these internal applications disappear. They are in a class similar to embedded systems, where replacement of working stuff is almost never done, and support obligations on long-obsolete software run for decades. Microsoft would love to forget that IE6 ever existed - what was once their way of dominating much of the Internet has turned into a millstone around their necks; but they can't. (Analogies to The Ring of Sauron come to mind) An interesting benefit that some of the businesses with IE6-only internal software are finding is that, if they keep their employee's machines IE6-only, their employees are increasingly unable to access most Internet sites. Talk about perverse incentives -- Jerry - 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:52 PM, Pat Farrell wrote: I'd like to build on this and make a more fundamental change. The concept of a revocation cert/message was based on the standard practices for things like stolen credit cards in the early 1990s. At the time, the credit card companies published telephone book sized listings of stolen and canceled credit cards. Merchant's had the choice of looking up each card, or accepting a potential for loss. A lot of the smart card development in the mid-90s and beyond was based on the idea that the smart card, in itself, was the sole authorization token/algorithm/implementation. that was one of my points ridiculing PKI in the mid-90s ... that the CRL was a return to offline point-of-sale payment operation ... and seemed to motivate the work on OCSP. The difference was that in the move to real-time online transactions ... it got much high quality operation ... not only could it establish real-time valid/not-valid ... but also other real-time characteristics like real-time credit limit, recent pattern of transactions, and much more. by comparison, OCSP was an extremely poor man's real-time, online transaction smartcard payment cards started out being stand-alone stored-value to compensate for the extremely expensive and limited availability of point-of-sale in much of the world ... aka it was stored-value operation where the operation could be performed purely offline (the incremental cost of the smartcard chip was offset by savings not requiring realtime, online transaction). The telco economics didn't apply to the US ... as seen by the introduction of stored-value magstripe based payment cards in the US that did real-time, online transaction ... which served the same market niche that the offline smartcard was performing in other parts of the world. Between the mid-90s and now, telco costs connectivity has significantly changed around the world ... pervasive uniquitness of the internet, cellphone coverage, wireless, ... lots of things. The common scenario in the past couple decades ... was looking to add more more feature/function to smartcards to find the magical economic justification ... unfortunately, the increase in feature/function tended to also drive cost ... keeping the break even point just out of reach. Part of the certificateless public key work was to look at chips as a cost item (rather than profit item ... since lots of the smartcard work was driven by entities looking to profit by smartcard uptake). The challenge was something that had stronger integrity than highest rated smartcard but at effective fully loaded cost below magstripe (i.e. I had joked about taking a $500 milspec part, cost reducing by 3-4 orders of magnitude while improving the integrity). Another criteria was that it had to work within the time power constraints of a (ISO14443) contactless transit turnstyle ... while not sacrificing any integrity security. By comparison ... one of the popular payment smartcards from the 90s looked at the transit turnstyle issue ... and proposed a wireless sleeve for their contact card ... and 15ft electromagnetic tunnels on the approach to each transit turnstyle ... where public would walk slowly thru the tunnel ... so that the transaction would have completed by the time the turnstyle was reached. Part of achieving lower aggregate cost than magstripe ... was that even after extremely aggressive cost reduction, the unit cost was still 2-3 times that of magstripe ... however, if the issuing frequency could be reduced (for chip)... it was more than recouped (i.e. magstripe unit cost is possibly only 1% of fully loaded issuing costs). Changing the paradigm from institutional-centric (i.e. institution issued) to person-centric (i.e. person uses the same unit for multiple purposes and with multiple institutions) ... saves significant amount more (replaces an issuing model with a registration model). Turns out supposedly a big issue for a transition from an institution-centric (institution issuing) to person-centric paradigm ... was addressing how can the institution trust the unit being registered. Turns out that trust issue may have been obfuscation ... after providing a solution to institution trust ... there was continued big push back to moving off an institutional issuing (for less obvious reasons) ... some of the patent stuff (previous mentions) covered steps for moving to person-centric paradigm (along with addressing institutional trust issues). Part of it involved tweaking some of the processes ... going all the way back to while the chip was still part of wafer (in chip manufacturing ... and doing the tweaks in such a way that didn't disrupt standard chip manufacturing ... but at the same time reduced steps/costs). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List
Re: A mighty fortress is our PKI, Part II
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry Leichter leich...@lrw.com writes: 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. Not quite. Untraceable anonymity and untraceable pseudonymity remain one of the important applications of cryptography, and both depend on store and forward anonymizing networks which mix traffic by using high random latency. The saving qualifier for your assertion is for commerce. True, there is not yet a way to securely transmit and store commercial value (money) offline, but it has not been proven impossible. For these applications, the security has to be in the message, not the connection. Offline verification is essential. -- StealthMonger stealthmon...@nym.mixmin.net -- stealthmail: Scripts to hide whether you're doing email, or when, or with whom. mailto:stealthsu...@nym.mixmin.net Finger for key. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkxReuIACgkQDkU5rhlDCl7izQCfXuxcHdDT5c54EpATviI+PXCO MFEAoI62kO/DZcwkw++BpQ4Ey5jTVro6 =6mIw -END PGP SIGNATURE- - 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 10:50:10AM +0200, Alexandre Dulaunoy wrote: On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams nicolas.willi...@oracle.com wrote: This is a rather astounding misunderstanding of the protocol. [...] I agree on this and but the implementation of OCSP has to deal with all non definitive (to take the wording of the RFC) answers. That's where the issue is. All the exception case, mentioned in 2.3, are all unauthenticated and it seems rather difficult to provide authenticated scheme for that part as you already mentioned in [*]. That's why malware authors are already adding fake entries of OCSP server in the host file... simple and efficient. A DoS attack on OCSP clients (which is all this really is) should either cause the clients to fallback on CRLs or to fail the larger operation (TLS handshake, whatever) altogether. The latter makes this just a DoS. The former makes this less than a DoS. The real risk would be OCSP clients that don't bother with CRLs if OCSP Responder can't respond successfully, but which proceed anyways af if peers' certs are valid. If there exist such clients, don't blame OCSP. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Jul 26, 2010, at 10:22 PM, Chris Palmer wrote: Perry E. Metzger writes: All major browsers already trust CAs that have virtually no security to speak of, ...and trust any of those CAs on any (TCP) connection in the (web app) session. Even if your first connection was authenticated by the right CA, the second one may not be. Zusmann and Sotirov suggested SSL pinning (like DNS pinning, in which the browser caches the DNS response for the rest of the browser process' lifetime), but as far as I know browsers haven't implemented the feature. I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) cpf.digicert.com IN TXT v=cpf1 /^DigiCert/ -all Get the top 5 browsers to support it, and a lot of that any CA can issue to any domain risk goes way down. Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only) Is there a reason that opportunistic crypto (no cert required) hasn't been done for https? Would it give too much confidence to people whose DNS is being spoofed? A presentation I've given at a few security gatherings may be of interest. I cover some specific security, UI/UX, and policy problems, as well as some general observations about incentives and barriers to improvement. Our overall recommendation is to emulate the success of SSH, but in a browser-y, gentle-compliance-with-the-status-quo-where-safe way. https://docs.google.com/present/view?id=df9sn445_206ff3kn9gs Great slides! The TOFU/POP is nice, and my favorite concept was to translate every error message into a one sentence, easy-to-understand statement. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Wow, I was just going to recommend Dan's book, Security Metrics. It is actually Andy Jaquith's book, I only wrote the intro. In the meantime, though, couple of years ago I did a tutorial on security metrics which you may find useful http://geer.tinho.net/measuringsecurity.tutorial.pdf Best, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann writes: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) That's along the lines of what EFF and I propose, yes. As I state in the slides, a key problem is how to smooth over the adaptation problem by various heuristics. We don't necessarily think that our mechanism is best, just that it's one of a family of likely approaches. Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) Even if anyone other than spammers had adopted SPF, we should still be seeking to reduce cruft, not increase it. Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only) Sure, or simply put the cert in the DNS itelf. But, DNS is not secure, so in doing so we would not actually be solving the secure introduction problem. Some people think that DNSSEC can fill in here, but it hasn't yet. Is there a reason that opportunistic crypto (no cert required) hasn't been done for https? As you can see, I am a firm advocate that we should emulate and improve on SSH's success. On one of my computers I use the HTTPS Everywhere and Perspectives plugins for Firefox; the latter renders CAs pretty much moot and the former gets me HTTPS by default at least some of the time. It's a fine thing. Remember when we all dropped telnet like a hot potato and migrated to SSH pretty much overnight? Let's do that again. Browsers should use secure transport by default in a way that is meaningful to humans and cheap to deploy. Would it give too much confidence to people whose DNS is being spoofed? I believe it would be a vast improvement in such a scenario. It would be hard to do worse than the status quo. Great slides! The TOFU/POP is nice, and my favorite concept was to translate every error message into a one sentence, easy-to-understand statement. Thank you. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Ben Laurie b...@links.org writes: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. This wouldn't make any difference, except for the special case of x64, signatures are only verified on install, so existing installed code isn't affected and anything new that's being installed is, with either form of sig-checking. In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). The way to revoke a cert for signed malware is to wait 0-12 hours for the malware signature to be added to AV databases, not to actually expect PKI to work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 28/07/2010 01:07, Paul Tiemann wrote: There is a long list of flyblown metaphors which could similarly be got rid of if enough people would interest themselves in the job; and it should also be possible to laugh the not un- formation out of existence*... *One can cure oneself of the not un- formation by memorizing this sentence: A not unblack dog was chasing a not unsmall rabbit across a not ungreen field. Had he succeeded in this mission, then we could never have had John Major on Spitting Image being not inconsiderably incandescent. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 00:14, Paul Tiemann wrote: On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. I like that idea, as long as a verifiable timestamp is included. Without a trusted timestamp, would the bad guy be able to backdate the signature? Note that I avoided this issue by using the date of receipt. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 09:57, Peter Gutmann wrote: Ben Laurie b...@links.org writes: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. This wouldn't make any difference, except for the special case of x64, signatures are only verified on install, so existing installed code isn't affected and anything new that's being installed is, with either form of sig-checking. Obviously if you are going to change revocation you can also change when signatures are checked. This hardly seems like a show-stopper. In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). Again, citing the failure to use revocation correctly right now does not tell us anything much about the possibility of using it correctly in the future. The way to revoke a cert for signed malware is to wait 0-12 hours for the malware signature to be added to AV databases, not to actually expect PKI to work. At which time they release another version? Doesn't sound like the optimal answer to me. I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 27, 2010, at 5:34 PM, Ben Laurie wrote: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. There is, of course, the problem of knowing when a signature was stolen! You can know that it was definitely stolen *by* a particular date, but never that it wasn't stolen earlier. Given that it was stolen, what evidence could you produce that it wasn't stolen - and simply kept around for later use - at the moment it was created? Beyond that, you it's often hard to know when you received a file. Perhaps the actual attack was to stick it on your system and backdate it! A forensic examination could look at backups, but we're talking about how to decide whether to accept a signature in an operational setting. You can't, of course, rely on any dates within the file itself, as they are protected from fakery only by the signature that you can't trust. You could rely on a digital time-stamping service ... but that just brings into sharper focus the absurdity that actually began the moment you needed to check an on-line CRL. The only conceivable purpose for using a signature is that you can check it *offline*. If you assume you can connect to the network, and that you can trust what you get from the network - why bother with a signature? Simply check a cryptographic hash of the driver against an on-line database of known good drivers. This is right in line with Lynn Wheeler's frequent mention here that the use case for offline verification of certs for commerce basically doesn't exist. It was a nice theory to develop 30 years ago, but today the rest of the framework assumes connectivity, and you buy nothing but additional problems by focusing on making just one piece work off-line. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? It's not just that the world doesn't work that way now, it's quite likely that it'll never work that way (for the case of PKI/revocations mentioned in the message, not the original SNI). We've been waiting for between 20 and 30 years (depending on what you define as the start date) for PKI to start working, and your reponse seems to indicate that we should wait even harder. If I look at the mechanisms we've got now, I can identify that commercial PKI isn't helping, and revocations aren't helping, and work around that. I'm after effective practical solutions, not just a solution exists, QED solutions. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 13:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? It's not just that the world doesn't work that way now, it's quite likely that it'll never work that way (for the case of PKI/revocations mentioned in the message, not the original SNI). We've been waiting for between 20 and 30 years (depending on what you define as the start date) for PKI to start working, and your reponse seems to indicate that we should wait even harder. If I look at the mechanisms we've got now, I can identify that commercial PKI isn't helping, and revocations aren't helping, and work around that. I'm after effective practical solutions, not just a solution exists, QED solutions. The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I don't know why it should help that we find different solutions for the world to ignore? -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Tue, Jul 27, 2010 at 10:10:54PM -0600, Paul Tiemann wrote: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) My preference would be for doing something like SCRAM (and other SASL/GSS mechanisms) with channel binding (using tls-server-end-point CB type). It has the effect that the server can confirm that the certificate seen by the client is the correct one -- whereas the server cannot do that in the SSL pinning approach. It'd have other major benefits as well. The problem is: there's no standard way to do this in web browser applications. Worse, there's not even any prototypes. I also like the Moonshot approach. Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) Better yet: use DNSSEC and publish TLS EE certs in the DNS. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 01:21:33PM +0100, Ben Laurie wrote: On 28/07/2010 13:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? [...]. I'm after effective practical solutions, not just a solution exists, QED solutions. The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I don't know why it should help that we find different solutions for the world to ignore? Solutions at higher layers might have a better chance of getting deployed. No, I'm not suggesting that we replace TLS and HTTPS with application-layer crypto over HTTP, not entirely anyways. I am suggesting that we use what little TLS does give us in ways that don't require changing TLS much or at all. Application-layer authentication with tls-server-end-point channel bindings seems like a feasible candidate. This too would require changes on clients and servers, which makes it not-that-likely to get implemented and deployed, but not changes at the TLS layer (other than an API by which to extract a TLS connection's server cert). It could be deployed incrementally such that users who can use it get better security. Then if the market gives a damn about security, it might get closer to fully deployed in our lifetimes. The assumption here is that improvements at the TLS and PKI layers occur with enormous latency. If this were true at all layers then we could just give up, or aim to fix not just today's problems, but tomorrow's, a decade or three from now (ha). It'd be nice if that assumption were not true at all. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 28, 2010, at 8:21 33AM, Ben Laurie wrote:
On 28/07/2010 13:18, Peter Gutmann wrote:
Ben Laurie b...@links.org writes:
I find your response strange. You ask how we might fix the problems, then
you
respond that since the world doesn't work that way right now, the fixes
won't
work. Is this just an exercise in one-upmanship? You know more ways the
world
is broken than I do?
It's not just that the world doesn't work that way now, it's quite likely
that
it'll never work that way (for the case of PKI/revocations mentioned in the
message, not the original SNI). We've been waiting for between 20 and 30
years (depending on what you define as the start date) for PKI to start
working, and your reponse seems to indicate that we should wait even harder.
If I look at the mechanisms we've got now, I can identify that commercial
PKI
isn't helping, and revocations aren't helping, and work around that. I'm
after effective practical solutions, not just a solution exists, QED
solutions.
The core problem appears to be a lack of will to fix the problems, not a
lack of feasible technical solutions.
I don't know why it should help that we find different solutions for the
world to ignore?
There seem to be at least three different questions here: bad code (i.e., that
Windows doesn't check the revocation status properly), the UI issue, and the
conceptual question of what should replace the current PKI+{CRL,OCSP} model.
For the last issue, I'd note that using pki instead of PKI (i.e., many
different per-realm roots, authorization certificates rather than identity
certificates, etc.) doesn't help: Realtek et al. still have no better way or
better incentive to revoke their own widely-used keys.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/28/2010 12:10 AM, Paul Tiemann wrote: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) cpf.digicert.com IN TXT v=cpf1 /^DigiCert/ -all Get the top 5 browsers to support it, and a lot of that any CA can issue to any domain risk goes way down. Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only) Is there a reason that opportunistic crypto (no cert required) hasn't been done for https? Would it give too much confidence to people whose DNS is being spoofed? Part of SSL was countermeasure to perceived weakness in domain name infrastructure ... is the server that I think I'm talking to really the server I'm talking to (things like ip-address hijacking). Now Certification Authorities typically aren't the authoritative agency for the information they are certifying ... they ask for a whole bunch of information from an SSL certificate applicant and then perform and expensive, time-consuming, and error-prone identification process, x-checking the supplied information with the information on-file at the domain name infrastructure as to the true owner of a domain (the same domain name infrastructure that has the weaknesses that SSL is designed as countermeasure). So ... something that could be backed by the Certification Authority industry as part of DNSSEC is to ask that all domain name applicants also register a public key as part of obtaining a domain name. domain name infrastructure then can required that all subsequent communication be digitally signed ... and can be verified with the onfile public key (as countermeasure to various kinds of domain name hijacking exploits, hijack domain and then apply for valid SSL certificate using dummy front company which matches the corrupted onfile information). The Certification Authority industry then could take advantage of the same infrastructure and require that all SSL domain name certificate applications, also be digitally signed (and can be verified with the onfile public key at the domain name infrastructure); replacing a time-consuming, expensive, error-prone identification process with an efficient, inexpensive, reliable authentication process. The catch-22 for the industry is if the Certification Authority industry could start doing real-time, online retrieval of public keys for authentication ... then maybe the rest of the world might also ... changing SSL to a certificateless, real-time, online publickey infrastructure. One of the possible reasons that it hasn't happened is there no startup, venture capital, IPO ... etc, gorp associated with such an incremental enhancement to the existing domain name infrastructure (it is a pure security/integrity play with no big financial motivation for anybody). W/o startup, venture capital, IPO play ... there is no big marketing budget to blitz the public on how much more comforting things would be (i.e. part of the reason that I coined the term merchant comfort certificates back in the early days). In the late 90s, we got visited by somebody that wanted to explain about the downside our comments could have on some pending Certification Authority IPO (much of internet hype from the period was actually part of IPO-mill money generating machine). I've posted frequently in the past about the catch-22 scenario for the certification authority industry. disclaimer: the inventor of domain name infrastructure did a stint at the science center a decade earlier ... working on various and sundry projects. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:38:17 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 09:57, Peter Gutmann wrote: In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). Again, citing the failure to use revocation correctly right now does not tell us anything much about the possibility of using it correctly in the future. The US Securities and Exchange Commission has long forced companies to state, when selling advisory services, that past performance is no indicator of future performance. However, I think that's pretty much clearly untrue in most disciplines. Empirical reasoning is entirely about observing and drawing conclusions based on what we observe. Virtually all of modern science comes, in fact, from observing what happens in the real world and extrapolating from it. After a few decades of trying to get PKI to work, we have failed to do so. At some point, one has to have very firm justifications for the belief that these decades of experience should be dismissed as mere experimental error. In another message you say: The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I'm unsure whether you are correct here, but I will point out that any solution which can never be deployed *is*, in fact, infeasible, and that if human beings cannot be convinced to use a particular solution (which is one form of the lack of will problem), then we might as well dismiss that solution. Now, I've been saying PKI can never be made to work for something like the last fifteen years. I was on a panel with Steve Kent at a Usenix workshop long ago, where I expressed the opinion that PKI very poorly models the actual legal and de facto relationships between parties, and I think that experience has borne that out. We've watched the rise and fall of substantial companies dedicated to trying to get PKI sold into enterprises, and the best efforts that Certco and Entrust and the like made were not enough. There is also considerable evidence that many of the technologies PKI requires, like reliable revocation, cannot be made to work, and whether that is because of a lack of will or because of something deeper, the fact is that these techniques have failed in practice over the course not of months or years but of decades, and we cannot ignore that forever. It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. I think we are at or even past that point with PKI. The odor of putrefaction is unmistakable. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Peter, In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. I can confirm that, at least for XP SP3: revocation just doesn't matter. What's even more worrying is the fact that one of the stuxnet/tmphider variants used the lnk exploit to install a dll signed w/ the (expired) Realtek key but w/ a *broken* signature in the first place. Still, it doesn't matter altough, as wireshark tells me, the host connects to microsoft.com in order to fetch certificates. When looking at the file properties, though, Windows tells you that this digital signature is not valid ... :-( Cheers, Stefan. -- Stefan Kelm sk...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Steven Bellovin s...@cs.columbia.edu writes: For the last issue, I'd note that using pki instead of PKI (i.e., many different per-realm roots, authorization certificates rather than identity certificates, etc.) doesn't help: Realtek et al. still have no better way or better incentive to revoke their own widely-used keys. I think the problems go a bit further than just Realtek's motivation, if you look at the way it's supposed to work in all the PKI textbooks it's: Time t: Malware appears signed with a stolen key. Shortly after t: Realtek requests that the issuing CA revoke the cert. Shortly after t': CA revokes the cert. Shortly after t'': Signature is no longer regarded as valid. What actually happened was: Time t: Malware appears signed with a stolen key. Shortly after t: Widespread (well, relatively) news coverage of the issue. Time t + 2-3 days: The issuing CA reads about the cert problem in the news. Time t + 4-5 days: The certificate is revoked by the CA. Time t + 2 weeks and counting: The certificate is regarded as still valid by the sig-checking software. That's pretty much what you'd expect if you're familiar with the realities of PKI, but definitely not PKI's finest hour. In addition you have: Time t - lots: Stuxnet malware appears (i.e. is noticed by people other than the victims) Shortly after t - lots: AV vendors add it to their AV databases and push out updates (I don't know what lots is here, it seems to be anything from weeks to months depending on which news reports you go with). So if I'm looking for a defence against signed malware, it's not going to be PKI. That was the point of my previous exchange with Ben, assume that PKI doesn't work and you won't be disappointed, and more importantly, you now have the freedom to design around it to try and find mechanisms that do work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann paul.tiemann.use...@gmail.com writes: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) That's the key-continuity model, which has been proposed a number of times for Firefox, for example here's a discussion by a FF developer from over two years ago on this, http://blog.johnath.com/2008/04/16/security-ui-in-firefox-3plus1/ (that's specific to FF, I don't know what the IE, Opera, Safari, ... guys talk about). There's no sign of it gaining any traction. I hate to be the perpetual wet blanket here but the problem isn't a lack of ideas (many backed by extensive real-world research) but a lack of motivation in browsers to change the security mechanisms and UI, most of which have remained essentially unchanged (except for cosmetic rearrangement of the chrome every release or so) since the debut of SSL in 1995. That's the mastodon in the room, we can debate ideas pretty much forever but if no browser vendor is interested in adopting any of them it isn't going to help secure users. (Having said that, it's fun to throw around ideas, so I'm not complaining about that bit). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. And still needs revocation. Is there a good replacement for pk for this purpose? -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. I agree with that fully. And still needs revocation. Does it? I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all. Is there a good replacement for pk for this purpose? I think public key cryptography is a wonderful thing. I'm just not sure I believe at all in PKI -- that is, persistent certification via certificates, certificate revocation, etc. PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28 July 2010 15:05, Perry E. Metzger pe...@piermont.com wrote: On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. I agree with that fully. And still needs revocation. Does it? I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all- The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote: PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. PKI alone is certainly not the answer to all our problems. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 10:05 AM, Perry E. Metzger wrote: I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all. long ago and far away ... one of the tasks we had was to periodically go by project athena to audit various activities ... including Kerberos. The original PK-INIT for kerberos was effectively certificateless public key ... aka replace registering a shared-secret password (for authentication) with a public key. There was then some amount of lobbying by the certification authority interests for pk-init to include certificate-based mode of operation (I wrote the draft-words for PK-INIT for inclusion of certificateless ecdsa). An issue with Kerberos (as well as RADIUS ... another major authentication mechanism) ... is that account-based operation is integral to its operation ... unless one is willing to go to a strictly certificate-only mode ... where all information about an individuals authority and access privileges are also carried in the certificate (and eliminate the account records totally). As long as the account record has to be accessed as part of the process ... the certificate remains purely redundant and superfluous (in fact, some number of operations running large Kerberos based infrastructure have come to realize that they have large redundant administrative activity maintaining both the account-based information as well as the duplicate PKI certificate-based information). The account-based operations have sense of revocation by updating the account-based records. This can be done in real-time and at much finer levels of granularity than the primitive, brute-force (PKI) revocation (and replacement). For instance, have you gone over your outstanding balance or credit-limit? ... are you up-to-date with you ISP account? ... or should it just be temporarily suspended bending receipt of funds. Account records can carry other kinds of real-time information ... like whether currently logged on ... and should duplicate, simultaneous logons be prevented (difficult to achieve with redundant and superfluous, stale, static certificates). The higher-value operations tend to be able to justify the real-time, higher quality, and finer grain information provided by an account-based infrastructure ... and as internet and technology has reduced the costs and pervasiveness of such operations ... it further pushes PKI, certificate-based mode of operation further and further into no-value market niches. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Perry, I think public key cryptography is a wonderful thing. I'm just not sure I believe at all in PKI -- that is, persistent certification via certificates, certificate revocation, etc. I'm sure you remember Peter Honeyman's PK-no-I talk from the '99 USENIX Security Symposium? :-) Cheers, Stefan. -- Stefan Kelm sk...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 15:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. And still needs revocation. It depends on what you mean by revocation, traditional revocation in the PKI sense isn't needed because (well apart from the fact that it doesn't work, you can't un-say something after you've already said it) if you look at what a PK or a cert is, it's just a capability, and the way to revoke (in the capability sense) a capability is to do something like rename the object that the capability refers to or use a level of indirection and break the link when you want to revoke (in the capability sense) the access. This means that no matter how many copies of the capability are floating around out there and whether the relying party checks CRLs or not, they're not going to be able to get in. Now you are talking my language! Have I mentioned that my new project at Google is all about finding good UI for exposing capabilities to users? Is there a good replacement for pk for this purpose? Which purpose? If you mean securing the distribution channel for binaries, here's a very simple one that doesn't need PK at all, it's called a self-authenticating URL. To use it you go to your software site, and here's a real-world example that uses it, the Python Package Index, and click on a download link, something like http://pypi.python.org/packages/package.gz#md5= (yeah, I know, it uses MD5...). This link can point anywhere, because the trusted source of the link includes a hash of the binary (and in this case it's a non-HTTPS source, you can salt and pepper it as required, for exammple make it an HTTPS link and use key continuity to manage the cert). In this form the concept is called link fingerprints, it was actually implemented for Firefox as a Google Summer of Code project, but then removed again over concerns that if it was present people might actually use it (!!). It's still available in DL managers like DownThemAll. The problem here is that it doesn't directly give me an upgrade path. Of course, I agree that this is sufficient to give me a link to the right binary, but what about its successors? Another option is to cryptographically bind the key to the URL, so you again have a trusted link source for your download and the link is to https://base64.downloadsite.com, where base64 is a fingerprint of the cert you get when you connect to the site. This does away with the need for a CA, because the link itself authenticates the cert that's used. Yes, this is of course the YURL scheme. Then there are other variations, cryptographically generated addresses, ... all sorts of things have been proposed. The killer, again, is the refusal of any browser vendor to adopt any of it. In the case of FF someone actually wrote the code for them, and it was rejected. Without support from browser vendors, it doesn't matter what cool ideas people come up with, it's never going to get any better. Peter. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 08:48:14AM -0400, Steven Bellovin wrote:
There seem to be at least three different questions here: bad code
(i.e., that Windows doesn't check the revocation status properly),
the UI issue, and the conceptual question of what should replace the
current PKI+{CRL,OCSP} model. For the last issue, I'd note that
using pki instead of PKI (i.e., many different per-realm roots,
authorization certificates rather than identity certificates, etc.)
doesn't help: Realtek et al. still have no better way or better
incentive to revoke their own widely-used keys.
With a sufficiently fine grained authorization model inside the OS,
there is no reason in principle that something like attribute
certificates couldn't work - RealTek would have a code signing cert
only valid for drivers that talked to network cards with specific PCI
vendors IDs, and UI tools that talked to that driver - the signature
on the worm binary in question would be valid, but the worm would not
be given the permissions it wants to actually do its thing. (Eg, when
was the last time you had a network driver that needed to access an
MSSQL db). Windows is not that OS. (Neither is Linux or BSD of
course). It looks like Singularity has some features which could
support this sort of model [1].
This is not to suggest this is at all an easy course of action to
take; my point is just that it's possible to do much better here
without having to alter anyone's incentives: the CAs still collect
their rent, and RealTek's drivers still work. Fixing the OS is
probably easier than somehow fixing PKI to do what we'd nominally want
it to do here (though actually revoking the cert would have been a
good start) or modifying the obvious incentives.
-Jack
[1] http://research.microsoft.com/apps/pubs/default.aspx?id=59976
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 03:16:32PM +0100, Ben Laurie wrote: Maybe it doesn't, but no revocation mechanism at all makes me nervous. I don't know Kerberos well enough to comment. DNSSEC doesn't have revocation but replaces it with very short signature lifetimes (i.e. you don't revoke, you time out). Kerberos too lacks revocation, and it also makes up for it with short ticket lifetimes. OCSP Responses are much like a PKI equivalent of Kerberos tickets. All you need to do to revoke a principal with OCSP is to remove it from the Responder's database or mark it revoked. To revoke an individual certificate you need only mark a date for the given subject such that no cert issued prior to it will be considered valid. An OCSP Responder implementation could be based on checking a real CRL or checking a database of known subjects (principals). Whichever is likely to be smaller over time is best, though the latter is just simpler to administer (since you don't need to know the subject public key nor the issuerserial, nor the actual TBSCertificate in order to revoke, just the subject name and current date and time). SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. This doesn't scale very well to SSL-style systems. The SSH ad-hoc pubkey model is a public key pre-sharing (for user keys) and pre-sharing and/or leap-of-faith (for host keys) model. It doesn't scale without infrastructure. Add infrastructure and you're back to a PKI-like model (maybe with no hierarchy, but still). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie b...@google.com wrote: On 28 July 2010 15:05, Perry E. Metzger pe...@piermont.com wrote: On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: And still needs revocation. Does it? I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all Maybe it doesn't, but no revocation mechanism at all makes me nervous. I think that is because you are thinking in terms of certificates, which naturally would require such a mechanism. I don't know Kerberos well enough to comment. In kerberos, tickets are short lived -- one can simply fail to give the person who stole a credential new ones, and in the interim, one can remove the authorization that a particular principal has. DNSSEC doesn't have revocation but replaces it with very short signature lifetimes (i.e. you don't revoke, you time out). Yes. Precisely. SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. No, that's not what SSH does, or rather, it confuses the particular communications channel (i.e. some out of band mechanism) with the method that actually de-authorizes the key. The point is that in SSH, if a key is stolen, you remove it from the list of keys allowed to log in to a host. The key now need never be thought about again. We require no list of revoked keys be kept, just as we required no signed list of keys that were authorized. We just had some keys in a database to indicate that they were authorized, and we removed a key to de-authorize it. This doesn't scale very well to SSL-style systems. I believe it does scale. Pretty much by definition, if you can get to a web site, your Internet connectivity is working. That means that there is no need for methods like having a signed key that lasts for years so you can cache it for offline use. I'm sure you remember the 1960s and 1970s well, as we are both a bit past our youth. In the US, at least, every store clerk had in their hands an unwieldy, telephone-book sized list of stolen credit card numbers they had to consult at each credit card transaction. In those days, there were no cheap modems and doing on-line verification was impossible. The whole point of Kohnfelder's thesis was, in effect, to turn the 1970s era books of stolen numbers into an offline machine readable list. You signed a long-lived credential so that it could be checked offline, and you kept a big book of withdrawn credentials around so you could check them offline as well. It was a model from the era in which everyone had a paper phone book. It was designed for the era where networks were a rarity. We no longer live in that era. The models used by Kerberos, DNSSEC, SSH, and such, make far more sense. We no longer need revocation. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
deliberately crashing ancient computers (was: Re: A mighty fortress is our PKI)
On Tue, 27 Jul 2010, Jack Lloyd suggested: http://www.crashie.com/ - if you're feeling malicious, just include the one line JavaScript that will make IE6 crash, maybe eventually the user will figure it out. (Or maybe not). Please stop and think about the consequences before using something like this! People who are still using IE6, Windows 95, etc, are usually doing so for reasons which make sense in their lives, things like (a) very low computer literacy (b) slow/unreliable internet connections (dialup?) (c) old/small/slow computer ( lack of money to buy a better one) (d) English not her/his native language (to read your how-to-upgrade msg) (e) that's what all their friends professional colleagues use These people are unlikely to change just because your site makes their computer crash. (They're also unlikely to distinguish between IE6 crashed and the computer crashed, and yes, they're likely to blame your website for the problem.) I too would love to see IE6 die. Ditto Windows 95. But I don't think actively trying to crash my colleague Professor X's computer is either ethical or an appropriate solution to her ancient computer environment. (She is elderly, retired, lives in a very poor country in South America, and has only dialup internet. The local computer shops/geeks where she lives usually recommend Windows 95 for upgrades/reinstalls. I don't know what web browser they pitch...) Ultimately though, the only thing that's going to get some people off IE6 is the machines they are running it off of finally dying, either due to hardware failure or being so badly owned by worms that the machine becomes inoperable, at which point it goes into the trash and they buy a new one. Yup. -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 10:42:43AM -0400, Anne Lynn Wheeler wrote:
On 07/28/2010 10:05 AM, Perry E. Metzger wrote:
I will point out that many security systems, like Kerberos, DNSSEC and
SSH, appear to get along with no conventional notion of revocation at all.
long ago and far away ... one of the tasks we had was to periodically
go by project athena to audit various activities ... including
Kerberos. The original PK-INIT for kerberos was effectively
certificateless public key ...
And PKINIT today also allows for rp-only user certs if you want them.
They must be certificates, but they needn't carry any useful data beyond
the subject public key, and the KDC must know the {principal,
cert|pubkey} associations.
An issue with Kerberos (as well as RADIUS ... another major
authentication mechanism) ... is that account-based operation is
integral to its operation ... unless one is willing to go to a
strictly certificate-only mode ... where all information about an
individuals authority and access privileges are also carried in the
certificate (and eliminate the account records totally).
This is true time you have rp-only certs or certs that carry less
information than the rp will require. The latter almost always true.
The account can be local to each rp, however, or centralized -- that's
up to the relying parties.
As long as the account record has to be accessed as part of the
process ... the certificate remains purely redundant and superfluous
(in fact, some number of operations running large Kerberos based
infrastructure have come to realize that they have large redundant
administrative activity maintaining both the account-based information
as well as the duplicate PKI certificate-based information).
Agreed. Certificates should, as much as possible, be rp-only.
The account-based operations have sense of revocation by updating the
account-based records. [...]
Exactly. OCSP can work in that manner. CRLs cannot. In terms of
administration updating an account record is much simpler than updating
a CRL (because much less information needs to be available for the
former than for the latter).
The higher-value operations tend to be able to justify the real-time,
higher quality, and finer grain information provided by an
account-based infrastructure ... and as internet and technology has
reduced the costs and pervasiveness of such operations ... it further
pushes PKI, certificate-based mode of operation further and further
into no-value market niches.
Are you arguing for Kerberos for Internet-scale deployment? Or simply
for PKI with rp-only certs and OCSP? Or other federated
authentication mechanism? Or all of the above? :)
Nico
--
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 16:01, Perry E. Metzger wrote: On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie b...@google.com wrote: SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. No, that's not what SSH does, or rather, it confuses the particular communications channel (i.e. some out of band mechanism) with the method that actually de-authorizes the key. The point is that in SSH, if a key is stolen, you remove it from the list of keys allowed to log in to a host. The key now need never be thought about again. We require no list of revoked keys be kept, just as we required no signed list of keys that were authorized. We just had some keys in a database to indicate that they were authorized, and we removed a key to de-authorize it. I am referring to the SSH host key. Fully agree for user keys. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote: PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. PKI alone is certainly not the answer to all our problems. Infrastructure Let me interrupt here and say that when I refer to PKI, I mean the Kohnfelder model which we have been following, which is the model of very long lived phone books of hierarchically issued certificates along with very long lived lists of revoked certificates, all designed with an offline world in mind. I have no objections to infrastructure -- bridges, the Internet, and electrical transmission lines all seem like good ideas. However, lets avoid using the term Public Key Infrastructure for things that depart radically from the Kohnfelder and subsequent X.509 models. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. Well, it depends a lot on what kind of trust. Let me remind everyone of one of my long-standing arguments. Say that Goldman Sachs wants to send Morgan Stanley an order for a billion dollars worth of bonds. Morgan Stanley wants to know that Goldman sent the order, because the consequences of a mistake on a transaction this large would be disastrous. Should they trust Verisign's ExtraSuperHighValue certificate presented by Goldman? No. Why? Because Verisign disclaims all effective liability for the use of its certs. It is not a party to the transaction being conducted. If it was actually insuring all transactions conducted with the certificate, then Morgan could trust them, because the counterparty who's credit would be at issue would no longer be Goldman but Verisign. However, Verisign won't even pay out if it turned out that they gave signed a Goldman cert and it was in fact held by a scammer. The problem with Certification Authorities is they certify NOTHING. There can be no reliance on them, because they have no liability of any sort in any transaction. So, in the real world, Goldman and Morgan come up with ways of making sure they trust each other's communications and credit lines. Even when we're dealing with small transactions, like buying a book at a book store with a credit card, if you trace it out, we're dealing with nothing but a web of bilateral commercial relationships. So, I have no trouble with various kinds of trust. What I have trouble with is the sort of false trust that a CA implies. CAs certify nothing in a real world business sense -- they are just toll collectors. However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. I believe we may, in fact, be in violent agreement here. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: deliberately crashing ancient computers (was: Re: A mighty fortress is our PKI)
On Wed, Jul 28, 2010 at 11:04:30AM -0400, Jonathan Thornburg wrote: On Tue, 27 Jul 2010, Jack Lloyd suggested: http://www.crashie.com/ - if you're feeling malicious, just include the one line JavaScript that will make IE6 crash, maybe eventually the user will figure it out. (Or maybe not). Please stop and think about the consequences before using something like this! People who are still using IE6, Windows 95, etc, are usually doing so for reasons which make sense in their lives, things like [...] Personally I'm not planning on doing anything one way or another to encourage or discourage people using IE6. In the spectram of social badness, I'd view using IE6 roughly on par with using heroin - a bad idea that mostly hurts oneself with some limited (albeit real) negative externalities. As with using drug rehabilitation versus prison sentences to reduce use, the real solution to IE6 is education and assistance for those who want it, not punishment. Some will, for whatever reason, choose to ignore said educational/assistance efforts, and eventually will take the consequences of their actions without any antics by you or I. And certainly I have better things to do with my time than crash a decade-old browser. Thanks, Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 11:13:36AM -0400, Perry E. Metzger wrote: On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: I have no objections to infrastructure -- bridges, the Internet, and electrical transmission lines all seem like good ideas. However, lets avoid using the term Public Key Infrastructure for things that depart radically from the Kohnfelder and subsequent X.509 models. Well, OK. But PKI no longer means that, not with bridges and what not in the picture. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. Well, it depends a lot on what kind of trust. Let me remind everyone of one of my long-standing arguments. Say that Goldman Sachs wants to send Morgan Stanley an order for a billion dollars worth of bonds. Morgan Stanley wants to know that Goldman sent the order, because the consequences of a mistake on a transaction this large would be disastrous. Indeed. They must first establish a direct trust relationship. They might leverage transitive trust to bootstrap direct trust if doing so makes the process easier (which it almost certainly does, and which we use in the off-line world all the time using pieces of paper or plastic issued by various authorities, such as drivers' licenses, passports, ...). However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. I believe we may, in fact, be in violent agreement here. We are. Perhaps I hadn't made my point obvious enough: transitive trust is necessary, but primarily as a method of bootstrapping direct trust relationships. I really should have used that specific formulation. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 11:05 AM, Nicolas Williams wrote: Are you arguing for Kerberos for Internet-scale deployment? Or simply for PKI with rp-only certs and OCSP? Or other federated authentication mechanism? Or all of the above? :) as i've mentioned ... the relying-party-only certificates are almost always redundant and superfluous ... except in cases where the relying party can't justify their own repository of information and/or distributed access to such a repository of information. I previously mentioned that in the payment transaction case, even a relying-party-only certificate was a factor of 100-times payload size bloat for typical payment transactions ... aka not only was the certificate redundant and superfluous ... but it represented an enormous (redundant and superfluous) processing burden. I've mentioned a number of times that OCSP appeared after I had repeatedly ridiculed revokation process being archaic backwards step for real-time payment processes. And that even OCSP (with a certificate) is still redundant and superfluous when real-time transaction is being performed using the real information. the other scenario for rpo-certs ... besides for no-value operations ... is when the real infrastructure is down and/or not accessible. But that usually is matter of cost also, some of the higher-value operations have gone to significant redundancy and claim 100% availability. The certificate analogy is still the letters of credit/introduction from sailing ship days ... when the relying-party had no (other) access to first time interaction with complete stranger (and has to fall back to much cruder and lower quality information). There is also some scenario if the respository and the service are co-located ... that when the repository is unavailable the service will also be unavailable ... so there is no requirement for independent source of information. The catch22 for certification authority operation ... is that as they move further further into the no-value market niches (and/or market niches that can't justify the expense of higher quality operation with real-time repository) ... they are forced to cut their fees and indirectly the quality of their operation. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. Specifically, if I submit a freshly-issued, valid certificate to an OCSP responder and ask is this a valid certificate then it can't say yes, and if I submit an Excel spreadsheet to an OCSP responder and ask is this a valid certificate then it can't say no. It takes quite some effort to design an online certificate status protocol that's that broken. (For people not familiar with OCSP, it can't say yes because a CRL can't say yes either, all it can say is not on the CRL, and it can't say no for the same reason, all it can say is not on the CRL. The ability to say vslid certificate or not valid certificate was explicitly excluded from OCSP because that's not how things are supposed to be done). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 10:50:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote: On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: OCSP Responses are much like a PKI equivalent of Kerberos tickets. All you need to do to revoke a principal with OCSP is to remove it from the Responder's database or mark it revoked. Actually, that's untrue in one very important respect. In a Kerberos style system, you actively ask for credentials to do things at frequent intervals, and if the KDCs refuse to talk to you, you get no credentials. In OCSP, we've inverted that. You have the credentials, for years in most cases, and someone else has to actively check that they're okay -- and in most instances, if they fail to get through to an OCSP server, they will simply accept the credentials. No, they really are semantically equivalent. Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Peter Gutmann has pointed out other critical distinctions, but I'll let his message stand for itself. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Nicolas Williams nicolas.willi...@oracle.com writes: Sorry, but this is wrong. The OCSP protocol itself really is an online certificate status protocol. It's not an online certificate status protocol because it can provide neither a yes or a no response to a query about the validity of a certificate. (For an online status protocol I want to be able to submit a cert and get back a straight valid/not valid response, exactly as I can for credit cards with their authorised/declined response. Banks were doing this twenty years ago with creaky mainframes over X.25 and (quite probably) wet bits of string, but we still can't do this today with multicore CPUs and gigabit links if we're using OCSP). Responder implementations may well be based on checking CRLs, but they aren't required to be. They may be, or they may not be, but you as a relying party have no way of telling. OCSP covers not only the three incompatible business models of the different authors' employers but, for good measure, an extra anything else you may care to do option if the first three aren't enough. A decade after it was published, PKI experts are still arguing over what various bits of the OCSP spec actually mean (the PKIX list has only just gone through yet another round of this... *ten years* later and domain experts still can't agree on how it's supposed to work). So given the schizophrenic nature of the RFC you can easily claim but you can do X because chances are if you read it just right you probably can. Unfortunately this doesn't give a relying party much to rely on, because they have absolutely no idea what they're getting, it could be anything from a live database query to a value from a month-old CRL to (thanks to the removal of nonces from the protocol a few years ago) an attacker replaying an old not-revoked value (although I don't know why they'd even bother with that, given the state of revocation checking in client software). In any event though since OCSP can't say yes or no, it doesn't matter whether the response is coming from a live database or a month-old CRL, since it's still a fully CRL-bug-compatible blacklist I can trivially avoid it with a manufactured-cert attack. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Jul 27, 2010, at 10:58 PM, d...@geer.org wrote: Wow, I was just going to recommend Dan's book, Security Metrics. It is actually Andy Jaquith's book, I only wrote the intro. Ouch, I'm sorry for the mistake! (I knew I remembered your name in connection with the book, but it's on my bookshelf in the office and I was at home.) In the meantime, though, couple of years ago I did a tutorial on security metrics which you may find useful http://geer.tinho.net/measuringsecurity.tutorial.pdf Thanks, my favorite so far is page 45 with the table on Risk Management Culture. I need to tape that to the wall for inspiration. Pathologic: Don't want to know Bureaucratic: May not find out Generative: Actively seek Pathologic: Failures punished Bureaucratic: Local repairs only Generative: Failures beget reforms From my point of view: The security community is being Generative (Actively seek) about finding the flaws in systems, but it's too often in the Pathologic (Failures punished) stage about how to handle those flaws once they're discovered. My suspicion: It's fun to Actively seek, and hard to find solutions, and it can be downright frustrating to champion reforms. If the vulnerability isn't gigantic, it's hard to even get people to listen. Reform is maybe 20x harder and 1/5th as fun as poking the holes. That said, here's an experience worth talking about: Dan Kaminsky did a pretty good job of being Generative in _both_ categories. He found a hole in DNS, and then worked with LOTS of vendors and even with people not directly tied to DNS to collaborate on reforms. He even called me (at a smaller CA) to make sure we were aware of the risks and to verify that we don't only rely on automated forms of verification. I really appreciated the call--it felt like my chance to talk to a rock star. All the best, Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:23:16 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 11:20:51AM -0500, Nicolas Williams wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. Also, requiring OCSP will probably take less effort than switching from PKI to Kerberos. In other words: eveything sucks. I wouldn't suggest that everything on earth move to Kerberos. I mentioned Kerberos only to show that entirely different models are possible. As to OCSP being a reasonable solution because it can be deployed easily, it clearly will not solve the browser security problem. So long as security depends on reliance on the lowest common denominator among the policies of hundreds of CAs, many of which are quite questionable, and so long as the certifications made by even the best of those CAs are effectively meaningless, and so long as the users are well trained to ignore every browser warning they ever get, the entire question of OCSP is somewhat irrelevant -- it would just be a way of spritzing the skunk with eau de cologne. I fully recognize that the odds we will fix the browser security problem are very low, if only because no one can deploy a truly new solution in a world where we can't even get IE 6 to die. However, in discussing this at a high level, as though we could improve things, we shouldn't kid ourselves about the current model. It is fatally broken. Hanging garlands from the corpse's ears will not convince anyone that it has a vibrant future ahead. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 12:02 PM, Nicolas Williams wrote: Sorry, but this is wrong. The OCSP protocol itself really is an online certificate status protocol. Responder implementations may well be based on checking CRLs, but they aren't required to be. Don't be confused by the fact that OCSP borrows some elements from CRLs. my OCSP analogy was turning authentication into an end in itself ... basically a new kind of retail store ... instead of retail store that sells some product ... you go in and buy something ... doing a real-time payment transaction; ... there is an authentication store ... convince everybody that they need to walk into their (OCSP) authentication retail store at least once a day to perform an authentication operation (for no other reason that people should get a lot of comfort out of being authenticated at least once a day or more if necessary) ... totally divorced and unrelated to any actual business purpose. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Thu, Jul 29, 2010 at 04:23:52AM +1200, Peter Gutmann wrote:
Nicolas Williams nicolas.willi...@oracle.com writes:
Sorry, but this is wrong. The OCSP protocol itself really is an online
certificate status protocol.
It's not an online certificate status protocol because it can provide neither
a yes or a no response to a query about the validity of a certificate.
You should be more specific. I'm looking at RFC2560 and I don't see
this.
OCSP Responses allow the Responder to assert:
- A time at which the given cert was known to be valid (thisUpdate;
REQUIRED).
Relying parties are free to impose a freshness requirement (e.g.,
thisUpdate must be no more than 5 minutes in the past).
Perhaps you're concerned that protocols that allow for carrying OCSP
Responses don't provide a way for peers to indicate what their
freshness requirements are?
- A time after which the given OCSP Response is not to be considered
valid (nextUpdate, which is OPTIONAL).
- The certificate's status (certStatus, one of good, revoked, unknown;
REQUIRED).
How is responding certStatus=good, thisUpdate=now - a few minutes
not a yes response to a query about the validity of a certificate?
What am I missing?
(For an online status protocol I want to be able to submit a cert and get back
a straight valid/not valid response, exactly as I can for credit cards with
their authorised/declined response. Banks were doing this twenty years ago
with creaky mainframes over X.25 and (quite probably) wet bits of string, but
we still can't do this today with multicore CPUs and gigabit links if we're
using OCSP).
OCSP gives you that. Seriously. In fact, an OCSP Responder either must
not respond or it must give you at least {certStatus, thisUpdate}
information about a cert. Yes, certStatus can be unknown, but a
Responder that regularly asserts certStatus=unknown would be a rather
useless responder.
Responder implementations may well be based on checking CRLs, but they aren't
required to be.
They may be, or they may not be, but you as a relying party have no way of
telling.
And why would a relying party need to know internal details of the OCSP
Responder?
In any event though since OCSP can't say yes or no, it doesn't matter whether
the response is coming from a live database or a month-old CRL, since it's
still a fully CRL-bug-compatible blacklist I can trivially avoid it with a
manufactured-cert attack.
Manufactured cert attack? If you can mint certs without having the CA's
private key then who cares about OCSP. If you can do it only as a
result of hash collisions, well, switch hashes. Let's not confuse hash
collision issues with whether OCSP does what it's advertised to do.
Nico
--
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? I mention this only because your language here is quite sticky. Saying it is up to the relying parties is incorrect. It is really up to a host of people who are nowhere near the relying parties. In most cases, the relying parties aren't even capable of understanding the issue. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 01:25:21PM -0400, Perry E. Metzger wrote: My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? I mention this only because your language here is quite sticky. Saying it is up to the relying parties is incorrect. It is really up to a host of people who are nowhere near the relying parties. In most cases, the relying parties aren't even capable of understanding the issue. Precise and concise language in a fast moving thread with participants with diverse backgrounds is going to be hard to come by. Better to quit than hold out for that (unless you enjoy being disappointed). I'm hardly the only sinner here on that score. up to the relying parties means up to the browsers, where users-as- relying-parties are concerned. That also means getting software updated, which to some degree means getting my mom to do stuff she doesn't and shouldn't have to know how. It shouldn't mean getting my mom to enable OCSP -- that would be hopeless. up to the relying parties means up to the server as well, since servers too are relying-parties. Again, if everything is too hard, why do we bother even talking about any of this? ETOOHARD cannot usefully be a retort to every suggestion. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 12:38:10 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: Again, if everything is too hard, why do we bother even talking about any of this? ETOOHARD cannot usefully be a retort to every suggestion. Well, not everything is too hard. In fact, one of the important characteristics of systems that work is that they're simple, and thus tractable. We were just discussing the problem of needing users to make fine grained security decisions. Several obvious solutions exist here. For example, the there should be one mode, and it should be secure rule lowers the complexity users encounter quite a bit. I know of at least one project to fix the browser PKI mess which claims that they want to involve the users more, not less. This would seem to be a big mistake to me. On the other edge of the spectrum, many people now use quite secure protocols (though I won't claim the full systems are secure -- implementation bugs are ubiquitous) for handling things like remote login and file transfer, accessing shared file systems on networks, etc., with little to no knowledge on their part about how their systems work or are configured. This seems like a very good thing. One may complain about many issues in Microsoft's systems, for example, but adopting Kerberos largely fixed the distributed authentication problem for them, and without requiring that users know what they're doing. Yet another reason (one of dozens) that X.509 has never worked right for most users is the sheer number of knobs. There are too many choices for mortals, and there will always be subtle configuration failures that can catch even experts. (I am reminded of the similar death-by-complexity of the IPSec protocol's key management layers, where I am sad to report that even I can't easily configure the thing. Some have proposed standardizing on radically simplified profiles of the protocol that provide almost no options -- I believe to be the last hope for the current IPSec suite.) Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 02:41:35PM -0400, Perry E. Metzger wrote: On the other edge of the spectrum, many people now use quite secure protocols (though I won't claim the full systems are secure -- implementation bugs are ubiquitous) for handling things like remote login and file transfer, accessing shared file systems on networks, etc., with little to no knowledge on their part about how their systems work or are configured. This seems like a very good thing. One may complain about many issues in Microsoft's systems, for example, but adopting Kerberos largely fixed the distributed authentication problem for them, and without requiring that users know what they're doing. Hear, hear! But... great for corporate networks, not quite for Internet-scale, but a great example of how we can make progress when we want to. (I am reminded of the similar death-by-complexity of the IPSec protocol's key management layers, where I am sad to report that even I can't easily configure the thing. Some have proposed standardizing on radically simplified profiles of the protocol that provide almost no options -- I believe to be the last hope for the current IPSec suite.) IPsec is a great example of another kind of failure: lack of APIs. Applying protection to individual packets without regard to larger context is not terribly useful. Apps have no idea what's going on, if anything, in terms of IPsec protection. Worse, the way in which IPsec access control is handled means that typically many nodes can claim any given IP address, which dilutes the protection provided by IPsec as the number of such nodes goes up. Just having a way to ask that a TCP connection's packets all be protected by IPsec, end-to-end, with similar SA pairs (i.e., with same peers, same transforms) would have been a great API to have years ago. The lack of APIs has effectively relegated IPsec to the world of VPN. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 5:51 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. Specifically, if I submit a freshly-issued, valid certificate to an OCSP responder and ask is this a valid certificate then it can't say yes, and if I submit an Excel spreadsheet to an OCSP responder and ask is this a valid certificate then it can't say no. It takes quite some effort to design an online certificate status protocol that's that broken. OCSP is even better for an attacker. As the OCSP responses are unauthenticated[1], you can be easily fake the response with what ever the attacker likes. http://www.thoughtcrime.org/papers/ocsp-attack.pdf [1] Would be silly to run OCSP over SSL ;-) -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance -- that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 28, 2010, at 9:51 AM, Peter Gutmann wrote: Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. This isn't true for all OCSP services. For example, DigiCert's is not CRL based, so it really can say Yes and it really can say Unknown meaningfully. (For people not familiar with OCSP, it can't say yes because a CRL can't say yes either, all it can say is not on the CRL, and it can't say no for the same reason, all it can say is not on the CRL. The ability to say vslid certificate or not valid certificate was explicitly excluded from OCSP because that's not how things are supposed to be done). True for off-the-shelf OCSP responders that base themselves on CRL. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 14:40:14 -0600 Paul Tiemann paul.tiemann.use...@gmail.com wrote: On Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote: On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? That might depend. I tell Firefox to use OCSP if a responder is referenced in the certificate, and I check that little checkbox that says When an OCSP connection fails, treat the certificate as invalid. I believe you've missed an important point. First, my mother would never understand what that box means. Second, my mother has no control over whether the CA provides OCSP. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
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. 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 Eckersley's and Burns' presentation at Defcon (coming right up) will present their findings from a global survey of certs presented by hosts listening on port 443. Their results are disturbing. Ivan Ristic is also presenting his results of a survey at Black Hat on the 29th. I don't know anything about his findings. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann writes: Since this is a certificate we (DigiCert) have issued, I'm trying to understand if there is a vulnerability here that's more apparent to others than to me, If an attacker can steal the cert by any means, perhaps by means particular to one of the hosted sites, he can now forge the identities of the 100+ sites. It gives the attack a multiplier. (It appears 100+ is not even the largest number of entities in a single cert.) Potential attacks: * Attack the server (e.g. buffer overflow in FooHTTPD or some other bug in a web app the CDN runs (I know not all CDNs run cloud app hosting services, but some do)). Note that even though all sites are served by the same server, all sites suffer the risk profile of the highest-profile site. If a CDN server is serving tiny.unknown.com and also mega.often-attacked.net, tiny.unknown effectively endures attacks on mega.often-attacked. * Questionable reseller. Although reselling a CDN might normally give you access only to a subset of the CDN's subscriber's sites, you can get many in one go because these certs have so many subjects. See below. The bulk of the FQDNs included in the certificate are for subdomains like media., www-cdn., static., and the like. Apply a different test: Is it bad for various organizations to use the same CDN for services over http? Is it bad for all those different FQDNs to CNAME to the same DNS entry and point to the same IP address? Is it bad for a CDN to host multiple individual SSL certificates for its customers on the same set of hardware? Let's just say I'd rather get the advantages of a CDN by other means, but that I recognize that using a CDN can be a reasoanble economic trade-off in many situations. If not, then what is so abhorrent about their various FQDNs being included in a single SSL certificate? I wouldn't say abhorrent, but the increased size of the cert could be a concern. I just wiresharked an HTTPS connection to https://ne.edgecastcdn.net/. The cert is 7,044 bytes. Admirably small given how many names are in it, but still 6 KB larger than another cert I observed containing only one subject. I have a hard enough time convincing people that HTTPS is not the root of their web app performance problems and that therefore they CAN afford to use it; the last thing we need is a certificate that big increasing latency at a critical time in the page load. TLS sessions to that server don't seem to last very long either, increasing the frequency of cert delivery; but maybe that is necessary due to the high traffic such a server handles. (Gotta have a limit on the size of the session store.) I know it's a small thing, especially relative to the general content layer heft of most sites, but still. When trying to convince developers to use HTTPS, I need every rhetorical advantage I can get. :) Considering the business incentives landscape, is it safe to assume a strong incentive for a CDN running all those sites to be vigilant about their own server security? Are there any inherently skewed incentives that I'm just not seeing which would lead a CDN to be negligent in its management of its network security and the SSL certificates it manages? As Peter noted, http://www.webhostingtalk.com/showthread.php?t=873555. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Paul Tiemann paul.tiemann.use...@gmail.com writes: [...] This is kind of a long message to reply to so I'll just post a meta-reply to avoid getting bogged down in nitpicking, the message, as the subject line indicated, was intended to start a discussion on some of the weaknesses inherent in the SSL and commercial PKI model. I consciously worded it to avoid mentioning any CA names, and only mentioned Edgecast because it was impossible not to (I had to provide a URL for the cert), and even then included a disclaimer that it wasn't a criticism of Edgecast. I actually agree with a lot of the points made in the response, since this wasn't a failing of Edgecast or a CA but a problem in the way SSL's PKI (or more generally just PKI as a whole) works. Because it was designed for the purposes of authenticating a single user to the global X.500 directory it really doesn't have any provision for Sybil certs (I'm going to keep calling them that because we need some sort of label for them :-). The intent with posting it to the list was to get input from a collection of crypto-savvy people on what could be done. The issue had previously been discussed on a (very small) private list, and one of the members suggested I post it to the cryptography list to get more input from people. The follow-up message (the Part II one) is in a similar vein, a summary of a problem and then some starters for a discussion on what the issues might be. So a general response to the several well, what would you do? questions is I'm not sure, that's why I posted this to the list. For example should an SSL cert be held to higher standards than the server it's hosted on? In other words if it's easier to compromise a CDN host or (far more likely) a web app on it, does it matter if you're using a Sybil cert? I have no idea, and I'm open to arguments for and against. I've spoken with my contacts at Edgecast, and they expressed that they're very willing to consider alternate approaches. I'm not actually sure what the fix would be for this, or even if there is a fix that needs to be made. Thus the hope to get it discussed on the list. (Oh, and a comment on the XS* bit, that was based on an earlier off-list discussion on messing with Firefox' same-origin policy protection mechanism and isn't relevant here, the real issue is the more obvious one of a single cert acting for large numbers of totally unrelated domains with very different security requirements). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Ian G i...@iang.org writes: ** But talking about TLS/SNI to SSL suppliers is like talking about the lifeboats on the Titanic ... we don't need it because SSL is unsinkable. ... or talking to PKI standards groups about adding a CRL reason code for certificate issued in error (e.g. to an imposter). This was turned down because CA's never make mistakes, so there's no need to have such a reason code. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Hi, Eckersley's and Burns' presentation at Defcon (coming right up) will present their findings from a global survey of certs presented by hosts listening on port 443. Their results are disturbing. Have these results already been published somewhere, or do you maybe even have a URL? Ralph - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 10:11 AM, Peter Gutmann wrote: So a general response to the several well, what would you do? questions is I'm not sure, that's why I posted this to the list. For example should an SSL cert be held to higher standards than the server it's hosted on? In other words if it's easier to compromise a CDN host or (far more likely) a web app on it, does it matter if you're using a Sybil cert? I have no idea, and I'm open to arguments for and against. long ago and far away, we were called in to consult with a small client/server startup that wanted to do payment transactions on their server ... they had also invented this technology called SSL that they wanted to use. As part of applying the technology to the business payment process ... we also had to go around and investigate how some of these new businesses, calling themselves Certification Authorities, operated. In any case, the result is now sometimes called electronic commerce. There were lots of issues with deficiencies and vulnerabilities, resulting in my coining the term merchant comfort certificates ... aka ... as opposed to anything to do with security. Of course, I also suggested that everybody that in anyway touched on the certificates or the merchant servers ... needed to have detail FBI background check. -- 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
On 07/27/2010 11:04 AM, Anne Lynn Wheeler wrote: long ago and far away. they had also invented this technology called SSL that they wanted to use. As part of applying the technology to the business payment process ... we also had to go around and investigate how some of these new businesses, calling themselves Certification Authorities, operated. In that same time, I was at CyberCash, we invented what is now sometimes called electronic commerce. and that and $5 will get you a cup of coffee. We predated SSL by a few years. Used RSA768 to protect DES sessions, etc. Usual stuff. One complaint that we got a lot was that we did not use certs or CAs. CyberCash was the only trusted source. There were lots of issues with deficiencies and vulnerabilities Most of which we avoided by skipping the cert concept. Still, better technology has nothing to do with business success. Public Key Crypto with out all the cruft of PKI. Its still a good idea. Pat -- Pat Farrell http://www.pfarrell.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 12:09 PM, Pat Farrell wrote: Most of which we avoided by skipping the cert concept. Still, better technology has nothing to do with business success. Public Key Crypto with out all the cruft of PKI. Its still a good idea. that became apparent in the use of SSL between all the merchant servers and the payment gateway. by the time the registration and setup process was completed at both ends ... the certificate was purely an artificial attribute of the crypto library being used. there were other issues with the payment gateway protocol ... i was able to mandate things like mutual authentication ... which didn't exist in the crypto library up to that point ... however the exchange of certificates was so engrained that it wasn't possible to eliminate (even tho all the necessary information already existed at both end-points). the merchant server/browser part ... I could only recommend ... I couldn't mandate. my analogy is that certificates PKI are electronic analogy of the letters of credit/introduction from the sailing ship days ... when the relying party had no other recourse for information about the stranger that they were dealing with. This was left over from the dail-up email days of the early 80s (dial-up electronic post-office, exchange email, hangup, and possibly have first-time email from complete stranger). that design point was quickly vanishing in the 90s with the pervasive growth of the online internet. I as at annual ACM sigmod conference in the early 90s ... and one of the big sessions, somebody asked on of the panelists what was all this x.50x gorp about. Eventually somebody explained that it was a bunch of networking engineers attempting to re-invent 1960s database technologies with certificates being armored, stand-alone, stale representation of some information from a database someplace. In the later 90s, certificates attempted to find place in no-value market niches (aka, situations involving no-value operations that couldn't justify online /or real-time information) ... although this got into some conflicts ... trying to address no-value market-niche ... at the same time claiming high-value, expensive operation. There were businesses cases floated to venture community claiming $20B certificate market ... i.e. that every person in the country would have $100/annum certificate ... some predicting that the financial community would underwrite the cost. When that didn't happen, there were other approaches. We had been called in to help wordsmith the cal. state electronic signature legislation ... which was being heavily lobbied by the PKI industry to mandate certificates. I could that rube-goldberg OCSP was response to interaction I had with some of the participants ... somebody bemoaning the fact that the financial industry needed to be brought into 20th century requiring certificates appended to every financial transaction. I responded that stale, static certificates would be retrenching to before the advent of online, real-time point-of-sale payment transactions ... aka a major step backward, not a step forward. Besides the appending a stale, static certificate to every payment transaction being redundant and superfluous ... it also represents enormous overhead bloat. There were some reduced financial, relying-party-only certificates being floated in the mid-90s ... which were still 100 times larger than the typical payment payload size (increase the size of payment transaction payload by a factor of 100 times for no beneficial purpose). The X9 financial standard group ... had some participants recognizing the enormous overhead bloat certificates represented in payments started a compressed certificate standards activity ... possibly looking to reduce the 100 times overhead bloat to only 5-10 times overhead bloat (although still redundant and superfluous). One of their techniques was that all information that was common in every certificate ... could be eliminated. Then all information that the relying party already had could be eliminated. I was able to trivial show, that a relying party would have access to every piece of information in a certificate ... and therefor digital certificates could be compressed to zero bytes. Then rather than arguing whether it was mandated that every payment transaction have an appended certificate ... we could mandate that every payment transaction have a zero-byte appended certificate. disclaimer ... eventually had a couple dozen (assigned, retain no interest) patents in the area of certificate-less public key (some showing up long after we were gone) ... summary here http://www.garlic.com/~lynn/aadssummary.htm -- 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
Ralph Holz writes: Eckersley's and Burns' presentation at Defcon (coming right up) will present their findings from a global survey of certs presented by hosts listening on port 443. Their results are disturbing. Have these results already been published somewhere, or do you maybe even have a URL? Defcon is the publishing event; and Black Hat for Ristic's material. It's in a few days (Friday evening for Ekersley and Burns). Also keep an eye on the eff.org site, I bet they'll say something there too. Possibly also at isecpartners.com. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 12:09 PM, Pat Farrell wrote: In that same time, I was at CyberCash, we invented what is now sometimes called electronic commerce. and that and $5 will get you a cup of coffee. We predated SSL by a few years. Used RSA768 to protect DES sessions, etc. Usual stuff. somewhat as result of doing the SSL payment stuff ... in the mid-90s got invited to be part of the x9a10 financial standard working group ... which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 retail payment financial standard ... which was specific in such a way that it would work with any secure authentication (including allowing both certificate certificate-less mode). The business process was slightly tweaked so it was no longer necessary to hide the information in a payment transaction to preserve the financial infrastructure integrity. This didn't eliminate skimming, evesdropping, data breaches ... but it eliminated the ability for the attackers to use the information to perform fraudulent transactions (and effectively also eliminates the major use of SSL in the world ... hiding the information in financial transaction). About the same time the x9a10 standards work was going on ... there were a couple other payment transaction specification work occurring ... which were mandating certificate operation ... somewhat trying to side-step the 100 times payload bloat. they would strip the certificate at internet gateway ... and forward the transaction thru the standard payment network with flag turned on (they could somewhat wave their hands that 100 times payload bloat on the internet was immaterial ... but not so in the real payment network) that certificate processing had occurred (compared to light-weight, super secure, x9.59 ... which operated end-to-end). There were later some presentations at ISO standards meetings that transactions were showing up with the certificate flag on ... but they could prove no certificate had been involved (i.e. there was financial interchange fee benefit motivating turning on the flag). shortly after they had published their (certificate-based) payment specification (but well before any operational code), I did a public-key op profile for their specification. I then got a friend that had a optimized BSAFE library (ran four times faster) to benchmark the profile on lots of different platforms ... and then reported the results to the groups publishing the profile. The response was my numbers were 100 times too slow (if they had actually run any numbers, their comment should have been it was four times too fast). Some six months later when they did have pilot code ... my profile numbers were within a couple percent of actual (i.e. the BSAFE library changes had been incorporated into standard distribution). -- 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
Sampo Syreeni writes: I am not sure what quantitative measurement of vulnerability would even mean. What units would said quantity be measured in? I'm not sure either. This is just a gut feeling. See also: http://nvd.nist.gov/cvsseq2.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On Tue, 27 Jul 2010 11:11:52 -0700 Chris Palmer ch...@noncombatant.org wrote: Sampo Syreeni writes: I am not sure what quantitative measurement of vulnerability would even mean. What units would said quantity be measured in? I'm not sure either. This is just a gut feeling. See also: http://nvd.nist.gov/cvsseq2.htm That scale seems remarkably arbitrary. One problem with such arbitrary scales is that there is no objective methodology one can engage in which will show that the equation is wrong in some way. Unless you can perform an experiment to falsify the self-declared objective quantitative security measurement, it isn't science. I can't think of an experiment to test whether any of the coefficients in the displayed calculation is correct. I don't even know what correct means. This is disturbing. 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
Perry E. Metzger writes: Unless you can perform an experiment to falsify the self-declared objective quantitative security measurement, it isn't science. I can't think of an experiment to test whether any of the coefficients in the displayed calculation is correct. I don't even know what correct means. This is disturbing. I can recommend a good single-malt scotch or tawny port if you like. Have you tried the Macallan 18? False metrics are rampant in the security industry. We really need to do something about them. I propose that we make fun of them. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
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 --dan, program committee - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 27/07/2010 15:11, Peter Gutmann wrote: The intent with posting it to the list was to get input from a collection of crypto-savvy people on what could be done. The issue had previously been discussed on a (very small) private list, and one of the members suggested I post it to the cryptography list to get more input from people. The follow-up message (the Part II one) is in a similar vein, a summary of a problem and then some starters for a discussion on what the issues might be. Haven't we already decided what to do: SNI? -- 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 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. 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
On Tue, Jul 27, 2010 at 09:54:51PM +0100, Ben Laurie wrote: On 27/07/2010 15:11, Peter Gutmann wrote: The intent with posting it to the list was to get input from a collection of crypto-savvy people on what could be done. The issue had previously been discussed on a (very small) private list, and one of the members suggested I post it to the cryptography list to get more input from people. The follow-up message (the Part II one) is in a similar vein, a summary of a problem and then some starters for a discussion on what the issues might be. Haven't we already decided what to do: SNI? But isn't that the problem, that SNI had to be added therefore it isn't everywhere therefore site operators don't trust its presence therefore SNI is irrelevant? Do we have any information as to which browsers in significant current use don't support SNI? Hopefully at some point site operators could declare that browsers that don't support SNI will not be supported. 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 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? Paul Tiemann (DigiCert) - 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 1:14 PM, 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 --dan, program committee Wow, I was just going to recommend Dan's book, Security Metrics. Anyone tasked with quantifying actual security should read his book. There's a pretty good dissection of ALE, and a fantastic few chapters about building a balanced scorecard to measure your operations from more perspectives than just dollars and cents. When I read that nist.gov link, the joke about the spherical cow popped into my head. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
Haven't we already decided what to do: SNI? But isn't that the problem, that SNI had to be added therefore it isn't everywhere therefore site operators don't trust its presence therefore SNI is irrelevant? It appears Apache supports SNI as of 2.2.12 which was released 12 months ago. Do we have any information as to which browsers in significant current use don't support SNI? Hopefully at some point site operators could declare that browsers that don't support SNI will not be supported. The worst of the show stoppers is IE on Windows XP. No SNI support. IE6 is still at 7.2% as of June 2010. It was 14.4% in June 2009. http://www.w3schools.com/browsers/browsers_stats.asp ... is it possible to help IE6 and other non-SNI browsers to die faster? Perry suggested reading Orwell's essay, Politics and the English Language. Think about Orwell's opening sentence: Most people who bother with the matter at all would admit that the English language is in a bad way, but it is generally assumed that we cannot by conscious action do anything about it. Now replace the English language with PKI Then... 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. So... There is a long list of outdated browsers which could be got rid of if enough people would interest themselves in the job. One fast way to pressure technological change is for the world to move on to better things and leave the legacy stuff behind. Who uses Netscape 4 or IE 5 any more? Those were left behind because everyone in web design wanted CSS support and just started using CSS. The web design field desperately wants to be throwing IE6-is-dead parties. Could some intelligent web designers come up with a few snippets of code in the various web flavors (PHP, ASP, JSP, etc) for people to easily install and include on their sites (as part of a movement to discourage old browser usage and encourage better security on the web...) If an old browser is detected, a friendly warning message or even an error message appears, along with links to the site explaining the movement... Of course it would only be grassroots, but I've heard enough rumbling on web designer blogs to think that someone might just take up a cause like that. The security community could encourage it maybe? Put a Paypal button on there. I know a lot of people who would donate money. Looks like at least one site is out there: http://ie6update.com/ but has no Paypal donate button, and doesn't offer newcomers the reasons they should switch to something more modern. Maybe this is too utopian. But laughing does work, sometimes. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
** But talking about TLS/SNI to SSL suppliers is like talking about the lifeboats on the Titanic ... we don't need it because SSL is unsinkable. Apache support for this came out 12 months ago. Does any one know of statistics that show what percentage of installed Apache servers out there are running 2.2.12 or greater? How many of the top 10 Linux distributions are past 2.2.12? A CDN might be able to push SNI forward for its own platform, but mass adoption isn't coming until we also have broad compatibility among the client browsers. SSL certs as they are currently being used are not good for much if they cause a bunch of browser warnings, so I can't see how you could really expect SSL suppliers to blast holes in their own Titanic. New standards are wonderful, but who can use them until they're well supported? This page says iPhone IOS4 supports SNI. That just came out. http://en.wikipedia.org/wiki/Server_Name_Indication ... or talking to PKI standards groups about adding a CRL reason code for certificate issued in error (e.g. to an imposter). This was turned down because CA's never make mistakes, so there's no need to have such a reason code. I wasn't around when this happened, but maybe revoking for Key compromise was considered just as good. And maybe it's rare enough not to need its own special if() statement in all the browsers. The browsers don't really do different things based on the reason code anyway (to my knowledge) Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
