Email tapping by ISPs, forwarder addresses, and crypto proxies

[Hal Finney]

Thomas Shaddack writes:

> Reading some news about the email wiretapping by ISPs, and getting an 
> idea.
>
> There are various email forwarding services, which are nothing more than a 
> SMTP server with pairs of recipient at forwarder.com -- 
> recipient at hiscurrentisp.com.

Right, mostly for use as disposable email addresses.  I've used
spamgourmet to good effect, myself.

> Messages in storage have much lower judicial protection than messages in 
> transit. (This does not have much technical merit, in the current 
> atmosphere of "damn the laws - there are terrorists around the corner", 
> but can be seen as a nice little potential benefit.)

One thing I haven't understood in all the commentary is whether law
enforcment still needs a warrant to access emails stored in this way.
Apparently the ISP can read them without any notice or liability, but
what about the police?

Also, what if you run your own mail spool, so the email is never stored
at the ISP, it just passes through the routers controlled by the ISP
(just like it passed through a dozen other routers on the internet).
Does this give the ISP (and all the other router owners) the right to
read your email?  I don't think so, it seems like that would definitely
cross over the line from "mail in storage" to "mail in transit".

> There can be an easy enhancement for such forwarder service; GnuPG proxy. 
> Every email that arrives to the forwarder address, before it is forwarded 
> to the real recipient, is piped through a GnuPG script; the recipient has 
> then to upload his public key during the registration of the target 
> address, otherwise the function is the same.

That's a great idea.  You'd want to be sure and encrypt the whole message
including headers, and make the whole thing an encrypted attachment.
Has the added side benefits of compressing the email, and you could even
have the server do some spam filtering.

> For added benefit, the 
> forwarder should support SMTP/TLS (STARTTLS) extension, so the connections 
> from security-minded owners of their own mailservers would be protected.

STARTTLS support at the proxy should pretty much go without saying these
days, so you might as well do it, but if you're already PGP encrypting
then it's not adding that much security.  Well, maybe it does, but you're
talking about a different threat.  For the problem that ISPs can read
your email in storage, STARTLS doesn't help much because it will only
protect the email until it gets to your local ISP, who will store your
email for you and can read it then (which is where the PGP comes in).

Where STARTTLS would help is with power users who run their own mail
servers.  But those people don't suffer from the problem we are talking
about here, legal access to the email by the ISP (I think, see above).
Nevertheless a mail-receiving proxy that uses STARTTLS connections to
power users would be kind of cool because it would keep anyone local
from knowing anything about the incoming mail.  Hopefully, STARTTLS will
eventually become so widespread that this functionality will be redundant,
but we are not there yet.


> The recipient himself then can either run his own mailserver and download 
> mails through fetchmail, or receive mails using SMTP/ETRN (both methods 
> allow automated decryption of such wrapped mail during its receiving), or 
> use a POP/IMAP decryption proxy, or have a plugin in mail client.
>
> (I know, auto-decryption is dangerous, but we now talk about the system 
> for one's grandma, transparent to use.)

Absolutely, look at the threat model.  You're not worried about someone
breaking into your computer, you're worried about your ISP legally
reading your email.  To address this threat, auto-decryption is a
perfect solution.

Recently there was a proposal for a nym receiving service,
http://www.freehaven.net/doc/pynchon-gate/, by Bran Cohen and Len
Sassaman.  They have a complicated protocol for downloading email
anonymously.  To hide the complexity, they propose to set up a POP
compatible mail server agent on the user's computer running as a daemon
process (Windows service).  He would configure his mailer to connect to
localhost:4949 or whatever, just like any other POP server.  The service
would periodically go out and poll for email using the fancy protocol,
but then it would make it available to the local mail agent in perfectly
vanilla form.  The point is that this architecture hides the complexity
and makes it transparent for end users to use arbitrarily complex crypto
for mail receiving.  Something similar would be perfect for your idea.


> The only vulnerable parts of the mail route then will be the sender's 
> computer, the pathway between the sender and the forwarder server (if 
> SMTP/TLS is not used correctly or at all), the forwarder server (if 
> compromised), and the recipient's computer. The way between the forwarder 
> and the recipient's ISP, including the recipient's mailbox, is secured.
>
> What do you think about this scheme?

I think it's a great idea.  Of course as you say there is still the
problem that the forwarding server could read your email, so you have
only moved the threat from the ISP to another operator.  The difference
I suppose is that the forwarder would be selling privacy services, hence
different ones would compete to get a good reputation.  Any cheating might
be detected by insider whistle blowers or perhaps some kind of audit.

Hal Finney