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

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

On Wed, 2 Apr 2003, Justin Mason wrote:

> Hi all --
>
> J C Lawrence posted a scheme a few days back about authenticating the
> Received chain with "forward chained digital signatures".
>
> Also, william(_at_)elan(_dot_)net 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 <dfskjd23(_at_)somewebmail(_dot_)com> 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 <Justin(_dot_)Mason(_at_)acm(_dot_)org> (let's say) would have a 
> different
> secret from <Random(_dot_)User(_at_)acm(_dot_)org>.
>
> 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
> Asrg(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg