DNSSEC to be strangled at birth.

[Anne & Lynn Wheeler]

Dave Korn wrote:
> We already had this with PKI and SSL, and it basically failed.
> Works fine on a small scale in a tightly-disciplined organisation;
> fails totally to scale to Joe Internet-User.

one could claim that PKI failed ... especially in its trusted 3rd
party scenario ...  since it was an amazingly complex and expensive
deployment to solve a rapidly vanishing problem.

the basic design point is the electronic analog for physical
credentials, certificates, licenses used in the "offline" world ... or
the electronic analog of letters of credit/introduction from the
sailing ship days (and before) ... the trusted distribution of
information for the benefit of relying parties that had no other
recourse for the information.

in an online world ... a paradigm designed for trusted distribution of
information for an offline world, rapidly becomes redundant,
superfluous and obsolete (besides enormously NOT cost effective).

SSL was intended as countermeasures to two vulnerabilities 1) are you
really talking to the server that you think you are talking to (among
other things ip-address hijacking) and 2) evesdropping of information
in transit.

The SSL solution to #1 was predicated on the end-user having knowledge
of a trusted binding between the server he thought he was talking to
and the URL for that server.  The SSL protocol then provided the
trusted binding between the URL and the server the user was actually
talking to. That weak-link in all of this was current infrastructure
where end-users frequently have very little knowledge of the binding
between the server they think they are talking to and the URL for that
server.

It isn't so much that SSL has failed to do what it was implemented to
do, it is that SSL failed to take into account that part where
end-users have very little knowledge of the relationship between
servers and the URLs for those servers. It isn't so much a small-scale
population that it works for ... it requires a (disciplined)
population that maintains adequate knowledge of the relationship
between servers and the URL for those servers. Even a well disciplined
population is likely only to maintain knowledge of strong binding
between servers and URLs ... for only a small number of servers and
their corresponding URLs. The same population may be also be
vulnerable when dealing with URLs and servers outside some well
regulated domain.

these series of posts talk about eliminating PKI and digital
certificates for SSL ... and going to real-time public key operations
in the domain name infrastructure ... as countermeasure to ip-address
hijacking (original SSL) as well as domain name hijacking (as well as
providing mechanism for encrypting information while in transit).
http://www.garlic.com/~lynn/subpubkey.html#catch22

Aka the current domain name certification authority PKI-based paradigm
has its root trust in the validity of the information at the domain
name infrastructure. While the existing SSL/PKI related implementation
was targeted at ip-address take-over ... it still remained vulnerable
to domain name hijacking.

however, the real-time domain name public keys, still doesn't address
the vulnerability of end-users typically not having knowledge of
strong binding between the website they think they are talking to and
the corresponding URL (making them vulnerable to website impersonation
and social engineering attacks that get them to click on arbitrary
URLs).

Solutions for these vulnerabilities ... typically involve some amount
of additional trust operations by the users ... along the lines
of local repository of trusted public keys with the corresponding
trusted binding to trusted URLs (which starts to look somewhat
like the PGP email public key repository). One of the issues for
such solutions is that they lack the economic incentive for
large scale deployment (i.e. there is no 3rd party taking in
money selling digital certificates).


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