Subject: RE: [Asrg] porkhash: flexible anti-impersonation mail signatures

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 3 Apr 2003 18:05:31 -0500

On Thursday, April 03, 2003 3:42 PM, J C Lawrence [SMTP:[email-masked]] wrote:
8<...>8
> My concern there is distribution of the secret.  There's relatively
> little value in cacheing the value of an authenticity check.  Its not
> something that a given site tends to repeat.  However repetitive checks
> of *different* messages from the same MTA will be common, each one
> hammering the possessor of the secret.

I think he means caching of the public-key, so recieving MTAs can do quick 
checks of MTAs in the fowarding path.  I don't think you want anybody handing 
out secrets, but handing a public key out, via DNS, that can be cached by 
recievers seems like a prudent idea.  I do note your concerns on DNS server 
load however, that could be an issue.  DNS servers do however handle a lot of 
queries anyway though it should be noted as a security concern.

e.g., MTAs: O=originator, R=reciver; DNS: DOP=originator public-key RR, 
DRR=reciever porkhasher plug-in DO=originator DNS server

O ehlo, etc...DATA  >> R
O << end with '.'      R
O headers           >> R
latest header  >> read O[x] porkhash >>  DRR   query DOP >> DO
                                      DRR << DOP         DO
					DOP cached TTL n
:repeat for each header 0[x++]
...perform porkhashing checks
...return result, for each O[x]
0 << status (acc,rjt,...) R
end session

When new mail arrives from same O[x] before expiration of n, then
use the cached DOP for 'O[x]' porkhash checks.

> A system which doesn't require either distribution of the secret, or
> ready access to the secret by uninvolved parties would seem better.

Only the MTA needing to know the public-key would be involved and only 
(concerning cache persistency here) query again if necessary.

> --
> J C Lawrence
> ---------(*)                Satan, oscillate my metallic sonatas.
> [email-masked]               He lived as a devil, eh?		
> http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Thu, 03 Apr 2003 22:01:44 -0800

On Thu, 3 Apr 2003 18:05:31 -0500 
Eric D Williams <[email-masked]> wrote:
> On Thursday, April 03, 2003 3:42 PM, J C Lawrence [SMTP:[email-masked]]
> wrote: 8<...>8

>> something that a given site tends to repeat.  However repetitive
>> checks of *different* messages from the same MTA will be common, each
>> one hammering the possessor of the secret.

> I think he means caching of the public-key, so recieving MTAs can do
> quick checks of MTAs in the fowarding path.  I don't think you want
> anybody handing out secrets, but handing a public key out, via DNS,
> that can be cached by recievers seems like a prudent idea.  

Precisely.  The hard computation can be done by a receiving MTA to
generate the signature in the first place, and should reasonably be
optimised to use all-local data.  The verification computation arguably
should be similarly optimised to also use all local data (ie as provided
in the headers) for computation, with verification of the public keys
against cached DNS records to finish the correctness check.

Summary:

  Generators use only local data.

  Checkers can use data local to the headers to verify internal
  correctness of headers.

  Checkers can verify that claimed public keys match keys in DNS to
  close the check loop (straight string compare).

Note: If we're going to go the public key route I'd argue that the
forward chaining proposal offers more capability and verification than
the porkhash -- especially as its value grows with percentage deployment
across the transport chain.

> I do note your concerns on DNS server load however, that could be an
> issue.  

For authoritative servers there will be more load, yes, but with
reasonable TTLs, not that much -- not in a bandwidth or load bearing
sense.  A bigger concern is that the cache in your local DNS server is
going to grow much larger much faster...

> DNS servers do however handle a lot of queries anyway though it should
> be noted as a security concern.

Operations planning...

> (concerning cache persistency here) query again if necessary.

Note that the Porkhash proposal doesn't use signatures or keys, just an
MD5 hash of items with a secret.  Under the porkhash proposal anybody
wishing to verify a hash has to contact a system which possesses the
secret, for re-computation of the hash to see if it matches.  This
requires the secret to:

  a) be on an exposed system.

  b) be on a system which can be systematically explored and tested in
  attempt to deduce the hash.

Neither are optimal conditions.

---

From: Craig Hughes <[email-masked]>
Date: Wed, 9 Apr 2003 15:39:24 -0700

> Neither are optimal conditions.

There's nothing that says the secret needs to persist very long.  You 
are free to alter the secret for every combination of senderid and 
timestamp if you like.  Probably a secret keyed on the timestamp would 
be sufficient; then it's not all that material that the system which 
validates hashes can be systematically explored.  Sharing 365 secrets 
(one per day of the year) is not materially harder than sharing 1 
secret.

C

---

From: J C Lawrence <[email-masked]>
Date: Wed, 09 Apr 2003 15:54:56 -0700

On Wed, 9 Apr 2003 15:39:24 -0700 

>> Note that the Porkhash proposal doesn't use signatures or keys, just
>> an MD5 hash of items with a secret.  Under the porkhash proposal
>> anybody wishing to verify a hash has to contact a system which
>> possesses the secret, for re-computation of the hash to see if it
>> matches.  

> There's nothing that says the secret needs to persist very long.  

If it doesn't I can't retroactively verify message correctness.

  ObNote: Assuming that you want to support in-transport verification
  only (which while useful, doesn't seem a necessary compromise), that
  probably means at least a window of 20 days (4 days per transitional
  MX, plus a forward).