
Dark Internet Mail Environment: Architecture and Specifications [pdf] - adamnemecek
https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf
======
MichaelGG
> Two pre-authenticated sources are a management record signed using DNSSEC or
> a TLS certificate signed by a recognized Certificate Authority (CA)

So 1. if it's DNSSEC, then verification is handed over to every registrar and
government involved in the DNS chain, right?

2\. Isn't necessarily bad, but so far the biggest CA implementation is a mess.

Dark Mail needs to publish a simple one-page overview and explain how they
fixed things. Because it seems either you end up with a PGP-like mess and web-
of-trust and basically make it unusable, or you end up pretty much handing off
trust to a 3rd party (like everyone in DNSSEC) and hoping for the best. For a
system dedicated to the NSA, the latter doesn't seem feasible.

I'll continue to read it but the fact they don't start off with "here's how we
solved the well-known issues" worries me.

Edit: OK so I gave it mostly a read. It seems to me that the organisation is
the main unit of trust, as far as I can tell. That is, the TLS keys are tied
to the CA/DNSSEC for the org, and the user signets rely on the org. So... what
does Dark Mail provide over using SMTP with policies, like companies already
do? If a client requires TLS to its SMTP server and the SMTP server knows
which policies are allowed for each destination (like from OrgA->OrgB, TLS
required, with CA restrictions XYZ), that's most of the work right there.
Seems like they could get most of the same benefit with a few custom headers
and policies required of SMTP. And they wouldn't need to publish a spec with a
predefined field for "vision statement".

------
sarciszewski
Page 20 / 108:

    
    
        3. Ensure the system is reesistant to manipulation by Advanced Persistent Threats (APTs)
    

Page 27 / 108:

    
    
        The DIME security model depends upon the reliability and security of the global DNS system.
    

Color me skeptical...

------
jauer
I'm curious why a general purpose mail system is bothering to define fields
for resume, political party, supervisor, gender, etc.

~~~
tinco
I agree, he's a bit too specific on many fields. For example his 'common
fields' of the signets include 'currency' and 'cryptocurrency' that has a list
of common cryptocurrencies and their three-letter acronyms.

I guess it's nice that you can advertise a cryptocoin address in your signet,
but locking down the format like that makes it really fragile. Why use the
awkward binary format for the full signet?

Excuse my language, but wouldn't a XML type extensible human readable format
be highly preferable and more future-proof than colon/semi-colon delimited
UTF-8 strings? Not saying it literally has to be XML.

~~~
mattkrea
I would like to see something better too. I know that these low level
protocols are all like this but I think at some point the overhead of
something like JSON (the quotes, brackets, etc) would definitely be better
than dealing with fixed and variable length fields and a lot of regular
expressions especially if you want a lot of implementations created to spread
a new protocol.

~~~
MichaelGG
JSON, binary JSON like MessagePack, XML, Protobufs, Thrift, etc. etc., it
seems a bit weird to invent a whole new format. Actually two, because the
transfer protocol is separate.

Mail transfer has far less performance requirements than, say, HTTP. Plus,
their current format still requires per-string parsing, to separate out e.g.
your "gender" from your "gender label", whatever that means.

------
112percent
I love this idea, but it feels like lots of the other improvements to the
Email system. SPF was introduced in 2003, DomainKeys in 2007, DKIM in 2008,
DMARC 2011; all of these things rely on DNS which for some reason makes it
hard to implement. DNSSEC most recently has been gaining traction, but
languishes at 12% [1]. These things are hard to implement from an operations
point of view for existing systems, but many of the domain names out there are
not owned by people with an operations team and do not understand how they
could reduce their Spam and increase their security.

In order for us to use something like DIME/DMTP we need to find a way to
better integrate our DNS and Email infrastructure binding them together. If we
can ensure that when a Domain name is registered it is mandatory to provide
these additional DKIM/SPF/DIME records then we can make progress. But better
still a way to keep these records up to date when we can providers.

[1] [http://gronggrong.rand.apnic.net/cgi-
bin/ccpage?c=XA&x=1&g=1...](http://gronggrong.rand.apnic.net/cgi-
bin/ccpage?c=XA&x=1&g=1&r=1&w=1&g=0)

------
peterwwillis
The two obvious "ugh" factors here are 1. it's reliant on a "sufficiently
complex" user password, and 2. it's reliant on DNS, and only _recommends_
everyone in the DAME system use DNSSEC. For both these reasons, nobody should
depend on this system to transmit classified information.

In general, mail has always been a highly centralized distributed system. You
would think someone on the darknet would want to decentralize this a bit more,
and you know, make it harder to attack than GMail. (This is technically easier
to attack than GMail itself) I don't understand why people today don't
implement one-time pads into their cryptosystems. It's true that it's probably
the most problematic to implement, but it's also the most secure
(theoretically).

Let's be frank here: the NSA does not really give a crap about your data, and
will probably never look at it, because your data is mainly pictures of cats.
But on the off-chance that you are communicating with someone who might be a
threat to national security, don't trust the safety of your transmission to
protocols that can be breached, 3rd parties who can be issued NSLs, and
systems you don't administer. A properly implemented one-time pad between each
communicant will stymy even the biggest black ops budget, to the point where
your primary concern will be your physical safety and not your password
strength.

~~~
rwallace
One-time pads only work if you already have a secure way to transmit the pads,
and if you have that, you could probably use it to transmit your actual data.

~~~
peterwwillis
You only have to transmit the pads securely once, if you send enough of it.
The rest of the time you can transmit non-expensively. That's the whole point.
It's the tradeoff of one extra-expensive secured communication once so you can
transmit anytime, anywhere afterwards securely. If you really care about
nation states grabbing your data, this is a much more reliable system than
what is proposed herein. (Though really, just a two-factor auth system would
be more secure than what is proposed)

------
0x006A
for a presentation at C1C3 seek to 1:04:40 into the replay at
[http://streaming.media.ccc.de/relive/6597/](http://streaming.media.ccc.de/relive/6597/)

------
oldgregg
Really excited about this, no doubt the NSA has already sent their best men to
"help" on the project.

