Re: Is cryptography where security took the wrong branch?

2003-09-10 Thread Anne Lynn Wheeler
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?

2003-09-10 Thread bmanning
 
 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?

2003-09-09 Thread Anne Lynn Wheeler
. 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?

2003-09-09 Thread Anne Lynn Wheeler
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?

2003-09-09 Thread Anne Lynn Wheeler
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?

2003-09-08 Thread Ben Laurie
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?

2003-09-08 Thread Joseph Ashwood
- 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?

2003-09-07 Thread Anne Lynn Wheeler
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 brickmortar 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)

Re: Is cryptography where security took the wrong branch?

2003-09-07 Thread Ben Laurie
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?

2003-09-07 Thread Ian Grigg
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?

2003-09-07 Thread Ian Grigg
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 anything to reduce it.

It'e perverse, because as you say, the 

Re: Is cryptography where security took the wrong branch?

2003-09-07 Thread Eric Rescorla
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?

2003-09-07 Thread Eric Rescorla
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?

2003-09-07 Thread Anne Lynn Wheeler
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?

2003-09-07 Thread Anne Lynn Wheeler
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?

2003-09-07 Thread Bill Stewart
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?

2003-09-07 Thread Ian Grigg
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?

2003-09-07 Thread James A. Donald
--
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?

2003-09-04 Thread Ed Gerck

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?

2003-09-03 Thread Michael Shields
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]


Re: Is cryptography where security took the wrong branch?

2003-09-03 Thread Peter Gutmann
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?

2003-09-03 Thread Eric Rescorla
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?

2003-09-03 Thread Michael Shields
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]