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

Peter Fairbrother zenadsl6186 at zen.co.uk
Wed Mar 11 17:08:51 EDT 2015


On 11/03/15 13:52, Ladar Levison wrote:

>> So, what do you *need* in an email-replacement signet? Basically, data
>> which tells the potential sender that the signet is, or purports to be,
>> the right signet, and that is all. You don't need any more than that.
>
> The core signet is a subset of the full signet. The core is made up of
> the 5 fields required for encrypting email. Everything else is optional
> and can be "split" off if the user doesn't want to store it.
>
>> To allow someone to say "I warrant that this is my data, see, it has my
>> signature on it"? Can't they just do that in a (signed) DIME-mail?
>>
>>
>
> A simple explanation for using the optional fields: when someone types
> in your email address and your client goes out to fetch the signet, it
> can display a little more info about you in the compose window. Like
> your name and photo. Of course its all optional so we'll see how it ends
> up getting used. Think of it has typing a business card (or vcard) to an
> email address. Optional of course.

did you mean "tying"?
>
>
>>
>> Here is another, linked, question; are you giving up the right to lie
>> about who you are, or stay anonymous, in your email? It seems you need
>> a CA signet in order to receive DIME mail, but can you get one without
>> proving who you really are to the CA?
>>
>
> You can think of the org signet as the CA. Only in the world of DIME,
> the org is the owner of the domain name. You get to pick you want to trust.

Thanks for replying.

Just picking on the obvious points first; optional can be used, and will 
be. If it gets used, it will get abused.

The first law - if data isn't collected it can't be stolen. Do you NEED 
all this data stored to get the system working? Does it even give you 
any significant advantage? I say no.

Ordinary email seems to work quite well with just a <real name> field, 
which people can lie or use aliases, stage names etc in. An optional 
image field, maybe - think of the icons used in web lists, chat etc - 
but no more, not for a ubiquitous secure messaging system.


As for getting to pick who you trust, that's simply wrong - if I want to 
send you a message using DIME, I have to trust whoever you have decided 
to trust.

More, I have to trust them to some unknown extent - for instance, I 
don't know whether you are using a paranoid or a simple security level 
(and even if I did, it wouldn't help any if I am a typical user who has 
not RTFM), whether your server has access to my MIME data, my user 
details - whether it even knows who I am, or purport to be.



You do not seem to understand the high-level design of a system like an 
encrypted email system - writing the code is not the hard part, this is 
the hard part: and it needs to be done, and done right, before any code 
or specs can be written.



I append some first-thought notes on such a system. Possibly one of the 
first things you will see is that there is no place for a trusted server 
in this system.


I think you have in mind that you will operate such a server in DIME, 
but there you forget the second rule - only people you trust can betray 
you.


It seems to me that all of the objectionable bits of DIME - the MIME 
situation, the split signets,the multiple user security levels, the need 
for new server software, the need to trust a server - are all there in 
order to justify, or as consequences of, the desired new server 
architecture.

If we throw that new server architecture out, then we might be able to 
do something useful to increase privacy, which will be cheaper, more 
readily introduced, easier to use, and more acceptable than DIME.


And a hell of a lot securer.



>> If not, it seems DIME is pretty bad choice as a ubiquitous replacement
>> for email.
>>
>
> Its not a replacement. Its a wrapper for MIME messages.

Sent via email?


-- Peter Fairbrother


The principles of data security design:

First Principle: If data isn't collected, it can't be stolen.

Second Principle: Only people you trust can betray you. The rest are 
just out to get you.

Third Principle: Never underestimate the attention, risk, money and time 
that an opponent will put into reading traffic (Robert Morris).

Fourth Principle: Keep it simple. The more complex it is, the more 
places there are to attack.

Fifth Principle. Modes and choices are bad in crypto protocols, they 
give users choices they are not qualified to make. It's your job to be 
clever, not the user's.

Sixth Principle. a system that's hard to use either doesn't get used, or 
it gets misused. Good user interfaces are essential. Users don't RTFM, 
so don't expect them to.

Seventh Principle: Leaving holes to let "good governments" in will 
inevitably leave holes for others as well. (Jerry Leichter)

Eighth Principle: In code, assume nothing ever really goes away.  (Jerry 
Leichter)




-------------- next part --------------
Should provide:

end-to-end encryption
metadata concealment would be useful - however full anonymity against APTs is impractical


Key exchange:
 [*] - see seperate note for pki
 [*] - seperate signature and encryption keys
 [*] - end-to-end FS as well? 

Compatibility with existing server software infrastructure:

option [1] - end-to end encrypted email sent encrypted with STARTTLS over POP/SMTP, or over TLS webmail. No big changes necessary.
option [2] - optional changes to upgrade some (but not all) servers; eg for hiding user "to"s from sending server and "from"s from recipient server; forcing TLS between servers; perhaps onion?
option [3] - mandatory changes to server software. Not necessary, though desirable; ruled out initially on grounds of expense, resistance to change, initial critical mass, etc. May be future requirement.
option [4] - new server/ network. Not needed to provide any desired functionality.


Compatibility with existing client software infrastructure:

[*] - changes to client email software are necessary
[*] - browser extension for webmail


Should be almost transparent to user:

[*] - user should know when email is and isn't e-e encrypted, but doesn't need to know much more.
[*] - no user options - no need to RTFM
[*] - easy to setup, easy to use, easy changeover from ordinary email
[*] - when "send" key/button is pressed software fetches recipient key, encrypts message and any onions etc, and sends. No other user i/o normally needed unless eg key is unavailable. Decrypts automatically on receipt if user key available, puts into "secure mail" folder. Software handles keys and FS completely transparently to user.



Should provide some APT resistance and metadata concealment:

 [*] - some FS from TLS
 [*] - some metadata concealment, eg sending server does not know who intended recipient is, receiving server does not know sender name.
 [*] - onioning? a note on onioning - "please add 2 kb" "please remove 30 kB" should be legitimate commands. 








More information about the cryptography mailing list