LEAP is a project that tries to upgrade the security aspects of many existing technologies such as SMTP and DNS by applying many patches and workarounds rather than addressing the fundamental issues.

LEAP claims that in order to fix SMTP, the needed pieces are (1) opportunistic encryption via automatic key discovery/validation, (2) enforced StartTLS and (3) meta-data resistant routing. Let's discuss each of these points.

Contents

[edit]

Automatic public key discovery

Unfortunately with e-mail the key is not the address and as long as there is no secure link between the address and the public key or certificate, there will always be possibilities of failure or MITM. X.509 is a failure that can't be trusted. Naming systems that aren't self-authenticating will always offer attack vectors. Here are some ways for resolving cryptographic discovery elegantly:

  • Strong: Hold a public key address printed as a QR code in front of the webcam
  • Medium High: Have a VoIP conversation and read each other's fingerprints aloud.
  • Medium High: Adopt a contact from an existing contact's social graph.
  • Medium Low: Both sides type in a shared secret. You may want to apply some case normalisation to avoid minor mistakes in perception of the shared secret.
  • Low: Fingerprint exchange.

Methods like OTR's shared secret or old-fashioned fingerprint confirmation can be done, but there's always the risk people will cheat by using e-mail to exchange the info.

In practice it is a fallacy to think that email addresses are necessary and easy to use. Systems that route by cryptographic identity have proven to be actually easier (just try Pond). Also Facebook has proven that the actual delivery address is irrelevant. It's the profile that counts.

LEAP presents a strategy for reducing the risks of X.509 and so forth in the process of retrieving the public key for a certain email address. It is called nicknym and described at https://leap.se/nicknym

Think of your grandma. She unpacks her brand new computer with a free operating system on it. She clicks on "send a message" and the software asks her to insert the identifier for her son. Typing user@domain may be slightly easier than inserting 7yuogiqxgrak36kk.onion, but it is harder than holding his business card in front of the webcam or typing in what they agreed upon (a shared secret). Some keyboard layouts have a very nasty place for the @ sign.. ;)

But the real problem is different: once she starts using her brand new computer, the communications software generates a key pair for her. Will she go to some israeli authority and get herself a free (as in free beer) certificate? Or will she prefer to pay an american one? And will she do it each year? No. Would those make sure she is who she claims she is? Neither.

So how can the son be sure who is calling? According to LEAP he should be able to trust the combination of TOFU, perspective and provider keys. Let's walk through these options:

  1. noone has talked to his grandma yet, so perspective is out.
  2. provider keys, which seems to be a web-of-trust-based certification structure, isn't useful either, since his grandma's computer is new and knows nobody (not talking about exposing your interest for a certain public key to some external authorities...)
  3. so the only thing remaining is TOFU: trust on first use.

In practice he has no other choice than to call her up on the phone and ask her to click on some menu items and have her read the public key hash to him, or he just doesn't care and deals with it if there's a man in the middle.

Under these circumstances the shared secret or the business card bearing the public key in form of a QR code are much safer methods of bootstrapping a trustworthy communication.

The printed QR code in fact has an unbeatable advantage - you don't need to arrange for both sides to be online. You just hold that card or brochure in front of the webcam and can immediately communicate or access some basic authenticated profile information. This is also amazing for business. With LEAP you're thrown back to websites with insecure HTTPS credentials, because in the old world cryptographic identities aren't connected across applications.

[edit]

Enforced STARTTLS for SMTP?

Why hang on to E-Mail's "Simple Mail Transport Protocol" at all? Simple has a twofold meaning in SMTP:

  1. not simple at all, since so many things have been patchworked into it in the past decades;
  2. still far too simple to be safe from SPAM and secure for communication.

With SMTP servers still have a far too important role with cleartext access to at least all the addressing if not the content (see also Federation for a more profound criticism of such architectures), which is bad since they are prone to PRISM-like automated access. Modern communication systems like Pond or secushare do not give servers such a role.

As long as LEAP is backwards compatible to plain old unencrypted email we are unnecessarily risking downgrade attacks. Also we are exposing such an improved mail system to SPAM problems of the past. Also we maintain most of the problems listed in the n reasons for not starting to use PGP over e-mail. E-mail compatibility must at max go as far as IMAP or POP3 to our localhost onion router.

It is a fallacy to think we can maintain the existing social graph over e-mail and magically add encryption. This approach has failed for over a decade already. It is easier for people to accept that there is a new software that actually respects their constitutional right for Secrecy of Correspondence and that they need to re-establish secure links to each of their peers if they intend to use it.

People prefer Facebook mail anyway, so I presume they'll be fine with Pond, Retroshare mail or Susimail or whatever we come up with in the next weeks. The idea that backwards compatibility is an important priority could be completely wrong.

SMTP needs to be discontinued in the long run. It doesn't serve any of the purposes it was constructed for. It gives the attacker a full view of the social network, a view into the content by default, it also fails at handling SPAM and at delivering promptly to large numbers of recipients if not backed by cloud technology.

E-mail has a >25 years track record of not being reformable. It is just as essential to the Internet as FTP or TELNET. In 1991 FTP was the #1 protocol on the Internet, now that both HTTP and Bittorrent do a better job it exists only for aficionados. In 1993 it looked like SSH was the fringe paranoia technology from the free software extremists while all normal people were using telnet and rsh. Today you have to explain that there was something before SSH.

Facebook has been obsoleting millions of emails already. If it's not us taking SMTP to the grave, somebody like Facebook will.

Email has fundamental architectural flaws:

It is better to start from scratch and Facebook messaging is the proof for that. Although it only fixes the SPAM, the addressing, the DNS and the profile picture issue, those four are already enough to drive millions of people away from old-school e-mail into the arms of Facebook. Ever caught yourself writing a Facebook message to someone you could have sent e-mail to? Even old netheads catch themselves typing an old friend's name in Facebook rather than to dig out her email address (which has probably been discontinued).. and then you get to see the photo of her as you type.. email can't beat that.

We need a new mail system that fixes these issues instead of focusing on backwards compatibility.

[edit]

Meta-data resistant routing

LEAP has been promoting the idea that metadata can be protected while maintaining the existing federation architecture. Here are the proposed strategies:

[edit]

Auto-alias-pairs

Each party auto-negotiates aliases for communicating with each other. Behind the scenes, the client then invisibly uses these aliases for subsequent communication. The advantage is that this is backward compatible with existing routing. The disadvantage is that the user's server stores a list of their aliases. As an improvement, you could add the possibility of a third party service to maintain the alias map.

In practice the social graph is maintained exactly as is, only the addresses involved are camouflaged a bit. The 2009 paper "Deanonymizing Social Networks" shows how this kind of camouflaging can be automatically deanonymized, so let's better scrap this option and look at the next one.

[edit]

Onion-routing-headers

A message from user A to user B is encoded so that the "to" routing information only contains the name of B's server. When B's server receives the message, it decrypts a supplementary header that contains the actual user "B". Like aliases, this provides no benefit if both users are on the same server. As an improvement, the message could bounce around intermediary servers, like mixmaster.

The idea of doing the onion routing on top of SMTP instead of underneath it sounds like a neat and fancy hack at first, yet it has the disadvantage of giving SMTP servers more access to information than necessary. Also, how would they know they aren't just being used to forward SPAM?

Tor relays have a logic by which you cannot achieve anything useful if you don't play by the rules. Some goes for I2P, GNUnet and even RetroShare's turtle hopping. How can you enforce such a logic over e-mail if, at the same time, you have to be compatible to the past?

Not talking of the unnecessary loss in efficiency, cover traffic and ease of administration (one of the major advantages of the new communication systems is that "server" administration is trivial as they only have a job of relaying encrypted bits of data. By sticking to e-mail you lose that advantage).

I like onion routing, but I'd rather use a real public-key oriented routing system for it. Doing it on top of SMTP is not a reasonable proposal.

[edit]

Third-party-dropbox

To exchange messages, user A and user B negotiate a unique "dropbox" URL for depositing messages, potentially using a third party. To send a message, user A would post the message to the "dropbox". To receive a message, user B regularly polls this URL to see if there are new messages.

Dropboxes create dependency on specific servers, likelihood for them to become more popular than others (as it has always happened with federation – some servers get all the attention) and turning into honeypots for surveillance.

Here are two better options:

  • store data in a sybil-attack-resistant distributed hashtable such as GNUnet's;
  • store data on redundant relays, ideally already participating in a multicast distribution tree as in the case of secushare's pubsub trees.
[edit]

Mixmaster-with-signatures

Messages are bounced through a mixmaster-like set of anonymization relays and then finally delivered to the recipient's server. The user's client only displays the message if it is encrypted, has a valid signature, and the user has previously added the sender to a 'allow list' (perhaps automatically generated from the list of validated public keys).

Does the mixmaster decide itself where the things are sent to? This was okay in the past decade, but today this can mean that it just acts as if. There is a reason why the Tor program running on your computer chooses the entire onion route it will use by itself. It doesn't need to delegate trust to anyone else. Doing differently needs to have a scientific foundation to be trustworthy.

[edit]

LEAP's Architecture Comparison

Is available on https://leap.se/en/infosec - here are some notes.

GNUnet is a rather bad example for the P2P scores on this page since it comes with QR business cards, F2F mode, GNU Naming System and other things that LEAP apparently didn't take in consideration.

The table is missing an additional column called something like "P2P/F2F hybrid" for tools that combine Retroshare and Tor or GNUnet with PSYC. The difference to the "peer to peer" column would be:

  • Availability.. higher than high, because more than one node keeps the pending messages for you - which is technically better than a "home server" or a "drop box" in federation thinking.. also consider that "server"-like relay nodes are incentivized, so it isn't just nodes on some laptops. Thinking of "P2P" as being something slow and unreliable is not up to date with the state of technology.
  • Identity Security.. is solved better, thanks to strong cryptographic exchange options we talked about above. Authenticity and Unmappability are high and Usability is medium, since you still have to do a minimum effort for it - like printing business cards. Not very clear why LEAP has better Unmappability than generic P2P. Oh, in the new version the P2P column has disappeared from the last table.
  • Concerning User Freedom, Control can be the highest because only the intended recipients get *any* data - and if they participate in a distribution tree for your tweets they may not even see who else is in that tree (you can decide if the member list is viewable). In federation approaches at least the home server needs to know where to send things to, right?
  • Usability.. Tor is indeed difficult to use in a way that you don't expose your identity.. but that's because the web is in the ballgame. Again, Pond is a nice demonstration how Tor is a pretty safe technology if you don't use the web with it. Approaches like Retroshare or GNUnet's require you to actually write and promote a custom broken version of the software to damage yourself and others.
  • "Compatibility: None" - Actually since all data is on your own hard disk i think you have never been so in control of it and you can use any damn editor, file manager or photo manipulation software which is on your computer to interact with it - compatibility has thus never been so high. Reuse your own data anytime, post it to Facebook as you like, and most of all – don't put it at risk on any server.

Reasonable people may disagree? Yes. Adjust one or two cells? Underestimated.

[edit]

More?

There's more, probably. But time's up.

[edit]

Summary

The only motivation to look at LEAP is backwards compatibility. Should you be interested in privacy instead, you should better focus on #youbroketheinternet technologies.