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

[Peter Fairbrother]

On 27/02/15 16:08, Ladar Levison wrote:
> Hi,
[...]
> The December draft can be found here:
>
> https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf

Had a very quick look, seems like DIME is an email-like message-passing 
service of some kind - though it is not email, it will not work on 
normal email channels, it is not compatible with email - with end-to-end 
encryption and some attempt to prevent traffic tracing and to provide 
forward secrecy.

Neither the end-to-end encryption nor the traffic obfuscation is 
particularly robust - the encryption is subject to MITM attack, and the 
traffic obfuscation is at best partial, and depends on trusting the 
sender's and the recipient's end servers, presumably operated by other 
people than the sender or intended recipient.





Sender x sends a message through server X to recipient y's server Y. 
Roughly, server X will serve clients using TLD X, and server Y will 
serve clients using TLD Y, as both sending and receiving servers. 
Clients can be offline when messages are passed.

To deter MITM there is a complicated system of "signets", where two key 
signatures are obtained from somewhere - a CA? and the sender's server? 
the recipient's server? I am unclear about this.

In any case, it would seem that this requirement to fetch (at least) 2 
signets per message compromises the traffic tracing obfuscation - the 
servers holding the signets would know who sent the request, and the 
intended recipient it was meant for.






In order to make message tracing a little harder, an observer of traffic 
between server X and server Y cannot immediately tell which of server 
Y's clients the traffic is for.

However there is no delay or batching, so a passive observer of person x 
and his server X can immediately tell that x has sent a message to 
server Y, though he cannot immediately tell which of server Y's clients 
the message is for.

This system is obviously not robust against compromise of the recipient 
server, including legal requirements to store traffic data (formerly a 
becoming-ubiquitous legal requirement in the EU, now the legal status of 
traffic data retention is a bit indeterminate - though anyone operating 
a server in the UK today, for instance, would be required to log the 
relevant  traffic data and store it for 12 months.)

I think the sender's server X is not intended to know which of server 
Y's clients the traffic is for, just the recipient's server - however, 
the requirements for obtaining signets and perhaps DH portions also make 
server X susceptible to attack based on server compromise, and probably 
server traffic data retention requirements as well.



Also, according to figure 1, server Y sends some data direct to the 
sender. I am unclear about what data is sent, or why. so it is possible 
server Y does not know for sure who the sender is, but it seems likely.

Again, from figure 1, it seems some data is sent from server X directly 
to the recipient - so server X is likely to know who the recipient




There appears to be some form of forward secrecy, but details are 
lacking - as far a I can tell the recipient y seems to have a permanent, 
or at least semi-permanent, DH secret; so for instance message 
confidentiality is not secure against legal or rubberhose demands for keys.


As I said, I only had a very quick look - is that about right?




-- Peter Fairbrother