RFE: Trust on first contact opportunistic GPG about mailpile HOT 13 CLOSED

On 4 August 2013 14:07, Stephanie Daugherty [email protected] wrote:

Several of the GPG developers have discussed the possibility of
opportunistic GPG encryption and message signing on a "trust on first
contact" model, similar to that of SSH. (article here:
http://lwn.net/Articles/464137/)., whereby the public key for email
correspondents would be automatically retrieved and imported, and given somet.
indication of "marginal" trust (and assurance that the key can't be changed
without you knowing once you begin corresponding with someone).

Despite the obvious security weakness, in the form of one-time
vulnerability to man in the middle attacks, this strategy overcomes a
serious usability weakness for a net gain in security in most real-world
circumstances. Noting the benefits and limitations, this should obviously be
a supplement to traditional rigorous GPG verification and key management
practices , with clear indications as to the level of identity assurance in
the user interface.

I think Mailpile could be a good place to experiment with this strategy,
since a web based interface can be easily tailored to display necessary
trust information and security warnings in an intuitive way, and can
automate the necessary GPG functions to automatically track keys.

Good idea. Also having a web page to cut and paste signatures you
trust, and have mailpile automatically match them up with keys it has.
E.g. Someone has txt or has on their web page a copy of the key
signature in hex numbers.
Being able to cut and paste that signature into mailpile would make it
easier to build up the trust list.

from mailpile.

Excellent ideas, agree 110% that we need a less laborious trust model for wide adoption.

What about including your public key in emails, as an attachment perhaps, or using some mechanism where it won't be an ugly pile of ascii?

This way, you can email someone you already know (low chance of MiM), include your public key, and they can respond to you with an encrypted message, including their public key.

From that point forward, even if one of you loses control of your account, the intruder has no access to the private key, and cannot spoof authenticated messages from the compromised account.

from mailpile.

Is there a usable way to make fingerprint verification easier?

Trust on first contact is really great but can be further enhanced by making it very easy to verify fingerprints over secondary channels.

OTR uses a question&answer scheme, which is quite interesting (whats the bar we went to last night?)

I guess representing a fingerprint as a combination of colors/shapes (which probably cant convey the fingerprint fully but makes it easy to spot shoddy MitM attacks non-the-less) which can then be verified on a different channel.

Oh the possibilities :)

from mailpile.

Pubkeys can already be transferred in more ways than attaching it to a mail or uploading to a keyserver.

• There are at least three ways to distribute them via the DNS
• You can set a special header OpenPGP: url=http://domain.tld/pubkey.asc (Enigmail can do that, take a look at the advanced settings). You just need a hoster that you can upload your key to and hotlink the file, plus you have to keep the file updated if you gather more signatures.
• There are some even more obscure ways like LDAP, but they probably do not play well with an open infrastructure like the internet while preserving a decentralized model.

More ways to verify: I personally dislike QR codes, but this would probably be something where they may actually be useful. The problem is that the intersection of the set of devices that run mailpile and the set of devices with a camera that could scan QR codes is pretty small. But if it was adopted, you could just print your Fingerprint as a QR-Code onto your business cards.

Other than that, one could adopt something akin to SSH randomArt for weak verification. The problem is, as always, to get everyone else (Enigmail, gpgtools, and so on) to adopt the technique as well to make adoption easier.

I also like RedPhone's method for MitM detection: Both parties of the call get a two-word phrase, (probably) determined by the used session keys, which they can compare. If it is the same, they can be sure no one is actively MitM'ing them (I am not sure about the algorithms used, but I assume they use something like diffie-hellmann, where is is really hard to achieve an identical session key for both sides as an MitM). This technique is sadly not really fit for use with eMails, but I like the idea and wanted to throw it out there so someone else may have a cool idea with that.

from mailpile.

re QR codes: they have the advantage that as an image format, they are accepted and understood everywhere -- on websites, as attachments, etc. You can even play with them to include rudimentary icons and graphic overlays.

