digital signature enhanced radius (for ISP access authentication, i.e. replacing
the password with public key in the authentication database and replacing the
password with digital signature on authentication transactions) and in-coming
address spoof filtering at ISPs (similar to intranet address spoof filtering for
packets coming in from the internet, the ISPs would do address spoof filtering
on packets coming into the internet from their customers) would go a long way
for addressing a lot attacks (w/o requiring PKI).
then for things like denial-of-service attacks (w/o address spoofing) ...
account-based infrastructures would still use account-based public key
transactions. In the case of boundary pre-filtering for things like
denial-of-service attacks ... there is still trade-off with ASN.1 decoding &
public key ops that are still computationally intensive ... & can be greater
than TPC-C (for most of the current e-commerce transactions there would still
have account-based authentication processing ... boundary pre-filtering
represents duplication of effort & could lead to faster resource exhaustion).
It is likely then that a lot of the non-addresses-spoofed attacks would be from
compromised machines (given ISP authentication & incoming packet address spoof
filtering by ISPs).
Part of the issue is that almost all current e-commerce is transactional
account-based paradigm (because of requirements for information timeleness
and/or information aggregation). Part of the PKI design point/advantage is
targeted to peer-to-peer, anarchy, offline, lacking any account infrastructures.
Work on compromised machine exploits still has quite of bit of work to do and
PKI might play in program execution authentication ... say next generation of
virus checkers also check for valid program/executable digital signatures. Even
then there is a design trade-off between having the visus checker include a
(account) table of acceptable public-keys vis-a-vis each program having an
appended certificate in addition to the digital signature ... and the virus
checker only having a table of CA public keys. Does the user want to pass
approval on only the list of trusted CAs or does the user want to pass approval
on each individual developer's public key?
Once the user decides not to trust the CA as to whether programs from individual
vendors are to be accepted ... then the user creates their own table of
acceptable public keys (not relying on the CA/PKI trust infrastructure).
bram <[EMAIL PROTECTED]> on 01/11/2000 10:41:32 AM
To: Lynn Wheeler/CA/FDMS/FDC@FDC
cc: Peter Cassidy <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Killer PKI Applications
The first thing something needs to be a killer application is to be an
application. The problem with PKI is that it isn't an application, it's a
system. A killer app needs to have a very specific purpose, and needs a
very immediate motivating factor for it's use. Think web browser.
I'm more than a little bit skeptical that the world has much use for PKI
just yet. PKI is useful for stopping active attacks, but right now almost
everything on the internet is subject to passive attacks. Fix the first
problem first, only then will it become clear how to solve the second
problem.
-Bram
