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

[Ladar Levison]

This message was indeed valuable. I've been working on breaking up and
reorganizing the specification, with the goal of making it easier to
grasp the important parts, without being overwhelmed by the details.
Reading the spec should be like sipping tea and eating crumpets, as
opposed to drinking from a well endowed fire hose.

I tried to answer the portions of the message that I could...

On 3/1/2015 5:45 PM, Peter Fairbrother wrote:
>
> 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.

DIME wraps around RFC822/MIME _email_ messages, but does not transport
them over traditional SMTP. Rather, DIME uses a bastardized version of
SMTP which can be summarized by saying the localpart has been removed
from the RCPT TO/MAIL FROM commands. DMTP also requires the use of TLS
v1.2 with the ciphersuite 0xC030.  This guarantees PFS at the wire
level, and eliminates the possibility for TLS stripping attacks.
>
> 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.
>
>

Not sure what to make of this, so I'll just address the "traffic
obfuscation is partial" by saying DIME isn't TOR. Metadata is minimized
but not eliminated. Generally speaking, the system tries to minimize
metadata down to an organizational level. Going further would be
difficult, because you'd have to address infrastructure issues, like DNS
queries going out unencrypted, or an attacker with the ability trace a
message using traffic analysis. While DIME doesn't address these issues,
we did make it easy for a domain to advertise onion addresses for
delivery and/or access. See the spec.
 
>
> 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.

TLS provides PFS over the wire, but PFS for messages requires a little
more work. To attain PFS for messages, the user would need to operate in
paranoid mode (and thus avoid syncing their encrypted private key to the
server, where they could be copied). Assuming the user is operating in
paranoid mode, then they could rotate their signet every day (or so) and
delete their former private key when the expiry lapses. This would
provide PFS for any messages protected by the previous public key. I
don't expect many users to want this, but for those that do, its an
option. See the spec.

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

Not quite. I skipped over the parts of your message I didn't understand.
Like I said above, I will try and do a better job organizing/explaining
the details in the next draft. Or if your attending the IETF meeting, I
can sit down and explain the system more completely in person.

L~

P.S. I noticed you discussed other aspects of the system in other
messages. I will try and respond to those when I get a chance.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150305/c251109a/attachment.sig>