As to the issue of cameras, I hope Mailpile becomes more than a desktop mail client -- it will have to go mobile to be anything close to truly popular. But even on an old, camera-less desktop, saving a QR .png file and importing it into Mailpile by hand will be infinitely easier for casual users than doing the same thing with some obscure filetype that has no visual representation and is not understood by the operating system, browser, or other applications that may be called upon to handle them.

TL; DR: +1 for QR codes

from mailpile.

+1 for opportunistic encryption.

As soon as the parties have verified each others keys, Mailpile should make it easy to publish that information to the web-of-trust. That way we have a lower entry barrier and security gets better over time.

from mailpile.

@mjowe The web of trust is a multi-edged blade. It's one of the least bad systems we currently have for verifying the authenticity of keys which haven't been checked in person, but it's not actually all that good. It takes a lot of work to verify keys and publish certifications; few enough folks do that work that -- in many cases -- the web isn't much use at all.
On the other hand, the web of trust is a great way to distribute non-repudiable social network information, including which groups of people met when, and with a little more context, often where (at which conference &c.). That kinda sucks. I know that if any other supposedly privacy-centric mail client was constantly publishing my closest contacts online, I might be a smidge peeved.
I think that it would be prudent to reflect on whether the upsides to this actually outweigh the downsides. Are there better approaches? There are well-documented procedures which activists groups use to keep their social-network info private while still sharing certifications among themselves. That sort of thing is quite labor intensive to do manually, but might be much easier if Mailpile automated the fiddly and tiresome parts.

from mailpile.

You really need both. Opportunistic encryption gets the ball rolling with
"better than nothing" security and crucially, gets you something usable to
build usage of encryption up until it reaches a critical mass where you can
start to develop a web of trust.

On Thu, Sep 26, 2013 at 11:25 AM, Tom Lowenthal [email protected]:

@mjowe https://github.com/mjowe The web of trust is a multi-edged
blade. It's one of the least bad systems we currently have for verifying
the authenticity of keys which haven't been checked in person, but it's not
actually all that good. It takes a lot of work to verify keys and publish
certifications; few enough folks do that work that -- in many cases -- the
web isn't much use at all.
On the other hand, the web of trust is a great way to distribute
non-repudiable social network information, including which groups of people
met when, and with a little more context, often where (at which conference
&c.). That kinda sucks. I know that if any other supposedly privacy-centric
mail client was constantly publishing my closest contacts online, I might
be a smidge peeved.
I think that it would be prudent to reflect on whether the upsides to this
actually outweigh the downsides. Are there better approaches? There are
well-documented procedures which activists groups use to keep their
social-network info private while still sharing certifications among
themselves. That sort of thing is quite labor intensive to do manually, but
might be much easier if Mailpile automated the fiddly and tiresome parts.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-25176834
.

from mailpile.

The privacy concerns about the public nature of the PGP web of trust were one of the things we discussed in our first-pass threat-model and security review with Eleanor Saitta (Dymaxion) last week. It is definitely the case that at-risk people are targeted due to meta-data about their social network alone and leaking such information is not to be done lightly.

Eleanor's recommendation was that we ignore the web of trust entirely for this reason and look at some sort of TOFU (trust upon first use) model, augmented with easy-to-explain/understand/use-correctly manual key verification.

We haven't yet finalized any of these things, but I wanted to speak up and confirm that they are on our radar and we are thinking about them.

from mailpile.

Absolutely in favor of this plan. Thank you for recognizing that public webs of trust leak social data, and that expansion of their use may be detrimental to privacy.

Fortunately, TOFU is already tried and accepted in other domains. The implementation of pidgin-otr 3.0 is effectively TOFU, with an option to authenticate via Socialist Millionaire Protocol (SMP) or manual fingerprint verification. SMP could work as a mailpile authentication feature as well.

from mailpile.

Have you seen this?
https://datatracker.ietf.org/wg/dane/

Interesting post here, regarding the way keyservers / WOT can be abused.
http://cryptome.org/2013/07/mining-pgp-keyservers.htm

from mailpile.

Relates to #733

from mailpile.

This is now part of our security roadmap: https://github.com/mailpile/Mailpile/wiki/Security-roadmap

from mailpile.