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

[Peter Fairbrother]

On 27/02/15 16:08, Ladar Levison wrote:
> Hi,
>
> I’m about to spend a significant amount of time working on the DIME
> specifications, with a focus towards writing the sections missing from
> the current version, adding some of the low-level details missing from
> the current draft, and incorporating the feedback the community has
> provided.

Had a further look, Some more feedback, based on:

> The December draft can be found here:
>
> https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf




p.20 "Only the author and recipient can decrypt an entire message."

For forward secrecy and protection against key demands, only the 
intended recipient should be able to decrypt message content, NOT the 
sender.




p.20 "Messages are tree structured and content encryption is per leaf 
with independent keys for each leaf,
permitting access to individual parts of the message without having to 
process other parts"

yes, but .. why do you need independent keys? surely the only person who 
can see any message content should be the intended recipient, and you 
only need one key for that?

p.23 diagram You seem to have at least four independent symmetrical keys 
in the message format, but you only have two actors who are required to 
decrypt anything - the intended recipient's dimeserver, who decrypts the 
recipient's name (and perhaps a dimeserver-to-dimeserver transfer layer 
of encryption) and the intended recipient.

The recipient's name is short enough that it could perhaps be encrypted 
(by the sender) using the receiving dimeserver's public key directly, 
not a symmetric key.

for bounce messages, this could include the sender's name. Or the 
message could include an ID from the sending dimeserver, which the 
sending server could decrypt or look up if needed in order to identify 
the sender's name for bounces, spam reduction, etc.



p.27 "The DIME security model depends upon the reliability and security 
of the global DNS system. For this reason we strongly
recommended organizations use DNSSEC"


shouldn't that be REQUIRE, not recommend, if(?) the security model 
depends on it?



p.34 "PART 5: SIGNET DATA FORMAT

alma mater field
gender field"

dick size field? Too damn many fields.


p.59 "Specialized payloads are structured differently from encrypted 
payloads"

NO NO NO. All payloads MUST be treated the same.




p.67 "9 This is an aspect of D/MIME that would benefit from community 
feedback. The current plan is to allow a message which uses the same 
submitted once using DMAP, plus the individual key slot and signature 
symmetric keys to be values for each recipient. The submission server 
would assemble the pieces, and then the full contents would be 
transferred separately between servers over DMTP. "

I don't know what that refers to, but the ONLY time two messages should 
use the same key is when it is the same message to the same recipient. 
Ie, never.

This also helps a little with spam, which I don't see many references to 
in the draft.

"Users who want to avoid fingerprinting of the contents would need to 
submit a separate copy for each recipient."

tut tut.


p.67 "10 Should we define different display types for the different MIME 
content types? And possibly even differentiate a few of the subtypes, 
like text/plain and
text/html, so a client can distinguish which display chunk it should 
retrieve for display purposes? This would leak information about what 
information a
message is carrying, and make them easier to fingerprint, but could 
allow a client to avoid downloading a video message if it didn’t support 
video (for example
on a mobile device). Even if we did add this, there would be a generic 
catchall chunk type implementations could use if they didn’t like the 
leakage.


All this MIME stuff - should be nothing to do with DIME. DIME just wraps 
the standard MIME stuff and content up and encrypts it as a single 
chunk. Let the user's normal email client deal with the MIME stuff. If 
the dimeserver has to deal with it, the dimeserver gets to know too much.


More importantly, the dimeserver gets to know too much in _every_ case, 
not just in partial download cases.


To avoid downloading a large video, the client can download the first 
say 16 kB of the message, where the MIME metadata and plaintext version 
is, and decrypt it. If you want to get fancy, then stick a bit more 
metadata in there, like sizes, start points, and so on. Then the client 
decides what to download, and the dimeserver just gets to know what was 
downloaded - and only when a partial download is performed.


However there is a case for treating signatures differently, so that eg 
spam reduction can be done etc - but then, the signatures should be in 
DIME format and appended to the message, not in MIME format and included 
in the (single) main encrypted chunk.

You could also add the extra content type data in the message signature 
block, if you wish. Would require a small change to the email client, 
but I think you'll need that anyway.




p.68 "DMTP is intentionally simplistic." oh no it isn't !! it's far too 
complex already. The whole of DIME is.

KISS  ;)




Signet stuff - well, data on the use of signets seems to be missing. I 
am not clear about the signets.




p.97 "A user’s reliance on an associated organization server can be at 
three different service trust levels, selectable by the user"

NO NO NO _NO_ *NO*

A luser (a learner user) doesn't understand these options, and can't be 
expected to. Hell, I don't understand them myself.

Do not give him a choice - you decide, you take the responsibility for 
getting it right. That's your job, not his.



-- Peter Fairbrother