[148502] in cryptography@c2.net mail archive
Re: [Cryptography] The next generation secure email solution
daemon@ATHENA.MIT.EDU (Guido Witmond)
Wed Dec 18 12:33:14 2013
X-Original-To: cryptography@metzdowd.com
Date: Wed, 18 Dec 2013 11:25:30 +0100
From: Guido Witmond <guido@witmond.nl>
To: cryptography@metzdowd.com
In-Reply-To: <alpine.LFD.2.02.1312172124240.4403@laptop.kerry-linux.ie>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============5949035006512505667==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="----enig2IKBJDIVGNBQVTRTNFCUR"
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2IKBJDIVGNBQVTRTNFCUR
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 12/17/13 21:35, Ralf Senderek wrote:
> Guido Witmond wrote:
>=20
>> For email replacement you need to validate that there is no man in=20
>> the middle. The user agent cannot do that alone. It needs a global=20
>> list of certificates signed by each site. I call that the 'Global=20
>> Registry of Dishonesty' as it will show any attempts at a MitM.
>=20
> Doesn't that open the door for a DOS attack? By which means does the=20
> 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=20
> certificates. The MITM check will expand this model into something,
> I cannot clearly define at the moment, but seems to lead back to the=20
> (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.
------enig2IKBJDIVGNBQVTRTNFCUR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBAgAGBQJSsXgaAAoJEHPd8GglaNRmBOUP/0sZF5Zr03UI4s/wFSQnzlQe
SGdMn6k0/VAkml+prYlZhGDqedHLcpkb0eyU8P7tE845HyKP46WlFrouGWukK6AK
xiW3+sTt1zD0S+QMYjDn3oFaVx+pipoulrHmJ5jkDOcoo/a1Tx616BMeoik3tQ+9
0eh9vV27FtsMyVL8sv2IcsHdTZMq+jefM8nzIrsp2IfL7JehD3j6iITP/EhfC+hC
6V3qxT2z2mQs2F7OeMdVTvVtlPxJEZE0SVHUkB225jkDKHIyUn1Pj3oQd9eK0TAI
cyC9CdL+pkK0//DgYHKjtnpZ+gdjREyVHmUZZvMTWhDgpSUK1Z2HRUc4mfRNZHRV
uhA+Vpc7YpPChkxAd/nqST6IwkR6663T/rQQ5ACQzRXOfo+FjqECZKUXw2MpFyr4
6QxIwqV31c/oHSbNFSyRfGWavVnb31fZRGU5xcwhFhfnAyaCn2tIzoV3Qx9UTG4d
Q9jlh5yU2d1oRLGeLzua2EXWJbC/s8gDM8xwam1qEhp3xyxtWJ/Bi1LB9kBdoDjx
s9qUnVeNHld98PubStAHtkgasPia+fVZnKt+1lbekE4ZidTHgk5oTNBF3wj2ZOEA
mUzhrG19GdgSTqIkRG27kRMJCFwLXRNwicPQ32XKcZO48H67bIOVxHKSxNeqahFj
xk1o9+ilwdPaDEHqe7MJ
=Owk4
-----END PGP SIGNATURE-----
------enig2IKBJDIVGNBQVTRTNFCUR--
--===============5949035006512505667==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============5949035006512505667==--
