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

From: [email-masked] (Justin Mason)
Date: Wed, 02 Apr 2003 14:09:11 -0800

Hi all --

J C Lawrence posted a scheme a few days back about authenticating the
Received chain with "forward chained digital signatures".

Also, [email-masked] has mentioned '3. Complex callback verification
requirying full message tracking server functionality with dns extensions'
in his presentation.

Both of these are very similar to something I and others cooked up on
another mailing list a couple of months back.  I asked if I could forward
it on to this list, and they said "sure", so here it is.  We called it
"porkhash" BTW.  It's based on "email cookies", similar to Russ Nelson's
Q249 scheme and Pedro Melo's webmail auth cookie scheme.

Salient summary points:

  - If this scheme or something similar is implemented, then it -- like
    RMX, Designated Sender and others -- will mean that spammers will have
    two options for source obfuscation:

    - impersonate sites that do not implement this scheme (short term);

    - get tied down to a single domain or set of domains -- much easier to
      blacklist, track down, prosecute etc.  ie.  widespread impersonation
      of <[email-masked]> is no longer effective.

  - Requires 2 components: a "porkhash" signing component in the MTA which
    generates the porkhash; and a "porkhash" verification server on a HTTP
    server (or similar) which verifies hash validity and responds with a
    "yes" or "no".

  - It does not require an internet-wide key-management infrastructure for
    all mail sending organisations

  - It does not require that the sending MTA and verification server
    operate on the same machine, the same net, or even the same continent.
    All they need to share is the shared secret.

  - It does not require a database of stored Message-IDs (or similar
    read-write infrastructure)

  - advantages over RMX, DS et al:
  
    - a roaming user can sign their own mail headers, if they know the
      shared secret.  (requires MUA modification, a localhost SMTP
      proxy, or a similar signing app to do this though)

  - advantages over PGP-signing by relays:
  
    - transparent (only visible in headers), does not modify message body
    - PKI/key distribution stuff not required outside sender's
      own infrastructure
    - immune to breakage caused by message-body-munging by relays,
      gateways and mailing list software

So here's the nugget of the idea, if anyone cares to take it up and run
with it (or cannibalize it).  I'm a bit short of cycles myself right
now...  :(

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.

This IMO is the beauty of it.  Instead of other systems, which require
either bouncing stuff around via SMTP to validate mail, or a separate
server built into the SMTP server, it can validate mail using an
*entirely* separate HTTP server.   This is a hell of a lot easier for a
sysadmin to set up, and minimises the hackery in the mail-sending side.

Actually, one thing it's missing is that the URL of the validation CGI
should be listed in the header as well, since each sender SMTP server (or
block of SMTP servers sharing the same key) needs a validation URL to
itself.

Also, as Andy said, Russ Nelson's Q249 system is very similar.  It does
all the above, *but* it does not hash the timestamp, which I think is key
in this scheme, as it blocks replay attacks.  For details on Q249, see
http://q249.org/ .

From: jm

Russell Nelson said:
> Neale Pickett writes:
>  > ....  And remember, you *must* authenticate the body, or else a man in
>  > the middle could grab mail off the wire, rewrite the contents to be
>  > spam, and then reinject it.
> 
> Well, they wouldn't grab it off the wire, they'd grab it out of a
> mailing list archive, or some other public source of email.

that's the deal with including a timestamp in the hash; it avoids
that problem, since the hash would have expired if they grab an old one.
So, yes, with a hashed-timestamp scheme, they'd have to grab it off the
wire [*in transit* -- which is much harder].

From: Matt Sergeant

So all we need is someone to write plugins for the most popular web 
servers (Apache, IIS and a CGI script) to do the authentication part, 
then write some plugins for the popular email servers (qmail, sendmail, 
exim, postfix, oh and That Microsoft One) and we're set, right?

Then we need to standardise on what to put in a header - I would 
suggest serveral bits of info about the specific email (send time, 
send IP) along with where to verify the cookie and then SHA1 them 
together with a secret. Store the secret in the web server and the 
SMTP server config. Voila - all done.

From: Matt

[paraphrased, lost the mail:  We need to list the hostname used to
contact the verification server, in the porkhash.

The recipient can apply "common sense" rules, like verification server
domain must == sender's domain.

Alternatively use a DNS TXT record on the sender's domain to list that
server's name.]

From: Craig Hughes

Most of that info [sender data] is already in the Received header.  What
Scott and I came up with yesterday was the theory that you could fairly
add the required info into the received header since parts of that can be
more or less freeform.  So you end up with something like:

 Received: from unknown (HELO startechgroup.co.uk) (10.2.100.157) by 
   matt?dev.int.star.co.uk with SMTP 
   (porkhash:verifyme.startechgroup.co.uk:XXXXXXXXXXXXXXXXXXX); 5 Feb 2003 
   09:44:51 -0000

Then to verify, you contact verifyme.startechgroup.co.uk, and the 
XXXXXX should be maybe the hash of everything in the line =~ 
s/(porkhash[^)]*)//

[We then got sidetracked into RMX, DS, etc. discussion. end of thread ;)]

