Dark Internet Mail Environment: Architecture and Specifications [pdf]
darkmail.info
darkmail.info
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".
3. Ensure the system is reesistant to manipulation by Advanced Persistent Threats (APTs)
The DIME security model depends upon the reliability and security of the global DNS system.
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.
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.
Also not a fan of their little mini-formats embedded inside the format. Pick a structured encoding system, and stick to it. Like cryptocurrency, if it has to exist, should have two fields, type and address. Not this silly parse-text-look-for-semicolons. This kind of stuff leads to people grafting on all sorts of extra bits that require special parsing. It's bad and pointless. Use a binary JSON or something format and call it a day, and don't cram anything else into a string field other than a single value.
And the Phone field definition provides no format for the number, thus making many numbers you receive potentially ambiguous. Does 502 refer to Kentucky or Guatemala?
Seriously though: predefined fields to refer to a user or organisation's "vision statement"? Someone discovered that when you're just typing specs in Word, there's no implementation cost to pay and you can literally type in anything you please. This is the same problem that plagues various other specs. The same reason HTTP has line-wrapping in header fields, or why email URIs can contain comments, ffs.
There also seems to be a lot of "mays" and weird behaviour. Like, images can be 16MB. But you should keep them at 1MB or less, cause maybe clients might not display them if they're over 1MB. Probably. They can ignore them over 1MB, but they have to "handle" up to 16MB. This kinda stuff serves no purpose but to harm interop and split implementations.
Seriously, the more I read this, the more I see someone just having fun re-making email. Hey, sky's the limit! This is pretty funny considering: "DMTP is intentionally simplistic". Simplistic, but they cannot even agree on LF versus CRLF. Seriously. Brand-new protocol, and line-endings for the transfer part is implementation defined.
Disclosure: Given Lavabit's past, I was inclined to think Dark Mail would be more snake oil, so I am definitely biased.
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...
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.