1994-12-01 - Re: Hazards of encouraging forged dig sigs

Header Data

From: eric@remailer.net (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 69517801e8ab9a2433742660b9f32a4275b4ca7bb3aa5d27e9965531d5fee0a5
Message ID: <199412012024.MAA13573@largo.remailer.net>
Reply To: <199412010326.WAA22171@ducie.cs.umass.edu>
UTC Datetime: 1994-12-01 19:26:01 UTC
Raw Date: Thu, 1 Dec 94 11:26:01 PST

Raw message

From: eric@remailer.net (Eric Hughes)
Date: Thu, 1 Dec 94 11:26:01 PST
To: cypherpunks@toad.com
Subject: Re: Hazards of encouraging forged dig sigs
In-Reply-To: <199412010326.WAA22171@ducie.cs.umass.edu>
Message-ID: <199412012024.MAA13573@largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain


   From: "L. McCarthy" <lmccarth@ducie.cs.umass.edu>

   I foresee a
   situation in which a large portion of the list traffic uses forged or
   meaningless signing-server-appended dig sigs. When I establish automatic
   signature validation for incoming mail here Real Soon Now, there will be 
   plenty of noise generated by all the `false' negatives in the data to make
   a mockery of the authentication process. 

Recall my comments on transaction failure in a different context last
week.  What is important there is what happens under failure, not
under success.

Sig checking requires an analysis of the pragmatics of failure,
i.e. what happens.  What seems abundantly clear, no matter what
actions are taken, is that it will be actions plural rather than
action singular.  The decision process to decide what happens is much
more significant architecturally that what actually does happen.  An
embedded action, i.e. a hardcoded policy, would be bad, and since sig
failure handling is a relatively unexplored area, one can do it right
the first time.

Assuming such a failure recovery decision process, the actions are
simple: ignore, flag, discard, bounce, get key, etc.  None are
particularly difficult; the decider is what is hard.  Now, assuming
both decider and actions, you can very simply ignore all sig failure
for cypherpunks.

   Encouraging cryptographically
   valid signatures was the first suggestion I'd seen in this entire debate
   which seemed to promise tangible benefits; 

Syntactic checking also encourages valid signatures, just not as
strongly.

   encouraging cryptographically
   invalid signatures is the first notion which appears to offer tangible
   detriment.

It's a problem that won't go away that the existence of bogus
signatures merely make the problem imminent and proximate.

Eric





Thread