[net.news.stargate] how to verify an article's submitter

parks@noao.UUCP (Jay Parks) (02/11/85)

A significant problem with accountability and liability of Usenet
submissions is that the author of an article may be impossible to
trace, or conversely, easy to trace but it may be impossible to prove
that he was actually responsible.  This is a suggestion on how to
solve this problem.

     Public-key cryptography.  First off, I am not a cryptographer, and 
as far as I know there are no REALLY secure public-key systems.  We
are not dealing with military or top-flight financial information though, 
so as long as the public key system is as secure as a personal signature 
or driver's license (both of which can be faked), it should be sufficient 
for our needs.

     Another problem would be the need for a general directory of all
stargate submitters, with their names, addresses, and submission site
included.  Some people will probably view this with paranoia, but
these requirements are really no worse than those required to send a
letter to the editor of a major newspaper.  Also, it should be possible
to remove your identity from a posting (although the moderator would
still know -- more on this in a minute).

     As I picture it, the system would work like this:

     When a new poster wished to obtain stargate privileges, he would
select a public and private key.  He would write an electronic
document stating:  His real name, his address, his usenet name (or
nickname), his site.  He would then encrypt this with his private key,
and go to his system administrator.  The administrator would take the
encrypted file, check it (to make sure it could be decrypted with the
public key), then encrypt it with HIS private key.  He would then make
a hard copy of this double-encrypted page, and both people would
(physically) sign it, and send it to a special stargate moderator.
They would also electronically send the double-encrypted file.

     The stargate moderator to receive this would be the moderator of
a special group called NET.DIRECTORY.  He would receive the hard and
electronic affadavits, and file both.  Then, he would update his
listing of a regular posting called DIRECTORY, which would contain the
usenet nickname, the public key, and other information if desired.  He
would retain reliable proof that anything which could be decrypted
with that person's public key, was actually sent by them.

     All of this would be used by moderators and submitters only.  It
should not be noticeable to readers.

     To send an article, the submitter would use the following steps:
He would write his article using a regular editor.  When he had is
properly spelled and edited to his satisfaction, he would send the
file through a routine called PUB-CRYPT, and save the new file.  He
would then use the POSTNEWS (or MAIL, or whatever) and prepare to 
send the article to the moderator of the desired stargate groups.  
Whatever method is finally decided to send these articles to their
moderators (an 800 number, regular mail, or some other means), the
moderator would eventually receive a regular header and encrypted
text.  Looking through his directory file, he would use the site and
poster name to decrypt the file, thus verifying the poster.  If
necessary, he could strip site and name information from the posting
(The equivalent of "name withheld by request".  The newspapers that do
this still keep the original, with its name and address, they just
don't PUBLISH this information.).  The moderator then takes this final
article and posts it directly to stargate.

     I have, perhaps, gone into too much detail here.  The method
provides the following advantages:

---  It is at least as secure as regular means of identification
(driver's license, social security number, signature).

---  It can be easily added to all existing software by the simple
addition of a program called PUB-CRYPT, which would do public key
cryptography.  No new news software needs to be created (although the
overworked moderators would doubtlessly begin to want some).

---  It could be easily expanded to handle people who are not standard
unix users, who wish to join the system:  People with personal
computers who wish to submit directly to moderators, non-unix
academic machines who eventually link up to stargate, etc.  This
should be considered if Usenet continues to grow.

---  It can provide security, while hiding the identity of the poster
(except to the moderator), if we wish to.  Actually, this feature is
considered just to forestall arguments by those who will be afraid of
the abuses of the system.  All you need is ONE trustworthy moderator
to make the system work (he can strip off the encryption and
identification).

---  We can increase security, and protect submitters better by making 
the group NET.DIRECTORY only available to moderators.  I suppose this
would make the system a semi-public key.  

                           submitted for your approval,
                                     Jay Parks

             (decvax!hao!ihnp4!seismo)!noao!parks  :uucp
             Kitt Peak National Observatory        :U.S. Snail
             950 N. Cherry, Tucson, AZ  85726

lauren@vortex.UUCP (Lauren Weinstein) (02/13/85)

I have assumed that some variation on a public-key system would
be useful to help assure authentication.  However, it should be
noted that the validity of these in case of litigation is 
very unclear.  In other words, I know of no court decisions that
have stated that such systems are acceptable (to the courts)
as a means of identification.  Perhaps part of the problem is the
lack of formal verification of the security of these systems
to date.

On the other hand, such encryption may not be necessary given
other authentication constraints, such as signed documents
and (possibly) assigned logins/passwords on some central submission
machine.  These are obviously only possibilities.

Of course, none of this addresses the resource allocation, content,
and perceived information value questions, which are probably at least
as important (to the overall usefulness and success of a service)
as the nitty-gritty authentication aspects under certain scenarios.

--Lauren--

spaf@gatech.UUCP (Gene Spafford) (02/14/85)

Jay presents a very nice solution to the verfication problem except for
a few problems -- one of which makes it unworkable.

Let's suppose for a moment that we do have a large enough, unique
enough key space.  Let us further suppose we have the appropriate
software to encrypt and decrypt mail, and a mail transport mechanism
which will pass encrypted mail and still adhere to the appropriate
Internet standards.  We'll also assume a reasonable encryption
function.

I write up an article which looks reasonable but which actually is
libelous in some form or another.  I encrypt it and send it to the
moderator.  It gets published.  As soon as I see it appear, I send
frantic sounding messages to the moderator, the keeper of the keys, and
my system administrator claiming that someone must have broken into my
account and found my key sitting in a file.  Better yet, I can claim
that I accidentally had the permissions on the file with my key set to
public-read.  Prove I didn't.  In fact, to cover myself, I don't
have to even send out those frantic-sounding messages.  I just have to
wait until someone complains.  The I can claim something like:
"I posted WHAT?  The entire Unix kernel?  Never!  I didn't do that!
Wait...now I understand why my news-key file was set to 644 (or
why the holder of "root" at my site was chuckling about how he
'was going to get even with me.'")

Don't put the key in a file, you say?  Make me.

Sorry.  Digital signature protocols generally assume that (at least)
the identity og the sender or the privacy of the key are a given.
We have a situation where both are not secure.  That turns the
situation into one that is much more difficult to deal with.

-- 
Gene "6 months and counting" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet:	Spaf @ GATech		ARPA:	Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp:	...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf

draves@harvard.ARPA (Richard Draves) (02/15/85)

> I write up an article which looks reasonable but which actually is
> libelous in some form or another.  I encrypt it and send it to the
> moderator.  It gets published.  As soon as I see it appear, I send
> frantic sounding messages to the moderator, the keeper of the keys, and
> my system administrator claiming that someone must have broken into my
> account and found my key sitting in a file.  Better yet, I can claim
> that I accidentally had the permissions on the file with my key set to
> public-read.  Prove I didn't.  In fact, to cover myself, I don't
> have to even send out those frantic-sounding messages.  I just have to
> wait until someone complains.  The I can claim something like:
> "I posted WHAT?  The entire Unix kernel?  Never!  I didn't do that!
> Wait...now I understand why my news-key file was set to 644 (or
> why the holder of "root" at my site was chuckling about how he
> 'was going to get even with me.'")

> Gene "6 months and counting" Spafford

What happens if I libel someone while speaking "on the air"?
Don't dial-up radio programs have some sort of libel protection?

Certainly, any system will not be 100% secure.  I would think that
reasonable precautions like a public-key cryptography system would
protect the broadcasters.

Rich
-- 

	"If I am conceited, it is the conceit of an amazing man
	 who has never found any surpassing himself."

						Al-Mutanabbi

lauren@vortex.UUCP (Lauren Weinstein) (02/16/85)

This, unfortunately, is one of the reasons that courts would probably
rule that the encryption-based authentication was not valid for
their purposes.

--Lauren--

jhull@spp2.UUCP (Jeff Hull) (02/19/85)

In article <12022@gatech.UUCP> spaf@gatech.UUCP (Gene Spafford) writes:
>Jay presents a very nice solution to the verfication problem except for
>a few problems -- one of which makes it unworkable.
>
>... <Description of counter-example - please read the original>

First,
>Don't put the key in a file, you say?  Make me.

I can't prevent you from leaving your checkbook lying around with
signed but otherwise blank checks in it either.  But if I find it,
fill one of the checks out & cash it, you have no legal recourse
against me.  I think the same principle applies here.

Second,
>Sorry.  Digital signature protocols generally assume that (at least)
>the identity og the sender or the privacy of the key are a given.
>We have a situation where both are not secure.  That turns the
>situation into one that is much more difficult to deal with.

I think we have a slightly different situation that the one Gene
envisions.  I think the net at large can leave to the individual sites
the problem of dealing with individual users at each site.  Presumably
the security needs of TRW are different than those of someone
accessing the net from his home computer.  

If (the legal eagles think the net/satellite carrier can afford to)
set the limit of the net's concern for liability to the originating
site & let the site worry about the local user base, then we have a
situation where the identity of the originator is known.  And system
administrators can be required to properly handle encryption keys.
(BTW, I envision keys being changed frequently [daily? more often?]
and the key files themselves being encrypted a la /etc/passwd.  Key
updates being passed between sites using keys that are never stored
in digital form. etc  Complete details on request.  If we ever get
that far.)

The cost of administration is automatically spread around.  Each site
is concerned only with those sites that feed it.
-- 
 Blessed Be,

 Jeff Hull            {decvax,hplabs,ihnp4,scdrdcf,ucbvax}
 13817 Yukon Ave.         trwrb!trwspp!spp2!jhull
 Hawthorne, CA 90250

tim@callan.UUCP (Tim Smith) (02/20/85)

In article <554@vortex.UUCP> lauren@vortex.UUCP (Lauren Weinstein) writes:
>I have assumed that some variation on a public-key system would
>be useful to help assure authentication.  However, it should be
>noted that the validity of these in case of litigation is 
>very unclear.  In other words, I know of no court decisions that
>have stated that such systems are acceptable (to the courts)
>as a means of identification.  Perhaps part of the problem is the
>lack of formal verification of the security of these systems
>to date.
>
On the other hand, courts seem to accept handwritten signatures, and as
far as I can tell, these also lack a formal verification of security! :-)
-- 
Duty Now for the Future
					Tim Smith
			ihnp4!wlbr!callan!tim or ihnp4!cithep!tim

lauren@vortex.UUCP (Lauren Weinstein) (02/22/85)

Most radio and TV talk shows use a 5 to 10 second delay so that
they can "kill" a caller before something nasty gets on the air.
The few that don't have a "live" kill button handy and depend on their
ability to drop a caller in real time if they start to drift
into the forbidden zone.  While the delay is safest from their
standpoint, it appears that either technique meets the requirement
of exercising "reasonable care" that such material is not
broadcast.  If a station just let them ramble on, however, then
they'd have real problems on their hands.

The courts have not established the legal validity of public 
key cryptosystems for identification purposes.  Given this
fact, all "reasonable care" techniques must be based on
existing (and court approved) identification techniques (signed
statements, contracts, etc.)

--Lauren--

lauren@vortex.UUCP (Lauren Weinstein) (02/22/85)

For some reason I find it hard to believe that most site
administrators will be willing to sign (or that they might
even have the legal ability to sign) for accepting the responsibility
for the users at their site.  Why do I suspect that few people
are going to want to take the legal responsibility for such
activities on the part of their users?  I can imagine what would
happen when management got a look at that "blanket responsibility"
form.  "You signed WHAT????"  

It should also be noted that we'd probably be dealing with so many
isolated one or two person sites that the overhead would still
be quite large.

--- Enter "getting tired of the infants" mode:

But there's a much larger question.  Take a look at much
of the stuff flying around the net, particularly over the last couple 
of weeks.  Personal attacks in public groups.  "Joke" memos that
seem to be anything except jokes.  People yelling and screaming
and generally behaving like children.  This is the kind of stuff
to send via satellite?  The network rot ratio (NRR) is expanding
at an impressive pace.

--Lauren--

jss@sjuvax.UUCP (J. Shapiro) (02/23/85)

[Pacman's revenge...]
	
	Dial up radio programs typically provide a 6 second delay while the
stuff is verified, so they have plenty of time to bleep out obscenity and
libel...

Jon Shapiro

spaf@gatech.UUCP (Gene Spafford) (03/01/85)

In article <439@spp2.UUCP> jhull@spp2.UUCP (Jeff Hull) writes:
> ...[introductory remarks -- refer to the original.]
>I can't prevent you from leaving your checkbook lying around with
>signed but otherwise blank checks in it either.  But if I find it,
>fill one of the checks out & cash it, you have no legal recourse
>against me.  I think the same principle applies here.

If you write in an amount to those checks and cash them, you are
breaking the law.  Which law depends on where and how you do it, but it
still is not kosher.  That doesn't matter, though, in my example.  My
example was more like leaving a copy of my signature around and someone
forged it to something I didn't write. Even if I protect my digital
signature in a file, that doesn't guarantee that someone won't get into
my account and use it.  Or break it.  Or read through kmem after I've
used it and find it.

>Second,
>>Sorry.  Digital signature protocols generally assume that (at least)
>>the identity og the sender or the privacy of the key are a given.
>>We have a situation where both are not secure.  That turns the
>>situation into one that is much more difficult to deal with.
>
>I think we have a slightly different situation that the one Gene
>envisions.  I think the net at large can leave to the individual sites
>the problem of dealing with individual users at each site.  Presumably
>the security needs of TRW are different than those of someone
>accessing the net from his home computer.  
>
Exactly.  The situation with home computers is much harder to regulate
and enforce some form of validated cryptosignature to be applied to
postings.  As far as leaving it up to the sites, the administrators of
most sites are not any more competent than their users.  Sometimes they
are considerably less competent.

>If (the legal eagles think the net/satellite carrier can afford to)
>set the limit of the net's concern for liability to the originating
>site & let the site worry about the local user base, then we have a
>situation where the identity of the originator is known.  And system
>administrators can be required to properly handle encryption keys.
>(BTW, I envision keys being changed frequently [daily? more often?]
>and the key files themselves being encrypted a la /etc/passwd.  Key
>updates being passed between sites using keys that are never stored
>in digital form. etc  Complete details on request.  If we ever get
>that far.)

Geez, we can't even get sites to run B news or fix their faulty software.
You think they're going to bother changing keys daily?  Even twice a year
is perhaps a little too optimistic.  And their would be too many people
who would have to be "trusted" in such a distribution scheme to make
it work in a simple (or appropriate) manner.


The idea of digital signatures is nifty, but the reality just doesn't
match up with the real-world needs of the net.
-- 
Gene "5 months and counting" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet:	Spaf @ GATech		ARPA:	Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp:	...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf