Is cryptography where security took the wrong branch?

[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 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/2003l.html#46 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#50 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#51 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#52 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#54 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#55 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#57 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At 
least I hope it's new)
--
Anne & Lynn Wheeler    http://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 majordomo at metzdowd.com