ietf-mailsig
[Top] [All Lists]

Re: User-to-User or Server-to-Server mail encryption

2004-09-19 11:26:52


1. Encrypting and decrypting entire message is a lot more cpu 
   resource-consuming process then just signing it. It SHOULD NOT be 
   default choice for either end-user or MTA (but I'll not that
   some have proposed to make a default choice for unknown or
   unauthenticated senders to force them to use more resources). 

2. It is undertood that AUTHOR of the email is the person who can best
   decide about needed level of privacy for his email communication.
   This author can in fact encrypt the message with S/MIME or PGP
   in current email system, so we already achieve needed level of
   privacy as is. There is a problem, however, that author does not
   know for sure if recepient would be able to read his email, so 
   some kind of email policy record indicating that end user or
   his MTA can accept and decrypt S/MIME and/or PGP signed emails
   can indeed be helpfull.

3. Email system is more complicated then just end-end. There are
   various email servers that are involved in email transmission
   and none of them want to accept a bad email for somebody else.
   Another problem is that with all the email forwarding, author
   does not actually know for sure who the recepient would be.

P.S. I actually disagree with those that think signed S/MIME or PGP
   messages would not pass through end-end in current email system.
   I sign messages with S/MIME for one of my account and with
   OpenPGP for another. I've never seen any emal where signature
   would not be passed through by email list or similar forwarder.
   Its another question that I really dont know if recepient has
   capabilities to verify either S/MIME or PGP signature. And this
   problem with no "one and only" email signing standard has caused
   serious problems in adaption of this technology by end-users.

On Sun, 19 Sep 2004, Andriy G. Tereshchenko wrote:


Currently this list discuss one of problems - validation of email author to 
_possibly_ prevent spam/abuse.

But how about email privacy ? 
Nobody at post-office allowed to read your regular (paper) mail. 
But why all kinds of email filters constantly dig for keywords inside your 
messages ?

Why nobody discuss email-encryption/signing solutions ?
If we will send each-other a  gzip-compressed, encrypted and signed files - 
this will definitely solve a lot of problems.
 
No worry about canocalization, no worry about prepended/appended content at 
old non-compatible MTAs, no worry about your email read
by business competitors, no worry about email author, as well this can result 
in email traffic decrease (useless feature nobody care
about ;-)

Each mail server can announce in DNS that it accept such a emails and 
decoding will done at server-side or optionally if user really
need this - at end-user computer.
Everything will be transparent. 

In contrast from SSL/TLS - this will be sender-receiver encryption, not a 
hop-to-hop.
In contrast from user-level SMIME/PGP - this will offer some transparency for 
users. 
Offload key management and signing/decryption to email servers or 
email-proxies (this is much easy compared to change all MUA
software).

What do you think about this ?
How about making content of all emails secure ?
--
Andriy G. Tereshchenko
Odessa, Ukraine


<Prev in Thread] Current Thread [Next in Thread>