ietf-asrg
[Top] [All Lists]

Re: [Asrg] porkhash: flexible anti-impersonation mail signatures

2003-04-03 11:36:00

On Wed, 2 Apr 2003 23:00:21 -0800 (PST) 
william  <william(_at_)elan(_dot_)net> wrote:

This is also a problem with porkhash: it disenfranchises those
without persistent connections (eg much of the third world).  There's
still a heck of a lot of mail tunneled over UUCP these days, or which
relies on disconnected ETRN semantics.

This is not unique to porkhash, many if not majority of proposals
either directly or indirectly rely on source or some central server
being reachable for confirmation (all certificate based proposals, my
callback verification proposals, RMX - have to have working dns
server, etc.)

To have mail work currently you have to have a DNS entry, minimally for
an A record, preferably for an MX.  This extra burden is already
expected, understood, and in place -- the system doesn't work without
it.  DNS has the benefits of not only being able to be externally hosted
and having a well developed cacheing and distribution layer, but
allowing things like the effective authoritative servers to in truth be
secondaries for non-publicly-routable primaries.  Thus, in the DNS
world, there's not only a range of freedom of expression, but the system
as built explicitly enfranchises the small operators who can plug in
seamlessly without (much) collateral expense, and the edge nodes who can
rely on local cacheing for most of their needs.

I see these as Good Things, and properties we should attempt to
preserve.  If we add layers, let's not also ratify and dictate a
technically connected elite.

Another aspect of the porkhash proposal is that it not-only requires an
additional server to be run, but that server must be publicly
routable/accessable and can reasonably expect to be subject to
significant hit rates (and thus bandwidth, hardware, etc costs), and
that's not counting the threat/risk vector that that server which is
handling external queries must also have full access to the secret the
system is based on.  An MTA doesn't suffer those constraints -- it can
be thoroughly disconnected, run behind a transient ETRN or even non-SMTP
transport (UUCP).  The only public structural presence which is
currently required by a mail system is that they have a DNS record -- a
system and service which is already well defined and established.

But to be more exactly on porkhash, you do not need to have your end
to have persistent connection, what you need is to have verification
server available somwhere and it be contracted by the source (server
does not have to be same machine or even same ip network as source -
can be futher upstream). For destination, you do checking on email
when you're receiving it, so once ETRN is then time when destination
has connection to internet and can verify email.
 
I tend to the line that an audit trail should be full verifiable by all
stages in the transport, as well as subsequent to receipt (ie
forensices).  Its not enough to do it once at inception, or once at
receipt.  Once such a truth is established (by the audit trail) it
should remain 'true" for reasonably large values.

-- 
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



<Prev in Thread] Current Thread [Next in Thread>