Discussion of secure messaging protocols ()

elijah | 8 Sep 08:50 2014

key validation rules for today

The threads here on key validation have been quite productive, but many
of the new email projects have need for some actual rules we can
implement in the here and now [1]. Most of these projects plan to
implement some form of TOFU, but there are many ways this could be done
and many ways this could transition to better key validation in the future.

Here is a draft text for some basic rules to navigate this transition.

https://pad.riseup.net/p/key-validation

That link is live editable. Please comment, edit, deplore, or applaud as
you see fit. The full text is also included below for your convenience.

-elijah

[1] https://github.com/OpenTechFund/secure-email

---- begin ----

Transitional rules for automated key validation

Intro
===================================

Although many interesting key validation infrastructure schemes have
been recently proposed, it is not at all clear what someone writing
secure email software today should do. In particular, most of the new
opportunistic encrypted email projects have proposed starting with some
sort of Trust On First Use, but there are many ways to implement TOFU
and many ways TOFU can interact with whatever more advanced schemes are

(Continue reading)

headers

Daniel Thomas | 8 Sep 12:22 2014

Re: key validation rules for today

On 08/09/14 07:50, elijah wrote:
> Unless otherwise specified, "key" in this text always means "public key".

One general observation, something which is particularly annoying with
existing OpenPGP email signing/encrypting is the assumption that there
is a 'key' rather than that there are 'keys'. So when Enigmail recently
changed its defaults to 'encrypt where possible' I ended up with a bunch
of emails encrypted under only one of my keys and so had to wait until I
was in a different location to read them[0].

I think for key validation it is important to ensure that it says 'keys'
in all the appropriate places as in general users will likely have one
key per device (so that they fail independently) and several devices.
Does that seem sensible? The interaction between that and key transition
is subtle. Is it useful to distinguish between 'this is a new key,
signed by my old key which is now deprecated' and 'this is a new key,
signed by my old key which will keep on being used'?

Daniel

[0]: Eventually I had to turn off 'encryption where possible' as it just
annoyed both me and my correspondents.

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

(Continue reading)

headers

Daniel Kahn Gillmor | 8 Sep 15:38 2014

Re: key validation rules for today

On 09/08/2014 06:22 AM, Daniel Thomas wrote:
> I think for key validation it is important to ensure that it says 'keys'
> in all the appropriate places as in general users will likely have one
> key per device (so that they fail independently) and several devices.
> Does that seem sensible? 

With OpenPGP, you'd want to do this with subkeys -- so they're all part
of the same OpenPGP certificate.  However, it's only sensible for
signing keys.  for encryption keys, you really do need to share the key
across all of your devices. this is because when someone encrypts a
message to you, they need to know which key to encrypt to (and they'll
generally only pick one).

> The interaction between that and key transition is subtle. 

A subkey key transition is easy -- you add a new subkey, revoke the old
one, and publish the updated certificate to the keyservers.
Transitioning primary keys is more nuanced.

> Is it useful to distinguish between 'this is a new key,
> signed by my old key which is now deprecated' and 'this is a new key,
> signed by my old key which will keep on being used'?

The current way (in OpenPGP, when considering key transitions between
primary keys) to distinguish between these cases is to revoke the old
key.  There is even space in the key revocation packet to contain an
arbitrary message, in which you could put "superseded by key
0xDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF".  I don't think there's a
way (or that there should be a way) to indicate from the new primary key
itself that the old primary key should be deprecated.

(Continue reading)

headers

Daniel Thomas | 8 Sep 16:32 2014

Re: key validation rules for today

On 08/09/14 14:38, Daniel Kahn Gillmor wrote:
> On 09/08/2014 06:22 AM, Daniel Thomas wrote:
>> I think for key validation it is important to ensure that it says 'keys'
>> in all the appropriate places as in general users will likely have one
>> key per device (so that they fail independently) and several devices.
>> Does that seem sensible? 
> 
> With OpenPGP, you'd want to do this with subkeys -- so they're all part
> of the same OpenPGP certificate.

But then there is one primary key the failure of which breaks the lot? I
also wouldn't know how to go about doing that an while I could probably
work it out, I wouldn't want to have to teach my users how to do it, it
is hard enough already.

> However, it's only sensible for
> signing keys.  for encryption keys, you really do need to share the key
> across all of your devices.

