Is cryptography where security took the wrong branch?

[Eric Rescorla]

Ian Grigg <iang at systemics.com> 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                                   ekr at rtfm.com]
                http://www.rtfm.com/

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