[Cryptography] DIME // Pending Questions // Seeking Your Input

[Peter Fairbrother]

On 05/03/15 13:18, Phillip Hallam-Baker wrote:
> I think we need to take a step back and ask why anyone is going to move
> to a new messaging platform and work from there. Security isn't the
> answer, that is merely an abstraction to most users.
>
> Instead, consider the following problems with current messaging platforms:
>
> 1) They are fractured. In the old days we had mail and news that were
> almost but not quite the same thing. The Web started to bring them
> closer together and then Netscape decided to blow them apart. Today we
> have mail, chat and webcams in the one to one space and mailing lists,
> blogging, blog commenting, Tumblr-ing and tweeting in the many to many
> space.
>
> 2) The messaging platforms are widely abused. This is largely due to a
> lack of accountability and the notion that publishing an email address
> is license for anyone at all to send content of any type.
>
> 3) Ownership of the forum and the content has been appropriated by
> intermediaries. In most cases merely because they got there first.
> Facebook and Google have too much power over what is said.
>
> 4) They don't protect provide necessary confidentiality or integrity
> protections.
>
>
>  From a protocol standpoint, all these diverse platforms are actually
> very similar. MIME content types and URIs solved the problem of
> supporting diverse content types in one medium long ago. But we still
> have the artificial boundaries between modes of communication.
>
> Now developing an infrastructure that replaces all the existing
> messaging forms just to add crypto might seem like a boil the ocean
> approach. But that is exactly what Tim did with the Web which replaced
> all the extant information sources with one user interface via gateways.

Eh, wot abaht FTP?

Tim's Web had huge advantages for the user - does DIME, or some 
overarching new infrastructure, have any such advantages?



Let's compare DIME with a fairly minimal and simple email encryption 
environment. In our simple environment encrypted email is sent over 
normal email channels. There are public key "signet"s for the users, 
which are kept in a distributed directory on a server somewhere.

Perhaps the @ is replaced by &, or there is something else in the 
address, in order to distinguish email addresses which will only accept 
encrypted email.

With a bit of handwavium over MITM for now (maybe I'll get into that 
later), a sender collects a public key "signet" from the directory 
server, and uses that to encrypt the message including attachments, 
signature, whatever, including the "from" field [1].

He transfers the encrypted message to his email provider via TLS. They 
then send it to the recipient's email server, hopefully via TLS as well. 
The recipient then collects it via TLS.


So, what does this system need in order to be implemented? It needs mail 
servers to use TLS between client and server, which is not a huge 
stretch. It needs a single or better several distributed directory 
servers. It needs updates to the client's email programs, or webmail 
with a hidden key program, probably a browser extension.



Cypherpunks write code? Get to it chaps!



DIME requires all these (?except the directory server?), but it also 
requires each user to employ a DIMEserver.

Afaict, DIME would need a critical mass of DIMEservers to be in 
existence just to start being useful. I might be wrong about that, but..

And I cannot see any great security reason or advantage for having the 
DIME servers. Ok, they might be required to use TLS server-to-server, 
but apart from that?

Is the benefit worth the cost?


Advantages of the simple system: it is compatible with ordinary email. 
It does not require any changes to existing email servers, or ask them 
to do anything they don't normally do, though it would be good if they 
always used TLS.

It encrypts email, it does the same job as DIME to provide FS, it 
actually does more than DIME does to hide metadata.

And most important, it does not require every potential sender to employ 
a dedicated DIME email server.

As to MITM, I don't understand the DIME anti-MITM mechanism (it isn't 
fully documented), but as far as I can tell there is no reason why the 
simple system can't provide exactly the same functionality.



[1] or perhaps the "envelope-from" field contains 
"simple-encrypted-email" - I am no POP/SMTP email expert, but the idea 
is that only the recipient (and the sender's server) can see who the 
sender is.



hmm, can you configure today's mail servers to only accept TLS connections?



-- Peter Fairbrother