[148587] in cryptography@c2.net mail archive
Re: [Cryptography] The next generation secure email solution
daemon@ATHENA.MIT.EDU (Guido Witmond)
Sun Dec 22 18:12:19 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 22 Dec 2013 23:34:10 +0100
From: Guido Witmond <guido@witmond.nl>
To: Ralf Senderek <crypto@senderek.ie>
In-Reply-To: <alpine.LFD.2.02.1312201432240.9069@laptop.kerry-linux.ie>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============0930303296614245723==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="----enig2CWDXQIRDBXBOHOLBUQFQ"
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2CWDXQIRDBXBOHOLBUQFQ
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 12/20/13 14:37, Ralf Senderek wrote:
> I am looking into the future: Secure Email Identities (SEI)
>=20
> The next generation secure email solution based on
> eccentric authentication may look like this:
>=20
> A user finds some website interesting and trustworthy and
> signs on. He gets a client-side X509 cert from the site that is stored
> on his local computer (including unprotected
> private key) under a globally unique name, that can be but
> needn't be his own name.
In fact, the user is better of to create a different (account) name at
each site. As the site name is part of the account name (SEI) these are
already disjunct. Eg. me@gmail.com is disjunct from me@hotmail.com.
The user is free to set passwords/fingerprints/iris-scan/swipe patterns
to protect the private keys on their computer. The agent creates a new
key pair for each account at each site. Important keys can have more
protection than throwaway accounts that a site demanded just to post a
comment.
> Users need their certificate to log into the website that
> has issued the cert, there are no passwords any more and whoever
> *has* the unprotected private key *is* the person and can
> use the SEI.
Exactly.
> Any website can create these certificates for users as long
> as SEIs are globally unique but only for local users.
As DNS(SEC) domain names are unique and each account name is unique,
hence SEI are globally unique.
> The global-uniqueness of a SEI can be verified by checking a
> distributed list of hashes, that enables anyone to see, if
> a certain site issues unique SEIs or not.
> Any duplicate SEI is proof of a problem and disqualifies the
> site as a trustworthy CA issuer, and therefore invalidates
> all user's certificates from the time a duplicate is detected.
> It basically kills the site, as users need certs to log in.
> So every web site has an incentive to do proper signing and
> SEI verification before signing.
It dents the reputation of the site. However, not all is lost. Any
previously validated SEI's in the users address book stay valid. If
people have created separate channels between them, these stay valid
too. The site can die, the users' validations stay. It is encouraged
that people set up extra indenendent channels as a precaution against an
untrustworthy/hacked/coerced site. It also protects against metadata
analysis.
Any message delivery via the site will get logged for life. Independent
channels can be anonymous if set up like a alt.messages.anonymous newsgro=
up.
> How does a user get a key?
> Read: How does the software on the user's computer fetch the
> correct recipient's public key without the user noticing what
> happens behind the scenes?
The protocol automates all these parts. It can be 1 click. "Create an
account at this site".
> All SEI addresses that are not locally stored can be used in
> the initial trust-establishing dance, involving the global
> register.
There are several ways to get to know the SEI of someone.
1. You communicate with people on the blog site. The site acts as
introducer to strangers;
2. You receive the SEI from someone on a business card; or read it from
a printed letterhead; or read it at a newpaper-colophon.
3. You receive it from someone you trust, family, friend. You wouldn't
accept it from a stranger on the street.
> How can a Man-in-the-Middle attack be mounted under these conditions?
>=20
> 1) The classic attack is the case where the cert is not signed by
> the website's CA but the MitM during the sign up step.
No need for quantum computers. If the attacker coerces the
DNSSEC-registrar to sign a duplicate for the fake site, it will be
detected by the Registry that notices a new CA for a known site as soon
as you submit your certificate for inclusion.
> 2) If someone who is not the recipient, replies to my encrypted message=
,
> I need to verify the sender's identity (via a mandatory signature).
> The user agent has to perform sign and encrypt on every message.
> No problem.
> 3) An attacker induces false certificates with the attempt to ruin the
> website. He creates a fake CA and creates duplicate certs for existi=
ng
> users and sends them off to the global registry. As the registry is
> designed to accept all submissions, a number of SEIs will soon
> be unusable. The registry has no means to distinguish benign from
> fraudulent certificates, because the web site CAs are not signed by =
a
> root key or bound to any old-fashioned PKI.
> As I see it, there is no protection from this kind of malice.
This has been foreseen. The Registry validates the submissions to see if
the certificate chain ends in the DANE-specified site-CA. It drops any
certificate that does not match. Eliminating this attack.
The site operator has an incentive to choose a good registrar. And throw
out bad ones.
> And if the endpoint (local machine) is the place where the private key =
is
> stored we will soon have another pile of SEIs becoming unusable, when
> laptops
> get stolen, hard drives die and local OSes become unreliable without pr=
oper
> backup procedures. This will happen.
The endpoint opsec is the weak link. These problems are real. But they
are equally problematic for password. Any malware that goes after
private keys can go after password managers and keylogging the master
password. Any improvement in opsec for passwords is also an improvement
for private key storage. Proper sandboxing, microkernels, process
isolation are important techniques to make client certificates more
safe. We need these techniques urgently anyway, whether we deploy
passwords or certificates. If only to keep my bitcoin wallet safe.
> So in the end we will have a mix of working addresses and dead addresse=
s
> and nobody can tell the difference.
That can be a good thing or a bad thing. Depending on your view.
Guido.
------enig2CWDXQIRDBXBOHOLBUQFQ
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/
iQIcBAEBAgAGBQJSt2jiAAoJEHPd8GglaNRm5VwP/inIilv5f9/qnjqudKVvc3Ij
jfvSpOfoUDTtJPGzUsnmjsDFf9AXCAP+aTcuMWKJJvGo2Bc66om6H2kugM7rH042
tSirRoEszfdDo4bT4pEYMqToYU4RwzauLs5B3M31Oo8eoYuFC7XbhOK1S5AVJ85x
gyzQm12WgRdBfp4jpftD2ygVgCD6lLDKPr3Dwtrc8RME0hCmAPp2gCzDw5DihRw8
+YR1yisRZPmj9jEGijGLee4a9b9Uqm3ofRA8a/Nf2J0UBD+ph+3mWu8451/M4pSL
QGKzQu8Sj6SpnCo8166/djRlh7ln1fzCatJOIeS9b+C59bLRqSmEni5gKOs91Nq7
nOAHfy2m1Pq36MDNRoYJSkFDYE8QydvTl2HVJBtYPojZxQC6pkYhWMHMHztE59tH
wMEvNCTXqi1t8vFGh3hIG4SiXkS1eTC3dXy/BNY7PlN1JdhBRF2LxlqPzhKgp7op
Q7RjGrQ7xPcKejNoHxnSirMVuS4kMIlJaZWzapYbyTMyFy834e52tmhliFGkVTTA
tfvSMPGFSiOcQ3vu+vduaWM7DRqxaqJ0DSETi8QazUfh9gDT1CDfAEE4Qn/qVf7O
SkvIQyqngDs3DJr8HiI0/79KYgYpl9xGvN8cArAz+F+uV6wffaTYHprJUnQglJGk
LwpZakNa48kGJfZHnXIP
=KwUn
-----END PGP SIGNATURE-----
------enig2CWDXQIRDBXBOHOLBUQFQ--
--===============0930303296614245723==
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
--===============0930303296614245723==--
