[Cryptography] [cryptography] Is it time for a revolution to replace TLS?

[Anne & Lynn Wheeler]

On 05/19/14 08:01, John Kemp wrote:
> Heh :) Thanks to Lynn's history lesson, I am reminded of the days when "micropayments" were last going to revolutionize commerce (on the web).
>
> And along came SSL, combined with the lowering of transaction fees by the credit cartel...

SSL was 94/95 ... and banking industry applied MOTO rates to internet transactions.

96/97 the banking industry was afraid that the telco industry would take over
the payment industry. the payment fees were contributing nearly half banking
bottom line and were heavily prorated based on possibility of fraud in transactions.

micropayment had prospect of enormous increase in transactions ... totally
swamping the existing payment backends. the only platforms that could possibly
handle the transaction rates were backends for telco developed for handling
callrecords (still ACID properties leveraging new "in-core" DBMS technologies).

telcos figured they could combine micropayment and callrecord charges in the
same statement.

banks were afraid that once the telcos had the micropayment market, they would
leverage it to move upstream and take over the rest of the payment industry ...
using technology to be substantially more cost effective than banks.

the micropayment volumes never quite emerged and the telcos stumbled not
being very diligent managing non-payment of statements. when statements
were purely callrecords ... it wasn't actually out-of-pocket expense,
basic use of infrastructure already there. With payments, the telcos
had already transferred the money to the merchant/recipients and needed
to recover that money from their customers. Within a couple years,
all the telcos that had made big move into payments had all backed out.

Even at that, the bank industry was still afraid of new entries into
banking that could be much more efficient and competitive. At about
1:03:30 I'm starting to blather that rhetoric on floor of congress
about the primary purpose of GLBA was to keep new competitors out
of the banking industry (specifically referring to new technology
and corporations like microsoft).
http://www.isoc-dc.org/2014/05/confidentiality-2020-can-we-keep-secrets-any-more/

GLBA now better known for repeal of Glass-Steagall (enabling "too big to fail").

cal. state was working on legislation for electronic signature, data
breach notification, and op-in personal data sharing. cal. managed to
get data breach notification before preemption by congress ... but
bank industry managed to get "opt-out" added to GLBA and passed
preempting cal. state "opt-in"
  
The card associates in that time-frame did define SET specification
with enormous amounts of crypto and digital certificates. When it
was 1st published, I did crypto-opt profile and had friend benchmark
with BSAFE library on several platforms ... and provided the information
back to the SET group (that included several vendors). The response
was the numbers were 100 times too slow. They obviously hadn't
ever done any real live operations since this was an improved BSAFE
library that was four times faster than the regular libray. Six
months later, initial SET prototype was very close to the profile
benchmark numbers.

The other issue was that it required appending digital certificates
to every normal payment transaction (besides encrypting the content
of the transaction). The only problem was that the typical digital
certificate payload sizes were 100 times larger than a normal
payment transaction payload size (and I was already constantly
pointing out that they were superfluous and redundant ... but
they also resulted in payload bloat of factor of 100 times).

Somewhat as a result, the CA industry got a work item in the
financial industry standards body to do compressed digital
certificates ... possibly down to only ten times payload
bloat (rather than 100 times payload bloat) ... still ignoring
that the digital certificates were redundant and superfluous.
However, I demonstrated using some of their proposed techniques,
compression of digital certificates to zero bytes. Rather than
eliminating redundant and superfluous digital certificates,
the industry could managed zero byte digital certificates appended
to every payment transaction.