Finally -- a few more points.

1. it's worth noting that this can be used with acm.org or other mail
forwarding services.

What these services would do, is provide a "shared secret" for each
user -- so <[email-masked]> (let's say) would have a different
secret from <[email-masked]>.

Justin.Mason would then download that shared secret and use it in porkhash
generation when sending mail from his MUA with that address.  (So it'd
require MUA modification, a localhost SMTP proxy, or an app which
generates the sigs for him.)

The verification server then would read the sender_id field -- the
email address -- from the headers in question, figure out that the
sender in this case was Justin.Mason, and use *his* shared secret
to compute validity.

Alternatively, the user could just relay via acm.org's SMTP relay,
assuming it provides auth in some way.   It can then add the porkhash
line.

2. Also worth noting that, since the hashes have a limited time-period of
validity, key revocation is no problem.   If a key "escapes" or is
stolen, it can be replaced, and the verification server just has to
know *when* the key was replaced; messages before that time can use
the old key, messages afterwards must use the new one.

3. Also, multiple "hops" of verification are possible, since each
Received line could have a porkhash token in it.  The recipient,
if they wished, could then verify *all* of them instead of just the
oldest one.

--j.

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

---

From: J C Lawrence <[email-masked]>
Date: Wed, 02 Apr 2003 14:52:43 -0800

On Wed, 02 Apr 2003 14:09:11 -0800 

> Received chain with "forward chained digital signatures".
...
>     - immune to breakage caused by message-body-munging by
> relays, gateways and mailing list software

I should note that the scheme I posted as written will break for those
list servers that:

  a) rewrite the Message-ID 

  b) don't remove prior Received: headers

Such is legit under [2]822 and centers on the controversy as to whether
a list broadcast is a new message or a retransmission of an extant
message.  FWLIW I'd be quite happy if Message-ID rewriting were ruled
against.

> Also, as Andy said, Russ Nelson's Q249 system is very similar.  It
> does all the above, *but* it does not hash the timestamp, which I
> think is key in this scheme, as it blocks replay attacks.  For details
> on Q249, see http://q249.org/ .

I explicitly encoded the Message-ID into the auth chain to allow binding
of the auth chain to a single message.  Prevention of replays of canned
good header sets is accomplished by encoding the time and addresses
involved in each transaction.  Not fool proof, but requires compromise
of an authenticating system (eg direct spool inject without a header
being added) to bypass.

-- 
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 13:06:56 -0800 (PST)

Reminds me of technical details for opt-out proposal I posted just recently:
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg02280.html

Difference is for opt-out receipient runs verification server where as 
for porkhash, its the sender that runs verification server.

As for the actual proposal, the only modification I would do is to have 
dns SRV record (or any other agree upon A name) for specific domain which 
points to verification server for that domain (instead of sending it as 
part of the header). Reason is sending header by the sender is insufficient
- spammer can do the same and used wrong domain name and still setup 
verification server that answer yes on all queries no matter what domain 
name and then they get free ride to use whatever domain name they want in 
from. If you actually tie it to dns, then the domain owner through its 
dns records controls the records for the domain. Header with actual 
verification server can still be sent, but then client should check to 
make sure its one of approved verification servers through that special 
dns record.

Tiying to dns also solves one other major problem - namely forging of 
headers - i.e. if you do it without this system, then spammer is free to 
forge the header (he just does not use porkhash), but if dns actually says 
that this domain has porkhash verification server and the email that came 
did not have the correct porkhash header, then you can suspect email may 
have been forged.

There still remains the system of distributing shared keys to all MUAs, 
and changing them regularly, I'd recommend this be done as well through 
verification server using special authentication. I'd also recommend not 
doing the system as http cgi but specifying the verification be done as 
new service (which can very well be http but running on different port).

---

From: [email-masked]
Date: Wed, 2 Apr 2003 13:26:59 -0800 (PST)

Thinking about this couple seconds more. What if verification is actually 
done by http and not only by http but is required to be done through https 
- SSL, i.e. verification server MUST present the certificate. Then the 
destination can get the certificate info. Verisign would be happy too :)