But then you have to transmit private key material between various
systems which is finicky and hard to get right[0]. I much prefer systems
built by transmitting only public information and never moving private
information off the host it was generated on (modulo backups).

> This is because when someone encrypts a
> message to you, they need to know which key to encrypt to (and they'll
> generally only pick one).

I think this is the problem. They should encrypt to all valid ones.

(Continue reading)

headers

elijah | 8 Sep 20:00 2014

Re: key validation rules for today

On 09/08/2014 06:38 AM, Daniel Kahn Gillmor wrote:
> On 09/08/2014 06:22 AM, Daniel Thomas wrote:
>> I think for key validation it is important to ensure that it says 'keys'
>> in all the appropriate places as in general users will likely have one
>> key per device (so that they fail independently) and several devices.
>> Does that seem sensible? 
> 
> With OpenPGP, you'd want to do this with subkeys -- so they're all part
> of the same OpenPGP certificate.  However, it's only sensible for
> signing keys.  for encryption keys, you really do need to share the key
> across all of your devices. this is because when someone encrypts a
> message to you, they need to know which key to encrypt to (and they'll
> generally only pick one).

Yes, the document is hand wavy about how subkeys work. If you read far
enough down, there is a section at the bottom about future support for
device keys, by requiring a practice that a client should encrypt to all
encryption subkeys that match the uid.

Even support for this would be a problem, since the goal with device
keys is to not need to share anything, so really you need a mechanism to
support multiple primary keys. I wonder, can you have multiple signing
and encryption keys under a single master signing key, and then export
these subkeys to a device but not export the master key?

For the moment, however, the assumption is that the recipient has a
single encryption key for a particular uid, since that is current practice.

>> Is it useful to distinguish between 'this is a new key,
>> signed by my old key which is now deprecated' and 'this is a new key,

(Continue reading)

headers

Tom Ritter | 9 Sep 02:17 2014

Re: key validation rules for today

Hey elijah, this is cool.  I really like the way you broke down
categories and gave them names.  Some thoughts:

As you note, *-endorsement really falls down to *-trust if the
infrastructure is not set up to allow Bob to audit.  But *-trust can
be (manually) upgraded to *-endorsement if one keeps logs. If I record
the TLS session between me and provider (and all the keys and such) I
can show that as proof that either a) the provider had a rogue
certificate issued for them or B) they lied.  A service can still
claim they/someone were hacked, whether it's a CA that led to a key
lookup MITM or the infrastructure behind their endorsement key.

If you're going to enumerate nuances of key authenticity, I think
there's more. Some nuances that, to me, upgrade the authenticity of a
key.
 - If I receive the key over an anonymous channel vs a bound channel.
(e.g. Tor vs Internet)
 - If I receive the key over multiple Internet connections (Cellular &
Broadband)
 - If I receive a signed response from the user, using that key
 - If I receive a signed response from the user, using that key, from
a different provider (e.g. if I get an email from your riseup.net and
leap.se accounts on the same key using UIDs)
 - In the grand unified communication context: if I receive the same
key over another medium, e.g. OTR & Email
 - If I receive the same key from a user when they're on different
