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

From: "Bob Atkinson" <[email-masked]>
Date: Wed, 2 Apr 2003 15:32:20 -0800

I see how this sort of approach can tie a particular timestamp and
sender_id / email address together in a MAC which can be validated, but
I'm missing how the MAC gets coupled to a given message. 

Was such a coupling intended?

If not, what's to prevent a spammer who gets his hands on one of these
(a valid one) from then using it to send a million messages of his own
(where of course he'll force all the other headers as necessary).

Confused,

	Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Justin Mason
Sent: Wednesday, April 02, 2003 2:09 PM
To: [email-masked]

Hi all --

[...]

From: jm

There's 2 entirely separate components; the SMTP part, adding the
header;
and the CGI script, validating the header.  The only data they need to
share is the secret passphrase, so they do not even need to be on the
same
network!  Here's how that works:

- header contains:

  sender_id (usually email addr?)
  timestamp
  opaque_md5_sum = md5(sender_id, timestamp, secretkey)

- CGI parses header to get:

  sender_id
  timestamp
  opaque_md5_sum

- CGI already has:

  secretkey

- it then computes md5(sender_id, timestamp, secretkey) and compares it
  with opaque_md5_sum.

If it matches, ok, if not, it's an invalid signature.

[...]

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

---

From: [email-masked]
Date: Wed, 2 Apr 2003 14:23:52 -0800 (PST)

Same as with S/MIME certs - if they got hold of your key, they can pretent 
to be you.

But there is actually way to help the situation with porkhash. Since we 
know that ever time email is received, there is a verification request 
done to the origin server  (and messageid is provided too!) - too many 
verification requests would signal something maybe wrong (i.e. you 
might expect 100 email from that client, maybe if they send to large 
email list - 1000, but 1 million - you know something is wrong). Plus
the request can be doublechecked and matched to messageid (though that 
requires verification server to be tied to messagetracking - just like in 
my proposal). 

I actually like this porkhash quite a bit. I'm thinking it can actually 
work best if tied to messagetracking (so instead of messagetracking being 
plaintext, we now have some crypto authentication) plus it also ties 
nicely into opt-out system.

---

From: [email-masked] (Justin Mason)
Date: Wed, 02 Apr 2003 16:53:01 -0800

> Was such a coupling intended?

The intent is that the MAC is included in a message's headers, where an
MTA, a user's filter, a MUA, or even an end user with savvy can then
extract it and perform a verification operation.   The most recent
thinking indicated that including it in a Received header seemed to
work well, since that already can include all the info about sender_id
etc.

> (where of course he'll force all the other headers as necessary).

The key, as I see it, is the use of a timestamp.  Spammers who wish to
replay a valid token, will then have to intercept a message with such a
token within a small window of time *after* the message was posted (and
presumably archived on a public webpage for example).

It's reasonably trivial, modulo the usual date-stamp-decoding logic,
to compare the Date header's timestamp with the MAC's timestamp.

BTW a key point here is that the porkhash string contains *both* a
human-readable (or at least machine-readable) sender_id and timestamp, as
well as the hashed version of that data; so the recipient's validation
code also gets to make a decision about the validity of that data, as well
as the verification server.

Also -- in response to William's point about distributing keys to users'
MUAs; it's important to note that in most use-cases I would imagine the
user would *not* have to use a key in their MUA -- that would be strictly
an edge case.   Instead an injecting MTA, to which they had authenticated
access, would include it on their behalf, for example an ISP's SMTP server
which auths based on source IP address, POP-before-SMTP, or SMTP AUTH etc.

--j.

---

From: J C Lawrence <[email-masked]>
Date: Wed, 02 Apr 2003 17:02:09 -0800

On Wed, 2 Apr 2003 14:23:52 -0800 (PST) 
william  <[email-masked]> wrote:

> But there is actually way to help the situation with porkhash. Since
> we know that ever time email is received, there is a verification
> request done to the origin server (and messageid is provided too!) -
> too many verification requests would signal something maybe wrong
> (i.e. you might expect 100 email from that client, maybe if they send
> to large email list - 1000, but 1 million - you know something is
> wrong). Plus the request can be doublechecked and matched to messageid
> (though that requires verification server to be tied to
> messagetracking - just like in my proposal).

> I actually like this porkhash quite a bit. I'm thinking it can
> actually work best if tied to messagetracking (so instead of
> messagetracking being plaintext, we now have some crypto
> authentication) plus it also ties nicely into opt-out system.

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.

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

---

From: [email-masked]
Date: Wed, 2 Apr 2003 23:00:21 -0800 (PST)

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

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.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 03 Apr 2003 10:33:39 -0800

On Wed, 2 Apr 2003 23:00:21 -0800 (PST) 
william  <[email-masked]> 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.

---

From: [email-masked] (Justin Mason)
Date: Thu, 03 Apr 2003 11:51:25 -0800

> should remain 'true" for reasonably large values.

I agree BTW.  A factor in this is that we cannot trust audit trail entries
which are *claimed* to be verified by entities outside our control --
generally, anything beyond our MX.

For example it's commonplace in spam nowadays to receive a mail at one's
MX, which claims it had established an audit trail (Received headers) from
an originating host, to the relay which opened the SMTP conn to our MX --
whereas in actual fact, all the Received headers before that one are
fakes, inserted by the spamware, intended to throw spam-reporters
off-track.

Here's a sample.  The top line is my MX.  The next 3 lines are all
faked.  I know they're faked because (a) the hostnames/IPs don't resolve
to what they claim to be and (b) they use host and protocol names that
have been identified as being generated randomly by this spamtool.

 Received: from [200.203.96.67] (helo=aol.com) by yzordderrex with smtp
    (Exim 3.35 #1 (Debian)) id 18tt7d-00075m-00; Fri, 14 Mar 2003 17:37:34
    +0000
 Received: from rly-xl05.dohuya.com ([35.238.84.138]) by
    anther.webhostingtotalk.com with SMTP; Fri, 14 Mar 2003 14:37:08 +0100
 Received: from unknown (29.23.228.6) by rly-xw01.otpalo.com with QMQP;
    14 Mar 2003 15:35:51 +1100
 Received: from [99.50.80.61] by sydint1.microthink.com.au with SMTP;
    Sat, 15 Mar 2003 02:34:34 -0900

--j.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 03 Apr 2003 12:05:06 -0800

On Thu, 03 Apr 2003 11:51:25 -0800 

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

> I agree BTW.  A factor in this is that we cannot trust audit trail
> entries which are *claimed* to be verified by entities outside our
> control -- generally, anything beyond our MX.

Right, that's one of the things I thought about with my forward chained
sigs approach.  The Received: headers in themselves can be checked for
internal consistency: does each signature line up with the claimed
public key?  And the public keys can be verified against DNS without
doing a damn thing to the DNS protocol or definitions, and without
requiring an external third party signator or clearing house for those
keys (sorry RSA/Verisign/BaltimoreTech/etc), _snd_ without running afoul
of crypto laws in various countries (it can use small non-milspec keys
with fair safety).

The idea was to get an audit trail with the least possible change to
established systems or requirements of participating nodes.  I don't
know if its the minimal path, but its as small as I've found to make it.

> For example it's commonplace in spam nowadays to receive a mail at
> one's MX, which claims it had established an audit trail (Received
> headers) from an originating host, to the relay which opened the SMTP
> conn to our MX -- whereas in actual fact, all the Received headers
> before that one are fakes, inserted by the spamware, intended to throw
> spam-reporters off-track.

Yeah, I get a lot of these.