From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: .plan as verification?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sun, 27 Sep 1992 16:58:08 GMT

In article <1992Sep27.073429.5833@muddcs.claremont.edu>, ebrandt@jarthur.claremont.edu (Eli Brandt) writes:
> In article <1992Sep26.165606.1@hamp.hampshire.edu> jyanowitz@hamp.hampshire.edu writes:
> >  Given the all the reasonable hullabaloo about verifying keys, what do
> >people think about, in the interim, placing copies of our keys in our
> >.plan (on unix and vms) so when people finger you, they can see a copy
> >of it.  Obviously, two flaws with this method are:
> >a) someone could create a fake account...
> >b) someone could intercept the finger requests.
> 
> This is what I was planning to do... (as soon as I check over my
> PGP).  It would be possible, I suppose, to install high-speed
> search-and-replace hardware on all routers.  As I don't know what
> the backbone connectivity is like, I don't know how feasible this is.
> Probably expensive, though I'm sure the NSA would give its eyeteeth
> for that kinda setup...


An "application gateway" for ports 119, 79 and 25 at only one or two
routers near you would probably be sufficient to destroy the use of
.plan for any particular site.  Most people do not have much redundancy
in how they get to the rest of the Internet.  As I understand it, most
people have a single link to one nearby NSS.  Some of us also have
links via a CIX or other exchanger.  Consider the small administrative
leverage (i.e. court order, bribe, threat from government agent) needed
to install such code at an NSS or even at the CIX.  Or even at Uunet or
PSI.

If you want to be paranoid, stop and think of reasons other than
incompetance for the infamous slowness of the NSS's.  Maybe IBM &Co.
are not so dumb after all.  Maybe those rings are slow because they are
already filtering and tracing traffic.  (Personally, I think Occam's
razor applies, and that such a conspiracy would require implausible
intelligence and foresight from bureaucrats.)

It is a standard drill to filter packets in routers based on address
and port number.  It is not at all hard to do a little re-writing for
slow, low volume, low speed stuff like SMTP, NNTP, and finger.  (Yes,
30-60MByte/day is "low volume".)  Such a filtering TCP/IP router is
standard, and for news, mail or finger, easy.  It is the start of an
Internet "firewall."  It is the beginning of the machinery used to
convert between X.400 and SMTP or FTP and FTAM, etc.

The obvious way would be to pass finger requests, and then capture and
not forward finger response until a human had a chance to produce a
useful replacement.  Who would notice transient finger failures?  A
smart agency would continually finger hosts looking for .plan's with
keys to be prepared for the first real customer.  For that matter, bad
guys who care could easily spend the $100k/year to have humans watching
for finger requests, to make the fix in real time.  How many would
notice if `finger joe@foo.edu` took 30 seconds instead of 5 seconds?


Still and all, this entire argument is irrelevant.  The difficulty with
PGP is not cryptographic security, but simple software logistics.  How
many people have mail user agents that can comfortably handle encrypted
traffic?  Do many of your correspondents?

Until most mail user agents can do not just MIME, but also encrypted
text, until you don't have to ask your correspondent in the clear about
their crypto facilities, this worry about cryptographic security is
largely academic.


Vernon Schryver,  vjs@sgi.com
Xref: sparky alt.security.pgp:51 sci.crypt:3529