[Cryptography] The next generation secure email solution

Guido Witmond guido at witmond.nl
Wed Dec 18 05:25:30 EST 2013


On 12/17/13 21:35, Ralf Senderek wrote:
> Guido Witmond wrote:
> 
>> For email replacement you need to validate that there is no man in 
>> the middle. The user agent cannot do that alone. It needs a global 
>> list of certificates signed by each site. I call that the 'Global 
>> Registry of Dishonesty' as it will show any attempts at a MitM.
> 
> Doesn't that open the door for a DOS attack? By which means does the 
> site that maintains this list decide which certificates are valid
> and which are not?


The Registry is needed in only a few cases.

1. When you sign up for a site (and get a certificate) you submit it to
the Registry and check to see that your CN is unique. To make sure the
site is not MitMing you.

2. When you want to write *the first* encrypted message to someone else,
verify that their CN is unique. To detect if the site is MitMing them.

3. When you receive your first response to an encrypted message you've
send out, you validate your CN-uniqueness. To detect a MitM against you
by the site.

At any point, when you detect multiple certificate for the same CN, it's
a violation of the protocol. Submit it to the Registry to protect the
other side. And blog about it on reddit: The site's CA has become
dishonest. The registry contains the proof. Hence the name.

After the first round, the certificate has proven to be unique. IE: it
is authenticated to belong to 1 person: your communication partner. You
store that certificate in your address book in the agent. There is no
need to check the registry anymore.

Now you can use that certificate to bootstrap other independent
channels, for example a ZRTP connection. It can use PFS, authenticated
by the validated certificate. All without the user having to deal with
any cryptography at all. It's all done by the software.

> Are we relying on a global PKI for this? The benefit of your proposal
> was, that two relatively inexperienced users are able to perform the
> initial steps of a trusted crypto relationship without having to
> trust another third party except the one that issues them 
> certificates. The MITM check will expand this model into something,
> I cannot clearly define at the moment, but seems to lead back to the 
> (broken) system.

At no point does a user have to *trust* a third party. It's all based
upon verification that the third parties are not engaging in a MitM. If
one does, it will be detected and brought out in public for every one.

There could be a step 0 in the above list:

0. Before signing up for a certificate, the agent checks the registry
for the amount of duplicate certificates for any given CN. If there are
duplicates, warn the user that the site is lax with operational
security, or active hostile, or taken over.


I envision something like Perspectives or Certificate Transparency, ie a
Merkle tree of hashes for implementing the Registry to make sure it
cannot lie about a submission. Best if it could be set up in a
distributed way.


I hope that this addresses your concerns.

Regards,

Guido.

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


More information about the cryptography mailing list