Is cryptography where security took the wrong branch?

[Ian Grigg]

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.
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.

As if anyone cares about that ;)


> 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.

Right.  They had this fallacious threat model.  And
what solved it - in their minds - was the application
of some crypto.  SSL as a placebo.  I grant, that may
well be the crowning reason for SSL's success.

(One can see this
when one considers the case for 40 bit crypto.  That
would have done perfectly for protecting credit cards.
But, because of the absence of a threat model, there
was also absence of requirements.  So 40 bits, instead
of being entirely adequate to protect credit cards,
became entirely inadequate.)

Fair enough, as long as we understand their motives
at the time.

That all was nearly 10 years ago.  (I'm not sure I as
an individual would have been able to see the full
story then.  It's important to realise that the net
was younger then, and the full impact of the commercial
steamroller was only imagined at by most of us.)

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.


> > > 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.

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?

> > 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.

That seems to be close to the truth of it.  About
the only thing that is stopping one from cracking
WEP other than laziness is the fact that one is
knowingly and deliberately breaking into a network
(no matter how weakly secured).  YMMV as to what
sort of an impediment that is, I don't think it is
much to write home about on a crypto scale.


iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com