devices. (Of course, this is actually near-impossible to prove, so it
can't count for much.)

So I envision keys gaining trust over time. Key Managers improve trust

(Continue reading)

headers

Tim Bray | 9 Sep 18:05 2014

Re: key validation rules for today

On Mon, Sep 8, 2014 at 5:17 PM, Tom Ritter <tom <at> ritter.vg> wrote:

If you're going to enumerate nuances of key authenticity, I think
there's more. Some nuances that, to me, upgrade the authenticity of a
key.
- If I receive the key over an anonymous channel vs a bound channel.
(e.g. Tor vs Internet)

[since I’m the the guy who keeps bringing up the keybase approach]

- If there's a publicly-accessible tweet or github gist verifiably signed by the private key associated with the public key, and you’re pretty sure you know who controls those Twitter/github accounts.

[Trevor helped me with a message bounce and said this group hadn’t really kicked keybase around yet, so I’ll separately do a quick overview].

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tony Arcieri | 9 Sep 18:19 2014

Re: key validation rules for today

On Tue, Sep 9, 2014 at 9:05 AM, Tim Bray <tbray <at> textuality.com> wrote:

- If there's a publicly-accessible tweet or github gist verifiably signed by the private key associated with the public key, and you’re pretty sure you know who controls those Twitter/github accounts.

Or: just put your key fingerprint in your Twitter/Github bio.

--
Tony Arcieri

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

zaki@manian.org | 9 Sep 18:33 2014

Re: key validation rules for today

Keybase uses tweets and Gists instead of bios because they are timestamped unlike bios.

Linking in social media identities has the nice property of inheriting both reputation to an identity from the social network and making MITM attacks more difficult.

Keybase's client uses these machine readable certifications and a human in the loop judgement if the social media key certifications are out of sync with the key server. Mostly this is the case because the user failed to complete a certification properly.

An MITM attacker would need to compromise a target's KeyBase account and a target's social media accounts to effectively MITM a user using KeyBase .

On Tue, Sep 9, 2014 at 9:19 AM, Tony Arcieri <bascule <at> gmail.com> wrote:

On Tue, Sep 9, 2014 at 9:05 AM, Tim Bray <tbray <at> textuality.com> wrote:
- If there's a publicly-accessible tweet or github gist verifiably signed by the private key associated with the public key, and you’re pretty sure you know who controls those Twitter/github accounts.

Or: just put your key fingerprint in your Twitter/Github bio.

--
Tony Arcieri

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tony Arcieri | 9 Sep 18:43 2014

Re: key validation rules for today

On Tue, Sep 9, 2014 at 9:33 AM, zaki <at> manian.org <zaki <at> manian.org> wrote:

Keybase uses tweets and Gists instead of bios because they are timestamped unlike bios.

It also has the effect of driving you to the Keybase site to obtain fingerprints, as users are publishing signatures under an unknown key (which is weird and a bit gross)

--
Tony Arcieri

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Evan Johnson | 9 Sep 19:02 2014

Re: key validation rules for today

This may be slightly off topic to key validation, but imho the ugliest part of keybase is the URL paths. For example, I may have reigstered github.com/user1 and keybase.io/user1, but an attacker may control twitter.com/user1.

I believe many users will believe twitter.com/user1 == github.com/user1 . I was able to do a similar attack previously and impersonate one of the keybase founders.

On Tue, Sep 9, 2014 at 12:43 PM, Tony Arcieri <bascule <at> gmail.com> wrote:

On Tue, Sep 9, 2014 at 9:33 AM, zaki <at> manian.org <zaki <at> manian.org> wrote:
Keybase uses tweets and Gists instead of bios because they are timestamped unlike bios.

It also has the effect of driving you to the Keybase site to obtain fingerprints, as users are publishing signatures under an unknown key (which is weird and a bit gross)

--
Tony Arcieri

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Daniel Kahn Gillmor | 9 Sep 18:35 2014

twitter and github as key validators [was: Re: key validation rules for today]

On 09/09/2014 12:19 PM, Tony Arcieri wrote:
> On Tue, Sep 9, 2014 at 9:05 AM, Tim Bray <tbray <at> textuality.com> wrote:
> 
>> - If there's a publicly-accessible tweet or github gist verifiably signed
>> by the private key associated with the public key, and you’re pretty sure
>> you know who controls those Twitter/github accounts.
> 
> Or: just put your key fingerprint in your Twitter/Github bio.

I'm afraid i don't understand the argument here.  What is the use case here?

 0) something is published on twitter account "foo" and i want to know
to whom to attribute authorship.

 1) i regularly communicate with "foo" on twitter, and i want to know
how to communicate with the author in other communications channels.

I think the proposed publications only (marginally) addresses use case
(1) above, and fails utterly at use case (0).

This fails use case (0) because it's easy enough for me to create a
twitter account and put someone else's fingerprint in the new bio, and
to republish an arbitrary signed tweet.

If this somehow establishes that tweets from "foo" are from the person
i've targeted, then framing this person is trivially easy.

it partially fails at (1) as well, mainly because you're now relying on
the administrators of twitter and github to act as certificate
authorities, which is a role that they have not signed up to do at all,
and may not even have considered.  If you think that the weakest link in
the CA cartel probably has bad internal controls, do you think they're
actually worse than those of twitter and/or github?

As a piece of corroborative evidence, considered thoughtfully, twitter
and github are surely useful.  As a mechanism for solo key validation,
it seems weak to me.

	--dkg

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tim Bray | 9 Sep 18:48 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

