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

[william@elan.net]

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

On Wed, 2 Apr 2003 william@elan.net wrote:

> 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@elan.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@somewebmail.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.Mason@acm.org> (let's say) would have a different
> > secret from <Random.User@acm.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@ietf.org
> > https://www1.ietf.org/mailman/listinfo/asrg
> 

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg