Re: Is cryptography where security took the wrong branch?
> > At 09:57 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: > > ok... does anyone else want to "touch" a secured DNS system > > that has some parts fo the tree fully signed? Its a way to > > get some emperical understanding of how interesting/hard > > it is to hammer the DNS into a PKI-like thing. > > > > www.rs.net has some information. > > My assertion is 1) DNS integrity issues have to be addressed as part of > generalized DNS trust issues regardless of any use for trusted > distribution of information that may include public keys. 2) because domain > name infrastructure is the root authority for CA/PKI SSL domain name > certificates, there is a suggestion that public keys be registered as part > of domain name registration (to fix trust issues in domain infrastructure > on behalf of the CA/PKI industry). Being able to trust DNS ... and having > registered public keys means that existing DNS information > distribution operation can turn itno trusted distribution of public keys > (aka existing DNS infrastructure supports distribution of any information > that happens to be registered). Nice collection of URLs. Ack both your assertions. RS.NET is a testbed that is being used to validate the accuray of those assertions and explore the operational and social impact with the deployment of a DNS that can respond with information which can be independently verified for accuracy. --bill - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 09:57 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: ok... does anyone else want to "touch" a secured DNS system that has some parts fo the tree fully signed? Its a way to get some emperical understanding of how interesting/hard it is to hammer the DNS into a PKI-like thing. www.rs.net has some information. a normal cache-based system attempts to make everything appear as if it is online and dynamic with the characteristics of information caching as close as possibly transparent to the relying-parties. one might claim that PKIs have tried to turn long-lived certificate-based "cache-entries" into a cult (aka from a information theory standpoint, certificates are a form of free-standing, somewhat self-describing, stale, static, long-lived cache entries) in part to create an independent revenue flow based on these cult objects. standard cache infrastructures usually attempt to go out of their way to try and make caching operation transparent to relying-parties (and can dynamically change/eliminate caching details to meet specific business requirement). domain name infrastructure needs to support 1) trusted information distribution and may implement 2) cached entries. DNS has never been restricted to just trusted information distribution of IP-addresses. CA/PKI SSL domain name certificates were deployed, in part because of integrity concerns about the domain name infrastructure. However, the "trust root" for CA/PKI SSL domain name certificates is still the domain name infrastructure (as to the authoritative owner of a domain name). Turning DNS into a PKI-like thing happens only in the sense that CA/PKIs have only been a trusted distribution of public keys ... while DNS has always been a (somewhat) trusted distribution of any information (that happens to be registered with them). Adding public keys to DNS distribution is only turning it into a PKI-like thing from the standpoint that DNS hasn't in the past ben used as a trusted distribution for public key specific information (and the issue about the level of trust you can actually have in DNS). My assertion is 1) DNS integrity issues have to be addressed as part of generalized DNS trust issues regardless of any use for trusted distribution of information that may include public keys. 2) because domain name infrastructure is the root authority for CA/PKI SSL domain name certificates, there is a suggestion that public keys be registered as part of domain name registration (to fix trust issues in domain infrastructure on behalf of the CA/PKI industry). Being able to trust DNS ... and having registered public keys means that existing DNS information distribution operation can turn itno trusted distribution of public keys (aka existing DNS infrastructure supports distribution of any information that happens to be registered). some past threads about transition steps for DNS trust which could include having cache entries that instead of being naked public keys could be digitally signed cache entries (sharing some characteristics in common to stale, static, long-lived, free-standing digitally signed certificate objects): http://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions http://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form) http://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form) http://www.garlic.com/~lynn/aadsm14.htm#17 Payments as an answer to spam (addenda) http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda) http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps http://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda) -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
> > At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: > > There are some other problems w/ using the DNS. > > No revolkation process. > > DNS caching > > third-party trust (DNS admins != delegation holder) > > Given high value &/or low trust ... relying parties still have option of > directly contacting root authority. And as outline, the root authority is > also the root authority for the CA/PKIs. If you attack the root trust > authority with false information then all subsequent trust operations > flowing from that false information is suspect. Domain name system still > has some exploits against the root database resulting in false information > but since that is the root for both DNS as well as CA/PKIs generating > SSL domain name certificates it is a common failure point for both > infrastructures. It needs to be fixed, in order to improve trust on either > the DNS side or the CA/PKI side (doesn't matter how thick you make the > vault door if somebody forgot to complete the back wall on the vault). ok... does anyone else want to "touch" a secured DNS system that has some parts fo the tree fully signed? Its a way to get some emperical understanding of how interesting/hard it is to hammer the DNS into a PKI-like thing. www.rs.net has some information. > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 08:14 AM 9/10/2003 -0600, Anne & Lynn Wheeler wrote: entry. We ran into a problem with doing consistent database updates over NFS (network filesystem) because while NFS advertises itself as item potent, most client implementations have this 8k cache that can be stale. fingers typing w/o brain syncronized ... it should have been idempotent not item potent. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder) Since DNS is a online positive list you change the database ... and voila it is updated. This is the scenario for credit cards going from pre-70s technology with plastic cards and the monthly revokation booklet mailed out to all merchants. The credit card industry transitioned to online infrastructure where it transactions are denied by updating the online database. It eliminates the revokation process, since there aren't an unknown number of copies of static, stale credentials/certificates floating around the world potentially being presented to an unknown variety of relying parties. DNS caching is the closest equivalent of the certificate paradigm of static, stale copies floating around the world. The two slight differences are that cached stale, static entries tend to have very short lifetimes ... they come into creation by activities by the relying-party (not the entity being authenticated) and tend to have very short lifetimes of a few hours to at most a day. However, relying-parties have the choice of going directly to the root and obtaining the current copy a function somewhat filled in the PKI world by OCSP although OCSP is just a check about whether the current, static, stale copy in a relying-party's possession is current ... not what the current entry is.. From information theory standpoint, stale, static certificates are logically a form of long-lived, distributed, replicated, r/o, cache entries. Cache entry semantics have been studied in some detail in areas like distributed file systems and multiprocessor consistent shared memory caches, etc. With short-lived r/o, distributed cache entires (like DNS) ... there is a trade-off involving 1) entry life-time, 2) frequency of change, 3) impact of dealing with stale entry. We ran into a problem with doing consistent database updates over NFS (network filesystem) because while NFS advertises itself as item potent, most client implementations have this 8k cache that can be stale. Given high value &/or low trust ... relying parties still have option of directly contacting root authority. And as outline, the root authority is also the root authority for the CA/PKIs. If you attack the root trust authority with false information then all subsequent trust operations flowing from that false information is suspect. Domain name system still has some exploits against the root database resulting in false information but since that is the root for both DNS as well as CA/PKIs generating SSL domain name certificates it is a common failure point for both infrastructures. It needs to be fixed, in order to improve trust on either the DNS side or the CA/PKI side (doesn't matter how thick you make the vault door if somebody forgot to complete the back wall on the vault). random, unrelated refs to past life working on processor cache design, distributed filesystems, and distributed databases http://www.garlic.com/~lynn/subtopic.html#smp http://www.garlic.com/~lynn/subtopic.html#hacmp -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
> >certificate requests coming into a CA/PKI can be digitally signed, the > >CA/PKI can retrieve the authoritative authentication public key (for the > >domain name ownership) from the domain name infrastructure and > >authenticate the request eliminating all the identification gorp (and > >also done w/o the use of certificates). > > > >misc. additional recent musings: > >http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model > >(At least I hope it's new) Not particularly new. This was/is the promise of DNSSEC. early work, the TBDS and FMESHD projects. Current IETF work, OE and IPSECKEY. > The problem is that the domain name infrastructure has a database of domain > name owners but no real good infrastructure ... Not entirely. The reverse maps are a well defined infrastructure space. > Of course, the bottom line is if the domain name infrastructure has a > real-time database of public keys for authentication purposes in part > for use by the CA/PKI industry for authenticating SSL domain name > certificate requests for use in authentication operations the use > of the domain name infrastructure's authentication public keys don't have > to just be restricted to authentication use by the CA/PKI industry. In > fact, domain name infrastructure authentication public keys could be used > to effectively for authentication operations that actually subsume the SSL > domain name certificates authentication operations. There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder) > > -- > Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ > Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 05:07 PM 9/9/2003 -0700, Joseph Ashwood wrote: Now that the waters have been muddied (by several of us). My point was that 3D-Secure (and SET and whatever else comes along) covers a different position in the system than SSL does (or can). As such they do have a purpose, even though they may be horribly bloated and nearly non-functional. Visa at least seems to be supporting the 3D-Secure concept (they should, they developed it), and looks like anyone can grab the spec from ... while SET, 3d-secure, etc may have been designed for all sorts of reasons I guess my point was that w/o a adequately specified threat model for the primary vulnerabilities ... there turned out to be little effective difference between the use of SET and the use of SSL (regardless of what the designers may have original thot). Also technology adoption/uptake typically requires the transition to be less painful than the problem it is fixing. SSL was already in the market space ... so SET had to demonstrate that it was incrementally better (not effectively the "same as" for the major vulnerabilities) in order to justify its significantly more difficult and costly deployment. The other issue that has been the bane of major PKI/certificate deployments (and I've repeatedly raised the issue) ... is that certificate-based operations typically have the key owner paying for the certificate while the major benefit accrues to the relying-party ... the the key/certificate owner. In the case of SET ... there was the consumer payng for their certificate and the merchant not only receiving a better than MOTO-discount (making interchange transactions with the "SET" flag turned on ... somewhat suspecious) ... but also the possibility that the transaction would be treated as "authenticated" and potentially shifting the burden of proof in a dispute from the merchant to the consumer. There was the possibility that not only would the consumer be footing the bill (buying their own certificate) for the sole benefit of reducing what the merchant paid on the transaction but there was also speculation that it might also be used to make it more difficult for the consumer (there was sporadic mention of shifting the burden of proof from the merchant to the consumer in a dispute). At least in the SSL domain name certificate, the merchant pays because of some belief that it will help attracted (internet) consumers/business. In the SET/PKI scenario ... it was nearly impossible to figure out a value proposition for the consumer where the consumer is footing the (certificate) bill ... that turns out to be totally for the benefit of the merchant. It wasn't so much that "cryptography took a wrong branch" ... but many of the PKI business models don't conform to any sane business operation with the entity (key-owner) footing the bill not getting any benefit ... and all the benefit going to the relying-party. The other generalized PKI issue (again not just SET) ... is "any" contract tends to be between the CA?PKI and the consumer aka the entity in a contract that purchases something. Frequently is no contractual relationship between the relying-parties who effectively the sole reason that the certificates exist ... and the CA/PKI. As mentioned elsewhere, the GSA PKI has attempted to somewhat address this by having all relying-parties sign contracts with the GSA and all the CA/PKI certificate issuing entities have a contract with the GSA where they are effectively issuing certificates on behalf of the GSA. Those set of contracts then preovide the legal foundation for some generic reason for relying-parties to do anything with certificates (since the relying-parties and the CA/PKI agency, aka GSA ... have contractual relationship and therefor a legal reason to deal with certificates). The slightly different SET scenario ... the associations just told the merchants that they would be charged less per transaction ... aka instead of MOTO (mail order, telephone order) discount, they could get something closer to card present discount. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Now that the waters have been muddied (by several of us). My point was that 3D-Secure (and SET and whatever else comes along) covers a different position in the system than SSL does (or can). As such they do have a purpose, even though they may be horribly bloated and nearly non-functional. Visa at least seems to be supporting the 3D-Secure concept (they should, they developed it), and looks like anyone can grab the spec from http://international.visa.com/fb/paytech/secure/main.jsp . SET seems to be a bit more elusive, although still available from http://www.mastercardintl.com/newtechnology/set/ . Mastercard SecureCode appears to be the current direction for MasterCard it's available at http://www.mastercardmerchant.com/securecode/ . All of these differ in target from SSL in the same way, they are designed to address the Buyer-Issuer link (although some not as simply as others, e.g. SET). And yes I am using a much simplified view of the credit card transaction, with only 3 (buyer, seller, issuer) parties instead of the absurd number actually present in a real transaction (buyer seller, issuer, accepter, processor, central card distributor, plus whoever I missed), I did this for clarity. Joe Trust Laboratories Changing Software Development http://www.trustlaboratories.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 05:19 PM 9/7/2003 -0600, Anne & Lynn Wheeler wrote: Out of all this, there is somewhat a request from the CA/PKI industry that a public key be registered as part of domain name registration (no certificate, just a public key registration). Then SSL domain name certificate requests coming into a CA/PKI can be digitally signed, the CA/PKI can retrieve the authoritative authentication public key (for the domain name ownership) from the domain name infrastructure and authenticate the request eliminating all the identification gorp (and also done w/o the use of certificates). misc. additional recent musings: http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new) The "Database gaps make ID fraud easier, GAO says" http://www.gcn.com/vol1_no1/daily-updates/23446-1.html is somewhat analogous to the SSL domain name certificate problem ... a primary purpose for existing is to authenticate that the website you think you are talking to is the website you are talking to. The problem is that the domain name infrastructure has a database of domain name owners but no real good infrastructure ... and the CA/PKI operations doing SSL domain name certifications are disjoint from the domain name infrastructure operations. As a result effectively the CA/PKI industry has to treat requests for SSL domain name certificates effectively as if it was a random person walking in from the street ... and then they have to try and match up such seemingly random requests ... with what little bit of information that they can extract from the domain name infrastructure (seeing if they can establish an identity in the real world based on the DNS database information ... and see if that identity then can be matched against the identity of the entity requesting the certificate). Adding a public key to the domain name infrastructure database as part of the domain name registration process then eliminates the requirement of trying to establishing corresponding identities in the real world ... and it just reduces to a question of authentication. Of course, the bottom line is if the domain name infrastructure has a real-time database of public keys for authentication purposes in part for use by the CA/PKI industry for authenticating SSL domain name certificate requests for use in authentication operations the use of the domain name infrastructure's authentication public keys don't have to just be restricted to authentication use by the CA/PKI industry. In fact, domain name infrastructure authentication public keys could be used to effectively for authentication operations that actually subsume the SSL domain name certificates authentication operations. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
e useless for fraud. slightly related discussion of the "security proportional to risk" and the vulnerability represented by the merchant transaction file http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe??? misc. recent SET refs: http://www.garlic.com/~lynn/aadsm15.htm#0 invoicing with PKI http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch? http://www.garlic.com/~lynn/aadsm15.htm#3 Is cryptography where security took the wrong branch? -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
- Original Message - From: "Ian Grigg" <[EMAIL PROTECTED]> Sent: Sunday, September 07, 2003 12:01 AM Subject: Re: Is cryptography where security took the wrong branch? > That's easy to see, in that if SSL was oriented > to credit cards, why did they do SET? (And, > SHTTP seems much closer to that mission, on a > quick reading, at least.) Actually they do target very different aspects. SET, 3D-Secure, and any other similar have a different target then SSL. To understand this it is important to realize that instead of the usual view of two-party transactions, credit card transactions actually take 3 parties; Issuer, Seller, and Buyer. SSL covers the Seller-Buyer communication, and can also be applied to the Seller-Issuer communication, but on a transaction basis it offers nothing for the Issuer-Buyer (the important one for minimizing costs for the Issuer). SET/3D-Secure/etc address this through various means but the end target is to create a pseudo-Buyer-Issuer link, through the Seller. This allows the Issuer to minimize costs (less chance of having to make a call) and because it is behind the scenes technology has no reason to be accompanied by a reduction in fees (and actually because of the reduced likelihood of buyer fraud, it may be possible to charge the seller _more_). In the end SSL and SET/3D-Secure/etc target entirely different portions of the problem (the former targets seller fraud against the buyer, latter seller against issuer). Both of these are important portions, of course the real upside of SET/3D-Secure/etc is that the seller doesn't have a choice, and the fees in accordance with the "fraud-reduction" may very well increase the costs to the seller, the buyer costs of course stay the same. End result: lower fraud, increased fees->higher profit margins. However, if it meets expectations, it is entirely possible that all legitimate parties (non-fraud entities) will see improved profits (seller has reduced fraud and charge-backs, buyer less likelihood of the $50 penalty, issuer higher fees). Will it meet those expectations? I have no idea. Joe Trust Laboratories Changing Software Development http://www.trustlaboratories.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: > Ben Laurie <[EMAIL PROTECTED]> writes: > > >>Eric Rescorla wrote: >> >>>Incidentally, when designing SHTTP we envisioned that credit >>>transactions would be done with signatures. I would say that >>>the Netscape guys were right in believing that confidentiality >>>for the CC number was good enough. >> >>I don't think so. One of the things I'm running into increasingly with >>HTTPS is that you can't do an end-to-end check on a cert. That is, if I >>have some guy logging into some site using a client cert, and that site >>then makes a back-end connection to another site, there's no way it can >>prove to the back-end site that it has the real guy online (without >>playing nasty tricks with the guts of SSL, anyway), and there's >>certainly no way to prove that some particular response came from him. >>Signing stuff would deal with this trivially. > > > Well, I'd certainly like to believe that this is true, since > it would mean that Allan and I were right all along. :) You _were_ right all along. At least about this :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
-- At 12:30 PM 9/7/2003 -0700, James A. Donald wrote: > > To the extent that trust information is centrally handled, > > as it is handled by browsers, it will tend to be applied in > > ways that benefit the state and the central authority On 7 Sep 2003 at 17:19, Anne & Lynn Wheeler wrote: > Out of all this, there is somewhat a request from the CA/PKI > industry that a public key be registered as part of domain > name registration (no certificate, just a public key > registration). Then SSL domain name certificate requests > coming into a CA/PKI can be digitally signed, the CA/PKI can > retrieve the authoritative authentication public key (for the > domain name ownership) from the domain name infrastructure > and authenticate the request eliminating all the > identification gorp (and also done w/o the use of > certificates). I seem to recollect that request, or a request very like it, from some years back. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG HwFde4LnTv0p3hXtAQB7k2SuW04BmKJDrrnyzvRr 4d+oWUHfpousTBWRKiFyUmAecGZRIK1gitZ4NELNp - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > > Maybe, maybe not. You've never heard of price inelasticity? > > > You haven't established anything beyond some apparent > intention to consider inelasticity, as if it is some > superior magic property we have to do battle with. Ian, The situation is really simple: You wrote: "The other thing to be aware of is that ecommerce itself is being stinted badly by the server and browser limits. There's little doubt that because servers and browsers made poorly contrived decisions on certificates, they increased the overall risks to the net by reducing the deployment, and probably reduced the revenue flow for certificate providers by a factor of 2-5." I asked you where you got the factor of 2-5 and you waved your hands a lot and didn't really provide any real answer. As it happens, I'm extremely familiar with the set of techniques that one would use in order to derive a number like this and it's quite apparent that you haven't used any of them. As a consequence, there's no reason to take your estimate as anything other than some number that you pulled out of the air. None of this is to say that it's not potentially worth trying to change things and see if it makes a difference. What I object to, however, is quantitative claims made without evidence, which is what you have been doing here. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: > Elasticity is about how much consumption changes when price > changes, not about what people who were already going to buy > choose to buy. Sorry, Eric, I'm not quite with you on this... You said: > > Maybe, maybe not. You've never heard of price inelasticity? You haven't established anything beyond some apparent intention to consider inelasticity, as if it is some superior magic property we have to do battle with. Then, you said: > The fact of the matter is that we have no real idea how > elastic the demand for certs is Firstly, most goods are elastic. The natural order of things is that if you want to establish that your particular claimed good is otherwise, then you might want to show it? Please? So, let's call this bluff: please show why and how the demand for certs is inelastic! Secondly, I'm proposing self-signed certs. What does price inelasticity mean when the price is zero? > Ian, it's a major econometrics project to determine how > elastic a given good has. To imagine that you can do > it with a little handwaving is simply naive. Thirdly, after we have established the inelasticity of the certs in question - a tough call - and we've also established that it means something even when the price is zero... ...we now want to establish how useful a tool is that won't measure it, as you assert, without such a "major econometrics project?" I'm curious, why did you bring econometrics up if it is too hard to use? And, why should *I* use it? The certs are elastic, until I see something to the contrary. Fourthly, econometrics delivers explanatory power. I.e., the past. It is weak on predictive power. I.e., the future. That's because the assumptions are arbitrary. And, that's why marketeers don't use econometrics: they prefer to change the assumptions, which takes us out of the data set. Which is where I am: the assumptions. First step, examine the assumptions of the past. That's what we on this list have been doing for the last 6 months. Second step, change them. iang PS: I'm curious, is there some URL that talks about application of inelasticity and econometrics to crypto? Somebody who's selling the notion? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg wrote: Pretty much. "Trust" in the certificate world means that a CA has authorised a web server to conduct crypto stuff. and James Donald and Lynn Wheeler also brought up the issues of who's certifying what, True Names, etc. SSL certs are really addressing (I won't say "solving", exactly) two different problems - - Whether the communication session you're setting up with example.com is really set up with them and not a MITM - Whether Example.com is slightly more likely to be run by Example Inc., and not some impostor like Example-Nigeria Ltd or Bad Example Spa Resort, GMBH, both of whom happily accept all major credit cards. DNSSEC (or something like it) takes care of the first problem, without the intervening step of requiring True Names. It doesn't help the second problem, and DNS doesn't either, which is one reason that ICANN is so insistent on getting True Names for whois records and forcing registrars to get them as well. It's possible to get some uncertified human-readable information about a domain name from its whois records. It's possible to get more human-readable information from SSL certs, and in some cases that information might be certified in a meaningful way, but in other cases it's not, and browsers aren't typically very good at telling you that information unless you try hard to get it, and when they do nag users about it, users usually ignore it. But it's not always even useful information - Bad Example might have a cert from trustcenter.de because they take Visa cards at their spa, but you may be on their _other_ web site that's selling cheap knockoffs of whatever the Example Inc. you were trying to deal with sells. Your browser isn't smart enough to know that. While DNSSEC mostly follows a hierarchical model, that doesn't mean that you couldn't get some user-friendly or browser-friendly certification model that does provide multi-homed values for rating information about web sites - Consumer Reports or the Better Business Bureau or whatever could do signed statements about domain names without building it into DNS or SSL. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 12:30 PM 9/7/2003 -0700, James A. Donald wrote: To the extent that trust information is centrally handled, as it is handled by browsers, it will tend to be applied in ways that benefit the state and the central authority. Observe for example that today all individual certificates must be linked to one's true name and social security number if it is to receive default acceptance, and analogously for corporate certificates. in the case of SSL domain name certificate for both domain name infrastructure and CA/PKI it is is a case of authenticating that the the web site you think you are talking to is really the web site you are talking to. The business issue is that the domain name registration and the CA/PKI are disjoint business operations and the domain name registration didn't provide for a really good authentication mechanism. As a result when getting a certificate request, the CA/PKI has to check with the domain name infrastructure map their information out to an external world identification, and then map the entity making the certificate request out to the same external world identification. Out of all this, there is somewhat a request from the CA/PKI industry that a public key be registered as part of domain name registration (no certificate, just a public key registration). Then SSL domain name certificate requests coming into a CA/PKI can be digitally signed, the CA/PKI can retrieve the authoritative authentication public key (for the domain name ownership) from the domain name infrastructure and authenticate the request eliminating all the identification gorp (and also done w/o the use of certificates). misc. additional recent musings: http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new) -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 09:44 AM 9/7/2003 -0700, Eric Rescorla wrote: Incidentally, when designing SHTTP we envisioned that credit transactions would be done with signatures. I would say that the Netscape guys were right in believing that confidentiality for the CC number was good enough. actually was supposedly no worse than the face-to-face world aka make the transit part secure ... so that the rest became the same as the physical world transactions go into big merchant file ... because there are several merchant related business processes that subsequently reference the transaction and number. the problem was that their appear to be little or not fraud associated with threats against CC numbers in flight (with or w/o SSL), however the threat model was against the merchant credit card file and the numbers in the clear; it wasn't that the process was any different than the physical world, but the web merchants allowed the file to be access able from the network (which didn't exist in the physical world). the requirement given the x9a10 working group was to preserve the integrity of the financial infrastructure for all electronic retail payments (debit, credit, stored-value, ach, internet, non-internet, point-of-sale, etc). Turns out the internet threat profile wasn't so much data-in-flight but having the operation connected to the internet at all. X9.59 addressed most of that ... which neither ssl or set did and did it with just a single digital signaturee. misc. x9.59 http://www.garlic.com/~lynn/index.html#x959 -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
"James A. Donald" <[EMAIL PROTECTED]> writes: > -- > On 7 Sep 2003 at 9:48, Eric Rescorla wrote: > > It seems to me that your issue is with the authentication > > model enforced by browsers in the HTTPS context, not with SSL > > proper. > > To the extent that trust information is centrally handled, as > it is handled by browsers, it will tend to be applied in ways > that benefit the state and the central authority. Yeah, I'd noticed that being able to buy stuff at Amazon really didn't benefit me at all. -Ekr - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ben Laurie <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > Incidentally, when designing SHTTP we envisioned that credit > > transactions would be done with signatures. I would say that > > the Netscape guys were right in believing that confidentiality > > for the CC number was good enough. > > I don't think so. One of the things I'm running into increasingly with > HTTPS is that you can't do an end-to-end check on a cert. That is, if I > have some guy logging into some site using a client cert, and that site > then makes a back-end connection to another site, there's no way it can > prove to the back-end site that it has the real guy online (without > playing nasty tricks with the guts of SSL, anyway), and there's > certainly no way to prove that some particular response came from him. > Signing stuff would deal with this trivially. Well, I'd certainly like to believe that this is true, since it would mean that Allan and I were right all along. :) -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > > > Ian Grigg <[EMAIL PROTECTED]> writes: > > > > > Eric Rescorla wrote: > > > ... > > > > > The other thing to be aware of is that ecommerce itself > > > > > is being stinted badly by the server and browser limits. > > > > > There's little doubt that because servers and browsers > > > > > made poorly contrived decisions on certificates, they > > > > > increased the overall risks to the net by reducing the > > > > > deployment, and probably reduced the revenue flow for > > > > > certificate providers by a factor of 2-5. > > > > I doubt that. Do you have any data to support this claim? > > > > > > Sure. SSH. > > That's not data, it's an anecdote--and not a very supportive one > > at that. As far as I know, there isn't actually more total > > SSH deployment than SSL, so you've got to do some kind of > > adjustment for the total potential size of the market, which > > is a notoriously tricky calculation. > > It's more than an anecdote. If I quote from your > slides, SSH has achieved an almost total domination > of where it can be deployed. No. There are lots of other things you CAN do with SSH that people don't do that often. > > Do you have any actual > > data or did you just pull 2-5 out of the air? > > > There is a middle ground between data and the air, > which is analysis. Data precedes analysis. > It's nothing to do with whether the ivory tower > brigade does some econowhatsists on their models > and then speculates as to what this all means. > > Have a look at the data that is available [2]. You > will see elasticity. Have a look at the history > of a little company called Thawte. There, you will > see how elasticity contributed to several hundred > millions of buyout money. Nope. Elasticity is about how much consumption changes when price changes, not about what people who were already going to buy choose to buy. Look at it this way: If Pepsi cut their price by 50%, it might affect their market share but would have only a very small amount of effect on how much fluid people consume overall. The market for beverages is competitive but not particularly elastic. That could easily be happening here. Ian, it's a major econometrics project to determine how elastic a given good has. To imagine that you can do it with a little handwaving is simply naive. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ed, I've left your entire email here, because it needs to be re-read several times. Understanding it is key to developing protocols for security. Ed Gerck wrote: > > Arguments such as "we don't want to reduce the fraud level because > it would cost more to reduce the fraud than the fraud costs" are just a > marketing way to say that a fraud has become a sale. Because fraud > is an hemorrhage that adds up, while efforts to fix it -- if done correctly > -- are mostly an up front cost that is incurred only once. So, to accept > fraud debits is to accept that there is also a credit that continuously > compensates the debit. Which credit ultimately flows from the customer > -- just like in car theft. What you are talking about there is a misalignment of interests. That is, the car manufacturer has no incentive to reduce the theft (by better locks, for e.g.) if each theft results in a replacement sale. Conventionally, this is dealt with by another interested party, the insurer. He arranges for the owner to have more incentive to look after her car. He also publishes ratings and costs for different cars. Eventually, the car maker works out that there is a demand for a car that doesn't incur so many follow-on costs for the owner. This is what we call a "free market" solution to a problem. The alternative would be some form of intervention into the marketplace, by some well- meaning "authority." The problem with the intervention is that it generally fails to arise and align according to the underlying problem. That is, the authority is no such, and puts in place some crock according to his own interests. E.g., ordering all car manufacturers to fit NIST standard locks (as lobbied for by NIST-standard lock makers). Or giving every car owner a free steering lock. And, that's more or less what we have with HTTPS. A security decision by the authority - the early designers - that rides on a specious logical chain with no bearing on the marketplace, and the result being a double block against deployment. (It's interesting to study these twin lock-ins, where two parties are dependant on the other for their mutual protocol. For those interested, the longest running commercial double cartel is about to come crashing down: DeBeers is now threatened by the the advent of gem quality stones for throwaway prices, its grip on the mines and retailers won't last out the decade. Understanding how DeBeers created its twin interlocking cartels is perhaps the best single path to understanding how cartels work.) > Some 10 years ago I was officially discussing a national > security system to hep prevent car theft. A lawyer representing > a large car manufacturer told me that "a car stolen is a car sold" > -- and that's why they did not have much incentive to reduce > car theft. Having the car stolen was an "acceptable risk" for > the consumer and a sure revenue for the manufacturer. In fact, a > car stolen will need replacement that will be provided by insurance > or by the customer working again to buy another car. While the > stolen car continues to generate revenue for the manufacturer in > service and parts. > > The "acceptable risk" concept is an euphemism for that business > model that shifts the burden of fraud to the customer, and eventually > penalizes us all with its costs. > > Today, IT security hears the same argument over and over again. > For example, the dirty little secret of the credit card industry is that > they are very happy with +10% of credit card fraud over the Internet. > In fact, if they would reduce fraud to zero today, their revenue > would decrease as well as their profits. Correct! You've revealed it. IMHO, not understanding that fact has been at the root cause of more crypto biz failures than almost any other issue. My seat of the pants view is that over a billion was lost in the late eighties on payments ventures alone (I worked for a project that lost about 250 million before it gave up and let itself be swallowed up...). In reality, the finance industry cares little about reducing fraud. This is easy to show, as you've done. > There is really no incentive to reduce fraud. On the contrary, keeping > the status quo is just fine. > > This is so mostly because of a slanted use of insurance. Up to a certain > level, which is well within the operational boundaries, a fraudulent > transaction does not go unpaid through VISA, American Express or > Mastercard servers. The transaction is fully paid, with its insurance cost > paid by the merchant and, ultimately, by the customer. > > Thus, the credit card industry has successfully turned fraud into > a sale. This is the same attitude reported to me by that car manufacturer > representative who said: "A car stolen is a car sold." > > The important lesson here is that whenever we see continued fraud, we must > be certain: the defrauded is profiting from it. Because no company will accept > a continued loss ithout doing anythi
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > > Eric Rescorla wrote: > > ... > > > > The other thing to be aware of is that ecommerce itself > > > > is being stinted badly by the server and browser limits. > > > > There's little doubt that because servers and browsers > > > > made poorly contrived decisions on certificates, they > > > > increased the overall risks to the net by reducing the > > > > deployment, and probably reduced the revenue flow for > > > > certificate providers by a factor of 2-5. > > > I doubt that. Do you have any data to support this claim? > > > > Sure. SSH. > That's not data, it's an anecdote--and not a very supportive one > at that. As far as I know, there isn't actually more total > SSH deployment than SSL, so you've got to do some kind of > adjustment for the total potential size of the market, which > is a notoriously tricky calculation. It's more than an anecdote. If I quote from your slides, SSH has achieved an almost total domination of where it can be deployed. Wherever there are Unix servers, we suspect the domination of SSH. (I haven't got a good figure on that. Some stats have been done Neils Provos and Peter Honeyman in a paper, but I can't interpret the results sufficiently to show SSH server distribution, nor penetration [1]. It's now a hot topic, so I believe the figures will become available in time.) > Do you have any actual > data or did you just pull 2-5 out of the air? There is a middle ground between data and the air, which is analysis. I've been meaning to write it up, but I'm working on the SSL threat model right now. > > It's about take up models. HTTPS' > > model of take-up is almost deliberately designed > > to reduce take-up. It uses a double interlocking > > enforcement on purchase of a certificate. Because > > both the browser and server insist on the cert > > being correct and CA-signed and present, it places > > a barrier of size X in front of users. > I don't know where you got the idea that the server insists on cert > correctness. Neither ApacheSSL nor mod_SSL does. I take the following approach here. I think that for Apache to promote the interests of the users, it should configure automatically to run SSL, and automatically generate a self-signed cert on install (unless there is one there already). I admit I haven't looked to see whether that is reasonable or possible, but I gather it does neither of those things, and it certainly doesn't make doing self- signed certs so easy. Oh, and Apache does lead one astray by calling the self-signed cert a "snake-oil" cert. This misleads the users into thinking there is something wrong with a self-signed cert. I'm not sure how easy that is to correct. > > Instead, if there were two barriers, each of half-X, > > being the setup of the SSL server (a properly set > > up browser would have no barrier to using crypto), > > and the upgrade to a CA-signed cert, then many more > > users would clear the hurdles, one after the other. > Maybe, maybe not. You've never heard of price inelasticity? > > The fact of the matter is that we have no real idea how > elastic the demand for certs is, and we won't until someone > does some real econometrics on the topic. Unless you've > done that, you're just speculating. The reason we have no idea how elastic the demand for certs is, is because a) we've never tried it, and b) we've not looked at the data that exists. (Yes, those reasons are contradictory. That's part of the world that we want to change.) It's nothing to do with whether the ivory tower brigade does some econowhatsists on their models and then speculates as to what this all means. Have a look at the data that is available [2]. You will see elasticity. Have a look at the history of a little company called Thawte. There, you will see how elasticity contributed to several hundred millions of buyout money. Mark S prays to the god of elasticity every night. Check out the Utah digsig model. If you can see a better proof of cert elasticity, I'd like to know about it. iang [1] http://www.citi.umich.edu/u/provos/ssh/ http://www.citi.umich.edu/techreports/reports/citi-tr-01-13.pdf [2] http://www.securityspace.com/ http://www.securityspace.com/s_survey/sdata/200308/certca.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: > Incidentally, when designing SHTTP we envisioned that credit > transactions would be done with signatures. I would say that > the Netscape guys were right in believing that confidentiality > for the CC number was good enough. I don't think so. One of the things I'm running into increasingly with HTTPS is that you can't do an end-to-end check on a cert. That is, if I have some guy logging into some site using a client cert, and that site then makes a back-end connection to another site, there's no way it can prove to the back-end site that it has the real guy online (without playing nasty tricks with the guts of SSL, anyway), and there's certainly no way to prove that some particular response came from him. Signing stuff would deal with this trivially. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "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 [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > ... > > > The other thing to be aware of is that ecommerce itself > > > is being stinted badly by the server and browser limits. > > > There's little doubt that because servers and browsers > > > made poorly contrived decisions on certificates, they > > > increased the overall risks to the net by reducing the > > > deployment, and probably reduced the revenue flow for > > > certificate providers by a factor of 2-5. > > I doubt that. Do you have any data to support this claim? > > Sure. SSH. That's not data, it's an anecdote--and not a very supportive one at that. As far as I know, there isn't actually more total SSH deployment than SSL, so you've got to do some kind of adjustment for the total potential size of the market, which is a notoriously tricky calculation. Do you have any actual data or did you just pull 2-5 out of the air? > It's about take up models. HTTPS' > model of take-up is almost deliberately designed > to reduce take-up. It uses a double interlocking > enforcement on purchase of a certificate. Because > both the browser and server insist on the cert > being correct and CA-signed and present, it places > a barrier of size X in front of users. I don't know where you got the idea that the server insists on cert correctness. Neither ApacheSSL nor mod_SSL does. > Instead, if there were two barriers, each of half-X, > being the setup of the SSL server (a properly set > up browser would have no barrier to using crypto), > and the upgrade to a CA-signed cert, then many more > users would clear the hurdles, one after the other. Maybe, maybe not. You've never heard of price inelasticity? The fact of the matter is that we have no real idea how elastic the demand for certs is, and we won't until someone does some real econometrics on the topic. Unless you've done that, you're just speculating. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
-- On 7 Sep 2003 at 9:48, Eric Rescorla wrote: > It seems to me that your issue is with the authentication > model enforced by browsers in the HTTPS context, not with SSL > proper. To the extent that trust information is centrally handled, as it is handled by browsers, it will tend to be applied in ways that benefit the state and the central authority. Observe for example that today all individual certificates must be linked to one's true name and social security number if it is to receive default acceptance, and analogously for corporate certificates. To the extent that trust information is decentralized in end user databases, as it is handled by SSH clients it will tend to be applied in ways that benefit the end user. Unsurprisingly, we observe greater end user utilization of SSH public keys. The vast majority of people encounter the concept of a public key when they log on to an SSH server. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG +VOl3Vqd/2KPdwuRgmR7CoTexKy84DdSChLXr3rS 4WcxJQwYP0cvPgTXK3Xq5OaTtELGHKXqra0DHd90x - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: ... > > The other thing to be aware of is that ecommerce itself > > is being stinted badly by the server and browser limits. > > There's little doubt that because servers and browsers > > made poorly contrived decisions on certificates, they > > increased the overall risks to the net by reducing the > > deployment, and probably reduced the revenue flow for > > certificate providers by a factor of 2-5. > I doubt that. Do you have any data to support this claim? Sure. SSH. It's about take up models. HTTPS' model of take-up is almost deliberately designed to reduce take-up. It uses a double interlocking enforcement on purchase of a certificate. Because both the browser and server insist on the cert being correct and CA-signed and present, it places a barrier of size X in front of users. Instead, if there were two barriers, each of half-X, being the setup of the SSL server (a properly set up browser would have no barrier to using crypto), and the upgrade to a CA-signed cert, then many more users would clear the hurdles, one after the other. How high can you jump? When I was young we used to do this high jump thing, where we'd get up to 5 feet or so. I could never do 6 feet. I couldn't even do 4 feet these days, but, I could do any number of 3 feet jumps. I could probably even do a few 3 feet jumps these days. (In that youth, we called them by feet. These days, a one metre jump looks more imposing...) I'm curious. You really think that in order to sell certificates, the best thing is to make them hard to use? Is this a "quality" argument? iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg <[EMAIL PROTECTED]> writes: > But, it's now a decade down the path, and its well > time to re-assess whether SSL/HTTPS, etc, is using > the right models to benefit us. Or anybody, really. To follow up on this line a little more, I don't see why you're so hung up on SSL here. SSL is perfectly capable of supporting an SSH-style "leap of faith" authentication model or an anonymous model. In fact, this is pretty much exactly how it's used for SMTP over TLS. It seems to me that your issue is with the authentication model enforced by browsers in the HTTPS context, not with SSL proper. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > > b. we seem to be agreeing on 1% penetration of > > > the market, at least by server measurement (see > > > my other post where I upped that to 1.24% in the > > > most recent figures). > > This really depends on your definition of market. > > SSL was designed to protect credit card transactions, period. > > We do have the problem that SSL can be considered > to be a channel security product, or it can be > considered to be a credit card protection product. My view would be that SSL is a channel security product designed to be used with HTTPS, which is pretty clearly a credit card security product. But like I said, the people who designed it weren't very sophisticated about such things. I remember Marca or Jim saying that they just wanted to solve all security problems in one shot. There's also the issues of Kaufman's law, which is that if you design something useful people will use it for purposes other than what it was intended for and you'll be criticized for being shortsighted. And as I've said, Hickman wasn't very experienced. [Note to people who just came in: the people who designed what everyone thinks of as SSL, SSLv3, were relatively sophisticated, but the security model comes from SSLv1 and SSLv2, which were designed by amateurs.] > To rest any current requirements on credit cards > means that SSL should be oriented towards the > threat to credit cards, and it plainly isn't. See above. The Netscape philosophy was simplicity uber alles. If you look at SHTTP you can see that that's clearly not my philosophy. (Though if I were designing it today it would be simpler). > > I look at it this way: > > You don't PERSONALLY eat the cost of fraud on your own > > card but you eat the cost of fraud on other people's cards. > > Thus, as in many situations, it's in your interest for > > everyone else to practice good hygiene. > > Right. That might be a good argument if the issuers > of credit cards practiced good hygiene. But, in > practice, they don't. What they practice is risk > management. That is, they figure out what the fraud > rate is, and charge percentages and penalties according > to the sector. I don't think of hygiene as opposed to risk management. It's a risk management tool. > The other thing to be aware of is that ecommerce itself > is being stinted badly by the server and browser limits. > There's little doubt that because servers and browsers > made poorly contrived decisions on certificates, they > increased the overall risks to the net by reducing the > deployment, and probably reduced the revenue flow for > certificate providers by a factor of 2-5. I doubt that. Do you have any data to support this claim? > > Vis a vis SHTTP, I'm not sure if that was the right design > > or SSL was. However, they had relatively similar threat models. > > hmm. Are you saying that SHTTP didn't have a threat > model (one interpretation of your "Hickman" post) or > that SHTTP assumed the Internet Threat Model (ITM) > in the same way that SSL did? SHTTP assumed the Internet Threat Model. We did so explicitly (though not in the document) whereas Hickman kind of stumbled into it via a bunch of course corrections by more experienced people. SHTTP, however, had a more generalized usage model than SSL. Thus, SHTTP did one really important thing that SSL is still struggling with: it could protect passive content. Say you want to provide static content for download and provide security for it. If you use SSL and your server gets hacked you're SOL. If you use SHTTP, however, you can presign things and have your server immune to that attack by keeping the key offline. We were designing with more than credit cards in mind. Incidentally, when designing SHTTP we envisioned that credit transactions would be done with signatures. I would say that the Netscape guys were right in believing that confidentiality for the CC number was good enough. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 03:01 AM 9/7/2003 -0400, Ian Grigg wrote: Reputedly, chargeback rates and fees in the fringe industries - adult for example - can reach 50%. But, instead of denying those uses of the card - hygiene - issuers have encouraged it (...until recently. There is now a movement, over the last year, to withdraw service from the fringe industries, but, it is because of additional risks being added, not the risks of fraud or user loss. Visa is doing it, Mastercard is "waiting and seeing.") a webhosting company presented some numbers at some standards meeting that they handled ten websites (all with monthly hits higher than the number one in the published monthly "hit" rankings) ... five were adult-type downloads and five were various kinds of (non-adult) software downloads. The adult-type charge backs were comparable to mainstream brick&mortar upscale retail outlets while the mainstream software downloads was on the order of fifty percent. It seemed that the people that download software are much more "fringe" than the types that download adult material (i believe they threw in some snide comments about the character f people that download software). as I've mentioned before ipsec had been progressing very slowly in ietf for some time. in '94 ... you saw VPN being introduced at router working group (fall san jose meeting?) and introduction of SSL. both could be considered the domain of ipsec. Several of the router vendors didn't have processors capable of doing the crypto for VPN ... so you somewhat saw vaporware product announcements following the san jose meeting and VPN didn't make much progress until more router vendors had processors capable of handling the crypto load. the ipsec people seemed to evnetually come to terms with vpn by referring to it as lightweight ipsec (so the vpn people got to refer to ipsec as heavyweight ipsec). also in 94 you started to see SSL deployment basically a transport level ipsec feature implemented by applications (could be considered because ipsec was having such a hard time progressing). minor past refs: http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI? http://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec what i remember from the time was that SSL was thought as handling all of the shopping experience not just the credit card part but the feedback was that doing everything thru SSL cut the thruput capacity by about a factor of five (or you could handle five times as much traffic on the same hardware not using SSL).. The result was rather than using SSL for all commercial activity ... it was cut back to just handling the credit card part. Basically, SSL was being used for hiding the credit card number while in transit (over the internet). However, almost all the exploits have been from harvesting credit card files even when it would be possible to "sniff" non-encrypted credit card transmission. That issue is somewhat that you can be very targeted and quickly get possibly hundred thousand credit card numbers or you could put up a listening post and hope that you run across several a day (or maybe even an hour). SET came out after SSL ... and made extensive use of public key operations. I reported a public key operation performance profile for SET within a couple weeks after the original specification ... which several people working on SET claimed to be one hundred times too slow. It was probably just wishful thinking on their part since when they had some running prototype ... the profile was within a couple percent of measured. An issue was that SET was at least an order of magnitude more resource intensive than SSL ... and the only thing it did was protect credit card information in transit; basically it was only addressing the same (credit card) threat model as SSL but with significantly more overhead (having possibly hundred times more PKI didn't actually make things more secure). lots of past comments about what SSL does for credit card transactions: http://www.garlic.com/~lynn/subpubkey.html#sslcerts lots of recent comments in sci.crypt about eliminating certificates from SSL by collapsing the public key stuff into DNS: http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#44 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new) http://www.garlic.com/~lynn
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: > > b. we seem to be agreeing on 1% penetration of > > the market, at least by server measurement (see > > my other post where I upped that to 1.24% in the > > most recent figures). > This really depends on your definition of market. > SSL was designed to protect credit card transactions, period. We do have the problem that SSL can be considered to be a channel security product, or it can be considered to be a credit card protection product. Part of the problem lies in the switching of arguments from one purpose to another. If one criticises the credit card aspects, the answer is often that SSL is a channel security product. And v.v. The result is slippery, and it can only be done so many times before one gains the impression that SSL is snake oil and the real needs are elsewhere. We need to decide. If SSL is aimed at credit cards, and HTTPS is only present for credit cards, then why is it that OpenSSL spends so much time on it? What's their incentive? I'm not sure I understand why Eric and Tim and Ben and whoever does it these days spend huge amounts of unpaid time developing code so that other people could protect ... the credit card issuers' risks? And, isn't it about time we designed a new product to protect against the threats that users face today? One that could be used by the rest of us? I think it's fair to say that SSL was designed because of credit cards. But now, SSL/TLS is for the purpose of a channel security requirement. The credit card thing is a forgotten issue, SSL can be used to protect credit cards, but the protection of credit cards no longer has anything to do with the way SSL/TLS is designed, tested, measured or implemented. To rest any current requirements on credit cards means that SSL should be oriented towards the threat to credit cards, and it plainly isn't. That's easy to see, in that if SSL was oriented to credit cards, why did they do SET? (And, SHTTP seems much closer to that mission, on a quick reading, at least.) Having said all that, maybe we need to add to the list of "market success measures" a part on success at original target, and applicability for other missions? > For that, the market penetration is near 100%. (OK. My guess there would be well above 50%, probably around 90%, by servers, of those taking credit cards. I spent a little time googling, and found about 10% of credit card sites had open forms. I've also seen a fair amount of anecdotal evidence that suggests that any merchant who's less than 100k of revenue probably won't be worrying too much about secured delivery of credit cards. Probably in terms of number of transactions and total value dealt with, the coverage is right up there above 99%...) > > d. subjective good. For HTTPS, again, it's a > > decidedly mixed score card. When I go shopping > > at Amazon, it makes little difference to me, because > > the loss of info doesn't effect me as much as it > > might - $50 limit on liability. > That $50 limit is a funny thing. Yup! It is an extraordinarily interesting thing from an economics pov. It's a piece of market interventionism that pleases few, except the marketing folks that admire its beauty, or the economists who admire its subsidy. > I look at it this way: > You don't PERSONALLY eat the cost of fraud on your own > card but you eat the cost of fraud on other people's cards. > Thus, as in many situations, it's in your interest for > everyone else to practice good hygiene. Right. That might be a good argument if the issuers of credit cards practiced good hygiene. But, in practice, they don't. What they practice is risk management. That is, they figure out what the fraud rate is, and charge percentages and penalties according to the sector. The issuers - the people that the browser and server people are working so hard to protect - couldn't give a flying f**k if the user has breached hygiene. What they are concerned about is that the costs are covered by fees. And, perversely, a little known finance secret, the system works best if the fees are stabilised at a high level. See above, $50. Reputedly, chargeback rates and fees in the fringe industries - adult for example - can reach 50%. But, instead of denying those uses of the card - hygiene - issuers have encouraged it (...until recently. There is now a movement, over the last year, to withdraw service from the fringe industries, but, it is because of additional risks being added, not the risks of fraud or user loss. Visa is doing it, Mastercard is "waiting and seeing.") It's all well and good that users are encouraged to practice hygiene. But, users should practice risk management first. Hygiene second. In this case, the merchant - a user - should be allowed to calculate his risks. With HTTPS, he is denied that opportunity. (We all know where this is heading ...:-) The other thing to be aware of is that ecommerce itself is being stinted badly by the server and browser limits. Th
Re: Is cryptography where security took the wrong branch?
At 10:18 AM 9/3/03 PDT, D. K. Smetters wrote: > >I find WEP very useful for one thing -- given the habit of >many wireless clients to opportunistically jump onto any >network they happen to find, turning on WEP keeps users >from accidentally "falling" onto networks by mistake. This is much like the locks on cars. They are basically weak, but they prevent you from accidentally opening the wrong car, should an identical one be parked near yours. Sort of like the locks on residential bathrooms that can be opened with a paper clip. Trivially brute forced but useful nonetheless. Or the no-tresspassing signs on barbed wire fences, which are required by law, else the property is crossable. (This is, in my mind, the common-law basis for New Hampshire's "no password = freely usable" law legalizing wardriving.) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Arguments such as "we don't want to reduce the fraud level because it would cost more to reduce the fraud than the fraud costs" are just a marketing way to say that a fraud has become a sale. Because fraud is an hemorrhage that adds up, while efforts to fix it -- if done correctly -- are mostly an up front cost that is incurred only once. So, to accept fraud debits is to accept that there is also a credit that continuously compensates the debit. Which credit ultimately flows from the customer -- just like in car theft. Some 10 years ago I was officially discussing a national security system to hep prevent car theft. A lawyer representing a large car manufacturer told me that "a car stolen is a car sold" -- and that's why they did not have much incentive to reduce car theft. Having the car stolen was an "acceptable risk" for the consumer and a sure revenue for the manufacturer. In fact, a car stolen will need replacement that will be provided by insurance or by the customer working again to buy another car. While the stolen car continues to generate revenue for the manufacturer in service and parts. The "acceptable risk" concept is an euphemism for that business model that shifts the burden of fraud to the customer, and eventually penalizes us all with its costs. Today, IT security hears the same argument over and over again. For example, the dirty little secret of the credit card industry is that they are very happy with +10% of credit card fraud over the Internet. In fact, if they would reduce fraud to zero today, their revenue would decrease as well as their profits. There is really no incentive to reduce fraud. On the contrary, keeping the status quo is just fine. This is so mostly because of a slanted use of insurance. Up to a certain level, which is well within the operational boundaries, a fraudulent transaction does not go unpaid through VISA, American Express or Mastercard servers. The transaction is fully paid, with its insurance cost paid by the merchant and, ultimately, by the customer. Thus, the credit card industry has successfully turned fraud into a sale. This is the same attitude reported to me by that car manufacturer representative who said: "A car stolen is a car sold." The important lesson here is that whenever we see continued fraud, we must be certain: the defrauded is profiting from it. Because no company will accept a continued loss ithout doing anything to reduce it. What is to blame? Not only the shortsighted ethics behind this attitude but also that security "school of thought" which is based on risk, surveillance and insurance as "security tools". There is no consideration of what trust is or means, no consideration whether it is ethically justifiable. "A fraud is a sale" is the only outcome possible from using such methods. The solution is to consider the concept of trust(*) and provide means to induce trust among the dialogue parties, so that the protocol can be not only correct but also effective. The problem I see with the protocols such as 3D Secure (for example) is that it does not allow trust to be represented -- even though it allows authorization to be represented (**). Cheers, Ed Gerck (*) BTW, I often see comments that it is difficult to use the concept of trust. Indeed, and unless the concept of trust in communication systems is well- defined, it really does not make sense to apply it. The definition that I use is that "trust is that which is essential to a communication channel but cannot be transferred through that same channel." This definition allows one to use Shannon's communication theory formalism and define trust without any reference to emotions, feelings or other hard to define concepts. (**) Trust is often used as a synonym for authorization (see InterTrust usage, for example). This may work where a trusted user is a user authorized by management to use some resources. But it does not work across trust boundaries. Trust is more than authorization. Ian Grigg wrote: > > This is mostly prevalent on the > Internet, where there is a sense of self-taught, non- > commercial application of cryptography. My time in (or > close to) a telco taught me the difference, as there, > they have an engineering focus on cryptography, and really > understand what it means to calculate the cost of the > solution. > > For them, leaving a weakness was just another risk > calculation, whereas so much stuff that happens on the > net starts from "we must protect against everything" > and then proceeds to design the set of "everything" > for ones convenience. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
> Eric Rescorla wrote: Ian Grigg <[EMAIL PROTECTED]> writes: I'm almost convinced that WEP is a failure, but I think it retains some residual value. I agree. After all, I occasionally come upon a network I'd like to use and WEP stops me cause I'm too lazy. On the other hand, MAC restrictions would have done just as well for that. I find WEP very useful for one thing -- given the habit of many wireless clients to opportunistically jump onto any network they happen to find, turning on WEP keeps users from accidentally "falling" onto networks by mistake. This saves a lot of confusion if you have the occaisional research network with say, different firewalling properties than a user might expect, or one that doesn't actually route to the outside world. And it's easier to manage than MAC filtering. --d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
In message <[EMAIL PROTECTED]>, Ian Grigg <[EMAIL PROTECTED]> wrote: > One thing that has been on my mind lately is how > to define success of a crypto protocol. There are two needs a security protocol can address. One is the need to prevent or mitigate real attacks; the other is to make people feel less afraid. HTTPS might or might not have addressed a major problem, but it did address a major fear. Many people -- not only consumers, but also merchants, issuing banks, and processing companies -- were concerned about using credit card numbers on the Internet in 1995, when there was no viable way to buy anything online. Netscape designed an effective protocol, deployed it widely, and made it visible to end-users. It offered a credible promise that you could trust your session without trusting the network, and that's what made people willing to do large-scale online commerce and banking. This is not to be underestimated. At the same time, Netscape put visible crypto into the hands of people who had never used crypto before, and in many cases had never even owned a computer before. This did a great deal to counter the rhetoric about encryption being a tool for drug dealers and child pornographers. The physical security industry has known for a long time that if you want something deployed, you shouldn't be looking at what problems are interesting or even at what problems people actually have. You should be looking at what makes people afraid. Fear drives deployment. -- Shields. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 10:09 PM 9/2/2003 +, Michael Shields wrote: I would agree that HTTPS has been more successful than WEP, in the sense of providing defense against real threats. HTTPS actually defends against some real attacks, providing an effective answer to a clearly defined problem: preventing the exposure of sensitive information such as credit card numbers, even in the face of eavesdropping and server impersonation. This is only one threat model and maybe not the most realistic one, but HTTPS does define it and address it. Meanwhile, WEP is too weak to prevent any attacks; and even if it were not cryptographically weak, its stone-age key management would make it a poor tool for any network with more than a handful of users. My view was that ipsec had been in progress for some time and not making a whole lot of headway. At the San Jose IETF meeting (fall '94?), VPN was introduced in a router/gateway working group. This caused quite a bit of consternation among the router vendors that didn't have processing to implement the required cryptography operations (and you saw some vaporware product announcements following the meeting). It also caused some consternation among the ipsec group. Eventually most of the router vendors upgraded to processors that could handle the VPN requirements and it started to make some deployment progress. The ipsec group somewhat came to terms by referring to VPN as lightweight ipsec (and the vpn group referring to ipsec as heavyweight security). HTTPS came out about the same period. It basically is a transport layer protocol implemented in the application layer again ipsec implementation and distribution at the operating system level was not making a lot of progress ... and so a vendor could build HTTPS into their product and distribute it w/o having to worry about dependencies on other vendor components. There is some postings in sci.crypt that while you see pervasive distribution of HTTPS support ... supposedly the percentage of web sites that actually offer up HTTPS (and SSL domain name server certificates) is around the one percent range. -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > I think it's pretty > > inarguable that SSL is a big success. > > One thing that has been on my mind lately is how > to define success of a crypto protocol. I.e., > how to take your thoughts, and my thoughts, which > differ, and bring the two together. > > There appear to be a number of metrics that have > been suggested: > >a. nunber of design "wins" >b. penetration into equivalent unprotected >market >c. number of actual attacks defeated >d. subjective good at the application level >e. worthless measures such as deployed copies, >amount of traffic protected > > All of these have their weaknesses, of course. > It may be that a composite measure is required > to define success. I'm sure there are more > measures. > > a. The only thing that seems to be clearly a win > for SSL is the number of design wins - quite > high. That is, it would appear that when someone > is doing a new channel security application, the > starting point is to consider SSL. > > b. we seem to be agreeing on 1% penetration of > the market, at least by server measurement (see > my other post where I upped that to 1.24% in the > most recent figures). This really depends on your definition of market. SSL was designed to protect credit card transactions, period. For that, the market penetration is near 100%. > d. subjective good. For HTTPS, again, it's a > decidedly mixed score card. When I go shopping > at Amazon, it makes little difference to me, because > the loss of info doesn't effect me as much as it > might - $50 limit on liability. That $50 limit is a funny thing. I look at it this way: You don't PERSONALLY eat the cost of fraud on your own card but you eat the cost of fraud on other people's cards. Thus, as in many situations, it's in your interest for everyone else to practice good hygiene. In this particular case, the issuers were *very* wary of providing credit card transactions over the Internet without some sort of encryption. So, SSL is what enables you to do e-commerce on the net. That seems like a large subjective good. > > Actually, I think that SSL has the right model for the application > > it's intended for. SSH has the right model for the application it > > was intended for. Horses for courses. > > Plenty of room for future discussion then :-) > > (I sense your pain though - I see from the SHTTP > experiences, you've been through the mill. Vis a vis SHTTP, I'm not sure if that was the right design or SSL was. However, they had relatively similar threat models. > I'm almost convinced that WEP is a failure, but > I think it retains some residual value. I agree. After all, I occasionally come upon a network I'd like to use and WEP stops me cause I'm too lazy. On the other hand, MAC restrictions would have done just as well for that. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg <[EMAIL PROTECTED]> writes: >There appear to be a number of metrics that have been suggested: > > a. nunber of design "wins" > b. penetration into equivalent unprotected market > c. number of actual attacks defeated > d. subjective good at the application level > e. worthless measures such as deployed copies, amount of traffic > protected You forgot the most important one: f. value added elsewhere SSL's real strength is that it's convinced 100 million Joe Sixpacks that it's safe to make purchases online. This has nothing to do with security (you could do the same with padlock GIFs stuck on your web page), but does count as some sort of measure of "success", although it's marketing success rather than security success. Although they provide about the same level of real security, it seems that SSH is the tool of choice for people who care about providing real security while SSL is the tool of choice for people who care about providing their customers warm fuzzies. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Eric Rescorla wrote: > > Ian Grigg <[EMAIL PROTECTED]> writes: > > That's a scary talk! I see a lot of familiar > > stuff, but it seems that whilst Eric courts the > > dark side of real security, he holds back from > > really letting go and getting stuck into SSL. > > > > For example, he states that 28% of wireless > > networks use WEP, and 1% of web servers use SSL, > > but doesn't explain why SSL is a "success" and > > WEP is a "failure" :-) > > I was very clear about this in my talk. A good point - commenting on slides is fraught with danger, as others have pointed out. Is there to be a paper? [further WEP comments at end...] > I think it's pretty > inarguable that SSL is a big success. One thing that has been on my mind lately is how to define success of a crypto protocol. I.e., how to take your thoughts, and my thoughts, which differ, and bring the two together. There appear to be a number of metrics that have been suggested: a. nunber of design "wins" b. penetration into equivalent unprotected market c. number of actual attacks defeated d. subjective good at the application level e. worthless measures such as deployed copies, amount of traffic protected All of these have their weaknesses, of course. It may be that a composite measure is required to define success. I'm sure there are more measures. a. The only thing that seems to be clearly a win for SSL is the number of design wins - quite high. That is, it would appear that when someone is doing a new channel security application, the starting point is to consider SSL. b. we seem to be agreeing on 1% penetration of the market, at least by server measurement (see my other post where I upped that to 1.24% in the most recent figures). That's not going to support any notion of "big success." (Note here Michael Shields' comments on HTTPS (in)convenience.) c. number of attacks defeated. When correctly deployed, SSL seems to defeat all known active and passive attacks. Problem is, at least for HTTPS, there are practically no active attacks. And passive attacks are not very common. We know this because credit cards get stolen in their millions. But in all cases, known, they get stolen by hacking. I still believe there has never been a case of a credit card number being eavesdropped off an open transmission (and delivering CCs over open forms & email does go on!). So, it's not clear that SSL achieves much with c. either - for HTTPS. For other applications, one would need to look at those specific cases. d. subjective good. For HTTPS, again, it's a decidedly mixed score card. When I go shopping at Amazon, it makes little difference to me, because the loss of info doesn't effect me as much as it might - $50 limit on liability. Same with the merchant - what he's worried about is identity, but SSL's only contribution to identity - client certs - is a failure. More on this another day, the basic issue is that the threat model is wrong, I think. In sum, I think it highly arguable that SSL is a huge success. Highly arguable, and in terms of any positive objective measure as to where one can show SSL's success, I'm interested to see what that is, from both the particular SSL case, and the general crypto case. > Actually, I think that SSL has the right model for the application > it's intended for. SSH has the right model for the application it > was intended for. Horses for courses. Plenty of room for future discussion then :-) (I sense your pain though - I see from the SHTTP experiences, you've been through the mill. And written the book! I also share the pain, as all this fine work by many people has delivered what amounts to very little. Our comms, our browsing, our net, remains fundamentally unprotected.) iang PS: in the interests of brevity, I stuck my reponse on the WEP issue here, where it can be skipped more readily... > WEP is a failure because any even vaguely serious attacker can break > it in minutes. Therefore, the amount of value it adds over simple MAC > checking is quite small. If WEP had been competently done (IE used RC4 > correctly) it would be a smashing success. I admit I was thinking it was an active attack, but in fact a passive attack is sufficient. This makes the attack by far easier. "AirSnort requires approximately 5-10 million encrypted packets to be gathered. Once enough packets have been gathered, AirSnort can guess the encryption password in under a second." http://airsnort.shmoo.com/ On a busy network, maybe many minutes of listening. On a mostly idle network, many hours. It seems to reduce WEP to a complicated method of access control. I'm almost convinced that WEP is a failure, but I think it retains some residual value. What matters is how much this slows down the attackers. Not the theoretical one (with his copy of WepCrack or AirSnort) but the real people out in the street. For a start, just the mere knowledge that you ha
Re: Is cryptography where security took the wrong branch?
In message <[EMAIL PROTECTED]>, Ian Grigg <[EMAIL PROTECTED]> wrote: > For example, he states that 28% of wireless > networks use WEP, and 1% of web servers use SSL, > but doesn't explain why SSL is a "success" and > WEP is a "failure" :-) Actually, he does; slide 11 is titled "Why has SSL succeeded?", and slide 23 is titled "The WEP Debacle". Also, although speakers often do nothing more than read what's on the screen, a talk does ideally involve more content than is on the slides. I would agree that HTTPS has been more successful than WEP, in the sense of providing defense against real threats. HTTPS actually defends against some real attacks, providing an effective answer to a clearly defined problem: preventing the exposure of sensitive information such as credit card numbers, even in the face of eavesdropping and server impersonation. This is only one threat model and maybe not the most realistic one, but HTTPS does define it and address it. Meanwhile, WEP is too weak to prevent any attacks; and even if it were not cryptographically weak, its stone-age key management would make it a poor tool for any network with more than a handful of users. A very relevant question is why WEP has been so much more widely deployed than HTTPS. Eric Rescorla is correct that people choose whether to use security measures or not based mostly on how convenient they are, not on how much they need them. In this sense, HTTPS is a failure; although it is effective, it is so difficult to use that almost no one bothers unless credit card numbers are involved. Security needs to be easy, or people will just put up with losses instead. > One thing he doesn't stress is design by committee > v. design by small focused team. Much of SSL and > SSH's strengths are that they were designed and > deployed quickly and cheaply (and insecurely!) so > as to tap into real needs real quickly. I would > suggest that any security protocol designed by a > committee has a low survivability rating. In fact, early versions of both SSL and SSH had extensive flaws; it took many people to evolve them into their present states. *All* security protocols have low survivability ratings. Inventing a new protocol is extremely hazardous. -- Shields. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Is cryptography where security took the wrong branch?
Hadmut Danisch wrote: > The reason I was asking is: I had a dispute with someone who > claimed that cryptography is by far the most important discipline > of information and communication security, and that its transition > from an art to a science was triggered by Shannon's paper in 1949 > and the Diffie/Hellman paper in 1976 (discovery of public key > systems). It depends on what the context is. If we are talking about "military security" then commsec is of some use, as things like tactical security don't really "need" the benefit of hard crypto, it's just a nice-to-have. E.g., the presence of a radio signal is generally most of the short term importance of tactical comms. The rest of it tends to be chit-chat which is hard to analyse in real time anyway... In this sense, commsec means radio silence more than anything else. If we are talking about "government security" then it is of high use, because pretty much everything about government is about talking and documents, and the time aspect of tactical comms is not present. Within the academic notion of infosec & commsec, it would be fair to say that it's the most important, but that's by absence, really. There's isn't much else to study if one is confined to academic research into the security of data! > Reality is different: While Firewalls, Content Filters (Virus/Spam/ > Porn filters), IDS, High availability systems, etc. become more and > more important, encryption and signatures, especially based on PKIs, > don't seem to get more relevant (except for HTTPS/TLS). If we are talking about Internet security, then by far the biggest problems are viruses, hacked hosts, identity theft and DOS. Snooping is next to non-existant but has a reputation for being rampant. Active attacks on comms - MITM, etc - are basically a theoretical issue only, but are seen by many theoreticians as "must-protects". This discord is seen by the fact that a real snooping event or, heaven forbid, an active MITM, is a newsworthy event, whereas the real threats - hacked credit card databases - are somewhere between boring and embarressing. (I'm waiting with interest to see if there is much report of WEP kits being used out in the world for aggressive entries.) So, part of the problem is that cryptography people have been concentrating on the wrong things (wrong threat model) for so long that they have earnt a reputation of being "mostly harmless." > There was an interesting speech held on the Usenix conference > by Eric Rescorla (http://www.rtfm.com/TooSecure-usenix.pdf, > unfortunately I did not have the time to visit the conference) > about cryptographic (real world) protocols and why they failed > to improve security. That's a scary talk! I see a lot of familiar stuff, but it seems that whilst Eric courts the dark side of real security, he holds back from really letting go and getting stuck into SSL. For example, he states that 28% of wireless networks use WEP, and 1% of web servers use SSL, but doesn't explain why SSL is a "success" and WEP is a "failure" :-) On the plus side, he balances the conventional (SSL is the model) with the new view (SSH is the model) quite well. It's good news that the SSH model is starting to receive some respect. The analysis of threat model failure is good. One thing he doesn't stress is design by committee v. design by small focused team. Much of SSL and SSH's strengths are that they were designed and deployed quickly and cheaply (and insecurely!) so as to tap into real needs real quickly. I would suggest that any security protocol designed by a committee has a low survivability rating. ( Hmm, I wonder who designed WEP? :-) > From the logfiles I've visited I'd estimate > that more than 97% of SMTP relays do not use TLS at all, not > even the oportunistic mode without PKI. Right. But, doing TLS over SMTP relays seems a complete waste of time. Basically doing node-to- node encryption for an end-to-end protocol isn't attractive, neither at the protocol level nor at the administrator level. [Ref: Eric's book.] > I actually know many companies who can live pretty well and secure > without cryptography, but not without a firewall and content filters. > But many people still insist on the claim that cryptography is by far > the most important and only scientific form of network security. Yep. It's just not fun to admit that being hidden in the crowd is a valid form of security. Or, controlling the guest list is solves most of the trouble at parties. > > Is cryptography where security took the wrong branch? > A large part of the problem, IMHO, is that cryptography in the popular domain is treated as a discipline of science and not of engineering. This is mostly prevalent o