On Tue, Sep 9, 2014 at 9:35 AM, Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> wrote:

I'm afraid i don't understand the argument here. What is the use case here?

0) something is published on twitter account "foo" and i want to know
to whom to attribute authorship.

1) i regularly communicate with "foo" on twitter, and i want to know
how to communicate with the author in other communications channels.

2) You want to communicate with me, Tim Bray, and go looking for a key for me. You discover that there is a directory of keys, and you can retrieve a public key from it, and the corresponding private key has been used to sign a time-stamped tweet from <at> timbray and gist from github/timbray and an assertion at tbray.org, and because you know who I am on Twitter and github and what my personal domain is, and you can check the signatures, you are prepared to believe that that public key is appropriate for communication with me.

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Ruben Pollan | 9 Sep 22:00 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

Quoting Tim Bray (2014-09-09 11:48:10)
> On Tue, Sep 9, 2014 at 9:35 AM, Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
> wrote:
>  
> 
> 
>     I'm afraid i don't understand the argument here.  What is the use case
>     here?
> 
>      0) something is published on twitter account "foo" and i want to know
>     to whom to attribute authorship.
> 
>      1) i regularly communicate with "foo" on twitter, and i want to know
>     how to communicate with the author in other communications channels.
> 
> 
> 2) You want to communicate with me, Tim Bray, and go looking for a key for me.
>  You discover that there is a directory of keys, and you can retrieve a public
> key from it, and the corresponding private key has been used to sign a
> time-stamped tweet from  <at> timbray and gist from github/timbray and an assertion
> at tbray.org, and because you know who I am on Twitter and github and what my
> personal domain is, and you can check the signatures, you are prepared to
> believe that that public key is appropriate for communication with me.

Yes, but I don't have any way to audit twitter or github. As dkg is mentioning 
in his email you are putting them in the role of a CA without their consent.

--

-- 
Ruben Pollan  | http://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: http://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tim Bray | 9 Sep 22:40 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

On Tue, Sep 9, 2014 at 1:00 PM, Ruben Pollan <meskio <at> sindominio.net> wrote:

> 2) You want to communicate with me, Tim Bray, and go looking for a key for me.
> You discover that there is a directory of keys, and you can retrieve a public
> key from it, and the corresponding private key has been used to sign a
> time-stamped tweet from <at> timbray and gist from github/timbray and an assertion
> at tbray.org, and because you know who I am on Twitter and github and what my
> personal domain is, and you can check the signatures, you are prepared to
> believe that that public key is appropriate for communication with me.

Yes, but I don't have any way to audit twitter or github. As dkg is mentioning
in his email you are putting them in the role of a CA without their consent.

The role of a CA?!? Not in the slightest. You are piggybacking on their authent system using public-facing well-documented interfaces. Confidence in key ownership isn’t absolute, it’s statistical. “Here is some evidence, you can choose whether or not to be convinced.” For my purposes, tying a key to the ownership of this sort of public-facing account is practical and useful evidence. The nice thing about the system is that you don’t have to trust the directory in the slightest, and you really only have to trust the proof statements in aggregate.

I haven’t made up my mind about the actual keybase.io project yet (among other things it’s unclear what they want to be) but the directory-that-you-look-evidence-up-in-but-don’t-have-to-trust feels like the only credible new thing in key discovery I’ve seen in a loooooong time.

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Daniel Kahn Gillmor | 9 Sep 23:18 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

On 09/09/2014 04:40 PM, Tim Bray wrote:
> the
> directory-that-you-look-evidence-up-in-but-don’t-have-to-trust feels like
> the only credible new thing in key discovery I’ve seen in a loooooong time.

The OpenPGP keyserver network has been offering
directory-that-you-look-evidence-up-in-but-don’t-have-to-trust for many
years now.

I'm not convinced that's what is novel about keybase.io, but i do think
it's tricky to put your finger on what exactly keybase.io is offering
that people find appealing.

This makes me think we need to investigate it more critically.

	--dkg

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tony Arcieri | 9 Sep 23:35 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

On Tue, Sep 9, 2014 at 2:18 PM, Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> wrote:

I'm not convinced that's what is novel about keybase.io, but i do think
it's tricky to put your finger on what exactly keybase.io is offering
that people find appealing.

I'm confused as well. Perhaps it's simply their visual design.

I think Keybase is in some sort of uncanny valley where it makes the PGP experience prettier but not necessarily that much easier, especially for novice users. As soon as you ask people to download and install a command-line utility you've just lost most of the human population.

That said, the UX of existing keyservers is horrendous. For technical users, I think Keybase does improve aspects of keyserver UX.

This is, again, why I'm more excited about systems in which a user's service provider publishes keys on their behalf, provided there are checks in place to help people detect if the key directory is being dishonest about their key. These systems seem like they can be mostly transparent for your average, non-technical user, which is the main thing I think is needed right now.

--
Tony Arcieri

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tim Bray | 10 Sep 00:00 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

Well, you mentioned UX; by coincidence, that’s what I’m working on. I’m doing some work on OpenKeychain, a key/crypto manager app for Android. I’m adding a “cloud search” tab that searches the existing keyserver network and Keybase, in parallel. If I search for “Tim Bray” I get https://www.tbray.org/tmp/tb-keys.png - two of the keys are from keyservers, one from Keybase. Not all are for me.

Maybe more interesting, if I check for “Dominik Schürmann” I get https://www.tbray.org/tmp/ds-keys.png - it’s searched both sides, found the same key in both places, and merged the ancillary information.

This isn’t quite released yet: My next work is to allow the Android user to double-check the proofs.

I hasten to add: We’re making this up as we go along. If you think you see something terribly wrong, you probably do.

Also: To anyone curious about keybase, I have tons of invites.

On Tue, Sep 9, 2014 at 2:35 PM, Tony Arcieri <bascule <at> gmail.com> wrote:

On Tue, Sep 9, 2014 at 2:18 PM, Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> wrote:
I'm not convinced that's what is novel about keybase.io, but i do think
it's tricky to put your finger on what exactly keybase.io is offering
that people find appealing.

I'm confused as well. Perhaps it's simply their visual design.

I think Keybase is in some sort of uncanny valley where it makes the PGP experience prettier but not necessarily that much easier, especially for novice users. As soon as you ask people to download and install a command-line utility you've just lost most of the human population.

That said, the UX of existing keyservers is horrendous. For technical users, I think Keybase does improve aspects of keyserver UX.

This is, again, why I'm more excited about systems in which a user's service provider publishes keys on their behalf, provided there are checks in place to help people detect if the key directory is being dishonest about their key. These systems seem like they can be mostly transparent for your average, non-technical user, which is the main thing I think is needed right now.

--
Tony Arcieri

- Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tony Arcieri | 9 Sep 22:09 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

On Tue, Sep 9, 2014 at 9:35 AM, Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> wrote:

1) i regularly communicate with "foo" on twitter, and i want to know
how to communicate with the author in other communications channels.

I think the proposed publications only (marginally) addresses use case
(1)

If you have your key fingerprint published through many channels, someone concerned with actually verifying your key fingerprint can check them all to ensure they match. If there's a discrepancy, something is probably amiss.

Perhaps an attacker managed to compromise them all and update your key fingerprints in all locations to confuse a victim into sending the attacker an encrypted message. Sure, it's not a great solution. It's an OK solution, however. Certainly better (from a security, not usability perspective) than TOFU.

Short of things like Google's proposed CT-alike for E2E looking for dishonest Key Directories, I'm not sure how you do better.

--
Tony Arcieri

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tao Effect | 9 Sep 23:09 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

On Sep 9, 2014, at 1:09 PM, Tony Arcieri <bascule <at> gmail.com> wrote:

If you have your key fingerprint published through many channels, someone concerned with actually verifying your key fingerprint can check them all to ensure they match. If there's a discrepancy, something is probably amiss.

Perhaps an attacker managed to compromise them all and update your key fingerprints in all locations to confuse a victim into sending the attacker an encrypted message. Sure, it's not a great solution. It's an OK solution, however. Certainly better (from a security, not usability perspective) than TOFU.

I think it's important to remind us who we're dealing with.

The fact that Keybase lookups are done over HTTPS eliminates most malicious actors.

If Keybase pins their cert (do they?), that virtually guarantees the validity of the github and twitter URLs.

The lookup would proceed to those services, to which the keys are not pinned, so the scope widens a bit again, just enough to include the Five Eyes, the host companies themselves (twitter and github), and anyone who hacked them.

What are the capabilities of the Five Eyes?

I think many would agree they are capable of manipulating and/or censoring connections (HTTPS or not) in an automated fashion, but with some difficulty (and non-zero possibility of detection). That implies that most keys returned from Keybase would be accurate, but for a small fraction they might not be.

I'd summarize the quality of service Keybase provides like so:

- For 99% of cases, it does a great job.

- For maybe <1%, it could provide false answers.

- There is the possibility of DoS / censorship (given that it is a centralized service) for everyone.

Short of things like Google's proposed CT-alike for E2E looking for dishonest Key Directories, I'm not sure how you do better.

OpenBazaar has plans to do public key lookups for pseudonyms in Namecoin via DNSChain:

https://github.com/OpenBazaar/OpenBazaar/issues/487

That has the advantage of virtually guaranteeing correct responses, and the decentralized nature makes it mostly invulnerable to DoS and censorship.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tao Effect | 9 Sep 23:14 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

On Sep 9, 2014, at 2:09 PM, Tao Effect <contact <at> taoeffect.com> wrote:

The lookup would proceed to those services, to which the keys are not pinned, so the scope widens a bit again, just enough to include the Five Eyes, the host companies themselves (twitter and github), and anyone who hacked them.

[..]

- For maybe <1%, it could provide false answers.

Oops, correction: if keybase pins their cert (and it's not compromised), then it would be able to detect false answers from twitter and github (even if they were compromised).

The downside of a centralized service, however, is that it then becomes a single point of failure, and the incentive for malicious entities to attack it becomes greater.

Please do not email me anything that you are not comfortable also sharing with the NSA.

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging

headers

Tobias Mueller | 9 Sep 23:25 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

Hi.

On Tue, Sep 09, 2014 at 01:09:17PM -0700, Tony Arcieri wrote:
> If you have your key fingerprint published through many channels, someone
> concerned with actually verifying your key fingerprint can check them all
> to ensure they match. If there's a discrepancy, something is probably amiss.
> 
What is missing, for me at least, in this statement is that the very same channel
is used.  Namely the Web via your Web browser.  I consider this channel to be
easily attackable plus the attack to subvert the proposed verification algorithm
easily mountable.  It's a mere 's/old_fingerprint/corrupted_fp/g' operation.

You might not have that attacker or threat model in mind when assessing the
security of the proposed scheme.  Some others do.  Those people, as it has already
been written, wouldn't want to depend solely on that scheme to verify keys.

Cheers,
  Tobi

headers

Daniel Kahn Gillmor | 9 Sep 23:29 2014

Re: twitter and github as key validators [was: Re: key validation rules for today]

On 09/09/2014 04:09 PM, Tony Arcieri wrote:
> If you have your key fingerprint published through many channels, someone
> concerned with actually verifying your key fingerprint can check them all
> to ensure they match. If there's a discrepancy, something is probably amiss.

it looks like https://twitter.com/dkg and https://github.com/dkg do not
publish the same information.  So, something is probably amiss.  What
should a user do with this information?

What if https://twitter.com/dkgillmor and https://github.com/dkgillmor
both offer the same key as each other, and their respective
contributions to the public discourse seem like the contributions that i
tend to make?  now do you believe the choice of key material published
by those accounts?

(note how easy it is to clone someone's public github repos; note also
how easy it is to replay someone's twitter feed into a new account; and
this is an impersonation attack i can do *without* being a twitter or
github administrator)

> Perhaps an attacker managed to compromise them all and update your key
> fingerprints in all locations to confuse a victim into sending the attacker
> an encrypted message. Sure, it's not a great solution. It's an OK solution,
> however. Certainly better (from a security, not usability perspective) than
> TOFU.

I agree it seems better than nothing and (probably) better than TOFU.
I'm just not sure what we're doing with it, and whether it helps us to
identify the actual people behind the different communications channels,
or whether it makes those different communications channels more
important, and the actual people less important.

> Short of things like Google's proposed CT-alike for E2E looking for
> dishonest Key Directories, I'm not sure how you do better.

So i think what you're getting at here is auditability, which is a
useful thing, particularly when coupled with the ability to act
effectively on detected malfeasance.  I still haven't read the google
E2E proposal, so i probably need to go do that.

	--dkg

_______________________________________________
Messaging mailing list
Messaging <at> moderncrypto.org
https://moderncrypto.org/mailman/listinfo/messaging