On Thu, 3 Apr 2003 18:05:31 -0500
Eric D Williams <eric(_at_)infobro(_dot_)com> wrote:
On Thursday, April 03, 2003 3:42 PM, J C Lawrence
[SMTP:claw(_at_)kanga(_dot_)nu]
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.
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...
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.
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.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(_at_)kanga(_dot_)nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg