Is cryptography where security took the wrong branch?

[Ian Grigg]

Eric Rescorla wrote:
> 
> Ian Grigg <iang at systemics.com> 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 majordomo at metzdowd.com