search

keybase / keybase-issues

A single repo for managing publicly recognized issues with the keybase client, installer, and website.
902 stars 37 forks source link

[Off-Topic] One-Way Verifications #979

Closed tinloaf closed 9 years ago

tinloaf commented 9 years ago

Hi,

I'd like to ask you to consider adding one-way verifications. What I mean is this: The current setup establishes two-way cryptographic ties between a keybase.io account and several other accounts / websites / whatever. With this, everyone can make reasonably sure that a certain PGP key belongs to a certain person.

Now it would be awesome if we could use this PGP key to verify more identities, where public proof is not so easy, say for example jabber IDs. I cannot publicly prove that I have access to a certain jabber ID, but I can sign the statement "if someone from foo@bar.com contacts you via jabber, you may assume that it's me" with my PGP key. Thus, people who track my keybase account can then also start to trust this jabber ID.

Did you ever consider something like this? If so, and you decided against it, then, if I may ask, why?

tinloaf commented 9 years ago

Come to think about it: You are already allowing this with bitcoin addresses. Why not other things?

ghost commented 9 years ago

Jabber for example has already been suggested and is on the list #518. Downside of one way verifications is that one can claim to own a specific account but didn't actually proved it. It would make it easier to fake identities on keybase itself...

tinloaf commented 9 years ago

Yes, obviously these one-way verified accounts may not be used to prove your identity on keybase, just the other way round. In other words: No one should trust your keybase account just because this account claims to have a bitcoin address that is yours. But if someone trusts your keybase account, he may trust that the bitcoin address listed there (and signed with the PGP key) is truly yours.

tinloaf commented 9 years ago

@dtiersch: I know about #518, btw. This should not become another collect-services-issue. But as far as I could tell, lots of the services in #518 are not getting in because one-way verification is not desired. Thus this issue, to discuss it. ;)

ghost commented 9 years ago

:thumbsdown:

The most important differentiation between Keybase and previous WoT-style systems is the two-way, independently, and externally verifiable proofs. Mixing those with one-way assertions weakens the system.

Most users - assuming us nerds become the minority - aren't going to understand the distinction between strong assertions and weak assertions. Warnings and disclaimers don't help much. True, most users will trust Keybase.io implicitly; most won't verify independently. But two-way proofs enable independent monitors and watchdogs. A two-way proof is easily check because of maths. A one-way signing lacks this property, making verification more difficult and expensive at scale (again, thinking of external watchdogs).

That Keybase set the precedent with Bitcoin doesn't mean it's good. I oppose the one-way Bitcoin assertion for the same reasons.

lorenzhs commented 9 years ago

You don't need to trust keybase.io to verify a signed statement claiming that the author can receive messages with the ID xyz. You can just as well not trust any other proof because a friend might have forgot to log out of their reddit account on my machine, and I could have abused that to "verify" their account.

Also, let's face it, in any system involving PGP, nerds are most likely going to be in the majority. PGP hasn't evolved a bit from the usability ideas of the 90s.

ghost commented 9 years ago

You don't need to trust keybase.io…

I don't.

You can just as well not trust any other proof because a friend might have forgot to log out of their reddit account on my machine…

I'd rather reduce the attack to human-error/social-engineering than inherent technical weakness in the system.

I prefer a system that requires a mistake like you describe versus one where anyone can make a difficult-to-verify, easy-to-fake assertion about ownership which keybase.io and the Keybase client aid in promoting as authentic.

Keybase can do better than acting as a clearinghouse of signed one-way assertions. This is demonstrated by every other Keybase proof aside from the Bitcoin address.

nerds are most likely going to be in the majority

Keybase has a goal to bring usable crypto to the masses. Either:

The last bullet is the least interesting to me, but even that is still interesting. The WoT model is difficult enough that even nerds get it wrong. Even if your conjecture is true, the implication that nerds don't need more usability is almost certainly false.

PGP hasn't evolved a bit from the usability ideas of the 90s.

By substantially improving the usability of key distribution, Keybase.io in alpha disproves that statement.

The features available on keybase.io when you trust it with your private key (arguably a bad idea: #901) may already have better usability than current PGP clients.

lorenzhs commented 9 years ago

Because this message wasn't really on topic and very long, I moved it to a gist instead: https://gist.github.com/lorenzhs/53314759cd5a62326444

ghost commented 9 years ago

But what I really want to talk about is the usability of PGP…[t]here are a number of issues…

My conclusion is that the issues with PGP are too numerous and the system too complex for it to ever succeed amongst non-nerds.

Creating (at least one) issue dedicated to that would serve you better. Limiting the cyphersuite warrants a dedicated issue for sure.

Your points are orthogonal to this issue of One-Way Verifications. Given a hypothetical much better PK crypto system that has desirable properties such as excellent UX, native app integration, modern cyphers, perfect forward secrecy, etc. I would still object to Keybase.io endorsements of one-way assertions.

Take the example of Jabber. How do you suggest to implement a two-way proof?

I don't have a suggestion. Nor is it a failure if users cannot consolidate all their identities on their Keybase profile. On the contrary, it's a failure if the Keybase profile includes one-way proofs.

It's better to omit XMPP usernames until a two-way proof is invented. Whether that be with XEP or something novel doesn't matter much.

lorenzhs commented 9 years ago

I agree that this discussion has wandered off topic. My ciphersuite concerns were not directed at Keybase, but at PGP implementations like GnuPG, thus creating an issue for that here wouldn't help. I don't know how Keybase behaves in this regard.

I disagree strongly on your other point. While I agree that the current presentation of one-way proofs is not perfect (it is presented in the middle of the other, two-way, proofs, lacking clear distinction), I do think that being able to claim ownership of accounts would add security (esp when combining XMPP with OTR fingerprints)

Requiring something new to be built for such verifications is not viable, as it will have to be implemented everywhere before it can be effective, and Keybase just doesn't have the reach that is required to get this done. Therefore, I support @tinloaf in allowing more general one-way claims.

tinloaf commented 9 years ago

I am fully aware (as I wrote in my original posting) that using one-way proofs as verifications for the keybase account would be stupid, and therefore this has to be mitigated visually somehow. Heck, let's not display those on the profile page at all.

I know it's always annoying for some stranger to walk up to you and tell you what the vision of your project should be, so let me tell you what I thought the vision of keybase was:

Now, if some piece of software tries to communicate with a piece of software (TextSecure, Threema, OTR, https-enabled webserver, ...) that claims to belong to Jon Doe, heres what happens:

I started this ticket because when I tried to convince some of my (nerd) friends to use keybase, I could not make them see why it would be useful. Honestly, no one cares if he can validate my reddit account. What people would care about would be if they could verify the authenticity of their one-to-one communication (Instant Messengers, https with the servers of friends, etc.) with this.

Thanks for the great project. I'm hoping that over time it will become the even greater project I imagined. ;)

ghost commented 9 years ago

When we build systems that give users a choice between doing the right thing and the wrong thing, some of the time, perhaps most of the time, our users will do the wrong thing:

The solutions aren't user education, warnings & disclaimers, segregating bad choices from good choices, or UX obstacle courses in front of bad choices. The solution is to design our systems so that users always do the right thing. We abolish certificate warnings. We use HTTPS everywhere, always, and from the start.

Similarly, Keybase.io and Keybase client should only ever present strong, two-way proven identities. Then users are only ever doing the right thing: trusting a strong, easily verifiable claim.

This simplifies Keybase UX. No disclaimers needed. No warnings. No need to design a UI that segregates two-way proofs from one-way assertions; no need to explain that segregation.

ghost commented 9 years ago

Keybase.io provides some kind of public API to get to those signed statements

This makes Keybase a central authority for one-way claims, which smells wrong to me. It's a single point of failure; a single authority to attack or commandeer.

Two-way proofs are more resilient. Subverting my claim to @toolbear on GitHub is two times as hard; you have to control Keybase.io and gist.github.com. Subverting my entire online identity (as consolidated on Keybase) is N-times as hard. Those are some nice properties when compared to the state of SSL Certificate Authorities, for instance.

I feel the same compulsion as you to provide this feature. It's how @maxtaco and @malgorithms justified adding Bitcoin address in the first place. What's the difference between me keeping a canned, signed "my bitcoin address is ___" which I send to anyone who asks versus Keybase hosting the claim? If there isn't much difference, then it certainly is a convenient feature to have.

The distinction between facilitating the exchange of a claim versus displaying a claim is significant. It's significant even if regular users don't recognize the distinction. Centralization is part of it. The notion of endorsement is another. The conflation of weak-claims with strong proofs is another.

lorenzhs commented 9 years ago

@toolbear Don't forget that subverting your claim also requires possession of your private key. Therefore, the worst case scenario is that you get an unusable (or no) proof from Keybase, and that is the status quo.

There isn't much of a difference between you sending the canned signed statement and Keybase hosting it for you. You could just as well append it to your Keybase http(s) proof and host it yourself. (That could actually be a pretty nice idea, self-hosting one-way proofs on a two-way proven domain, now we just need support for that in the CLI)

tinloaf commented 9 years ago

This makes Keybase a central authority for one-way claims, which smells wrong to me. It's a single point of failure; a single authority to attack or commandeer.

Failure as in "authentication might not succeed", yes. That's also the case when keybase is just DDoSed from the net. Failure as in "bad guy taking over keybase and impersonating Threema users", no. The stuff is signed, keybase just hosts the proof.

Two-way proofs are more resilient. Subverting my claim to @toolbear on GitHub is two times as hard;

"Subverting" as in "erasing it from the net"? Sure. So let's just clone keybase.io to keystore.io, and suddenly, to erase a one-way proof from the net, you have to control 2 sites, too. Heck, just mirror the archive of proofs as a torrent or whatever.

"Subverting" as in "forging"? Nope. In both cases ("one-way" and "two-way") someone would need to gain access to your private key.

The distinction between facilitating the exchange of a claim versus displaying a claim is significant.

That's why I said "let's not display the one-way proofs on the profile page" in my previous post.

The conflation of weak-claims with strong proofs is another.

A PGP signed statement "The holder of this PGP key wants to receive TextSecure messages encrypted with key X" is in no way a "weak claim". It's a cryptographic proof.

ghost commented 9 years ago

Don't forget that subverting your claim also requires possession of your private key — @lorenzhs

  • I'm your mother. I ignored your advice. I uploaded my private key to Keybase.io. I traded some security in exchange for better usability and more convenience. Given the choice, it was a totally reasonable decision for a normal person to make.
  • Keybase has been commandeered by the US government.
  • The surveillance apparatus introduced a backdoor, weakened the client-side crypto, or ran highly probable to succeed dictionary attacks against the collected private keys.

Result: at least one other actor has your mom's private key and its passphrase.

__Channels Louis CK\ Of course, of course this is crazy. Of course, of course this is slightly paranoid speculation. Of course it's a bit tinfoil hat-y, a bit cranky. But maybe…maybe…we haven't been cranky enough :hushed:

There isn't much of a difference between you sending the canned signed statement and Keybase hosting it for you [emphasis added]

Correct.

But my instincts tell me that the subtle difference is an important one.

Failure as in "authentication might not succeed", yes. That's also the case when keybase is just DDoSed from the net. Failure as in "bad guy taking over keybase and impersonating Threema users", no. The stuff is signed, keybase just hosts the proof. — @tinloaf

I'd rather have a system resistant to all those failures.

Making Keybase a central authority triggers my Centralization == bad heuristic. I'm pragmatic, so usability and convenience dictate some centralization. I get the motivation behind #162 in advocating for federation while also being sympathetic to Keybase.io making tradeoffs and centralizing some things.

I conclude that it's prudent to question/resist centralization; to try harder to invent usable, decentralized things.

But also…

Failure as in "bad guy taking over keybase and impersonating Threema users", no. The stuff is signed, keybase just hosts the proof.

Bad actor who takes over Keybase eventually has the information to start making signed statements on users' behalf. This includes signing false one-way claims and then making those false claims part of users' Keybase profiles (or wherever the home for such claims are).

So let's just clone keybase.io to keystore.io, and suddenly, to erase a one-way proof from the net, you have to control 2 sites, too. Heck, just mirror the archive of proofs as a torrent or whatever.

Yes. Something like that.

But it isn't so simple. Your suggestion, taken at face value, seems to share one of the problems with the SSL Certificate Authority system by introducing many trusted roots. What happens if they disagree? When the root I trust is compromised? How do we tell legitimate changes from nefarious ones: "yay, I finally claimed the inactive @toolbear on Twitter" versus "boo, @toolbear hacked my Keybase account and made everyone think I'd switched Twitter names"?

But yes. Something like that. The antidote to centralization is decentralization.

Concretely, mirroring Keybase's signed statements for those two-way proofs where I can't host the entire proof in the 3rd party service (tweet sized hash, HN >= 2 karma hash) would benefit greatly from a mirroring scheme.

Which remind me…two-way proofs are decentralized :satisfied:

The distinction between facilitating the exchange of a claim versus displaying a claim is significant.

That's why I said "let's not display the one-way proofs on the profile page" in my previous post.

When I wrote "facilitating the exchange of a claim" I should have included out-of-band as in "facilitating the out-of-band exchange of a claim" as in signing a statement and messaging it to you or posting it somewhere other than Keybase.io.

I commented "segregating bad choices from good choices" and elaborated on my position that trusting one-way claims on Keybase.io are "bad choices" with respect to trusting two-way proofs. This is why I disagree that moving one-way claims somewhere else in the UI fixes the problem. I didn't directly point out that I was rebutting your suggestion, but it was your suggestion that prompted me to write what I wrote.

I'm sympathetic to where you're coming from. One of my first drafts included something like "but if you keep one-way proofs, then at least separate them," but I decided it muddied my initial point and ultimately omitted it. I even have a recollection of advocating a similar UI improvement for the current Bitcoin address on the profile, but I can't find it.

In all likelihood hosting one-way claims on Keybase.io are here to stay. In that case, I certainly hope they are segregated as you suggest.

A PGP signed statement "The holder of this PGP key wants to receive TextSecure messages encrypted with key X" is in no way a "weak claim". It's a cryptographic proof.

I understand. I did a bad job of demonstrating what I meant by "weak claim". Here's one:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I am @toolbear on Twitter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUAQUWAAoJEG82bfxIPG1ncEQQAMEL6eEVAKV/Lw1qSD1kBN4e
KT8WvWyompmG1OJkopwPe1VwR67vxEOMS+buNKX6D0ZJf0F2rd7SMaRKNAldpkI1
Hbsks+3AKPlVLdlpdacwBimMH+QMwHPWXv21ThTqDX0jnezZjRdYIz+qDaBdeG0v
koqyYhF8JNG6onebLR7fTiu4CYsd/ZDkfEbeASnG0QlvSiN1OpZ3Lt3FElTmTVqP
QP18xWFgY11SosxBZBaHCpC/GhV/5xRoHoA548Lt3pKKzE8ijE/aWIxvkTNti1g1
J9HM/5RYw4Rtjfi7zODcBp+ecIAoOULZxWuP05nODZV62a4EgjycWZpzbu6s3YEw
fm9TefBqLfZ/iD6jB2Paaq2XqJVwHU6tAaFSC4PphYG1kZxEg9udnve9ospCEA7x
L4dAzbj6qUNUv9Z/u0CQxuBCdWyN3H62AFhdc2FIar7v6ziTOoqCHTKTr1k+DSbK
deKypmREUqAZtaJZ0QUbsX5uhkGqOlN/7oDuo7r5X5q1P6vAztqEpCtiAWHDNi0Q
i2pksMJMB7a9ZotcenISiSJEzhXEP06hciJAswodwqs8OxPHvm2yaXpCYtYzAXvH
vu/iNV4poJjx0/57VrTlG8JM3ny0ZwXeO18l/rLdVrI9QZ/jYI2a0OSVfZLYR34H
v8JiRsc2GCtc63LHuAVo
=yNe4
-----END PGP SIGNATURE-----

This claim is signed by me. It's also false (I'm @toolbear74).

It's a bad thing if Keybase cooperates in letting me put false claims on my profile or tied to my profile. I prefer if Keybase:

lorenzhs commented 9 years ago

Mate, your premises are ultimately flawed. When someone else has access to my private key, I'm screwed anyway. Any communication with that key is compromised. In that case, I have bigger problems that are not the concern of this issue.

As far as hosting of the proofs is concerned, I suggested self-hosting them as well, on your two-way proven domain. Heck, use a torrent like @tinloaf said. Decentralised, woohoo.

The current Keybase setup is just as susceptible to a DDOS attack. Without the Keybase website or API, you have no way of finding out which proofs belong together, and finding the proofs can be very hard.

Your claim "Bad actor who takes over Keybase eventually has [...]" is plain wrong. Keybase does not have my private key, so the bad actor cannot forge my signed statements.

The false claim you made may be false (I can do that, too: https://gist.github.com/lorenzhs/6302617e47347c9d3f65), but I can still verify that it was signed by your private key. If you're lying, that is ultimately your problem, because that other guy could tweet something you don't agree with and here I have a statement, signed by you, that says that you control that account.

tinloaf commented 9 years ago

@toolbear So you assume that (a) keybase has received a NSL and (b) your private key is out in the public. Please tell me (no, just in case you don't get sarcasm: Don't.) what exactly is hindering them to send github another NSL, and suddenly you're screwed, too.

When your private key is no longer private, you're screwed, period. But it looks like you don't want to understand, right?

[Mirroring Keybase] What happens if they disagree? When the root I trust is compromised?

Then how exactly is the compromised root able to forge wrong statements for you without having your key?

I understand. I did a bad job of demonstrating what I meant by "weak claim". Here's one:

No. I know what a weak claim is. That's why I did not propose adding something like this, but rather the statement in my previous post, I'm not gonna repeat everything here.

Personally, I've reached EOD here, it does not seem like you're even willing to read and understand what other people write. I have one more question for you: Are you officially affiliated with keybase.io? If not, I'll close this and open another ticket in which I would like to discuss this with the devs (and other reasonable people), I'm not assuming they are willing (or should be willing) to read through all the Offtopic stuff in here.

ghost commented 9 years ago

it does not seem like you're even willing to read and understand what other people write — @tinloaf

In my experience, when both parties feel that way it often indicates a misunderstanding as opposed to ignorance or obstinance.

Are you officially affiliated with keybase.io

No.

I apologize if I gave that impression, it wasn't my intention.

If not, I'll close this and open another ticket in which I would like to discuss this with the devs

I ask for a #XXX reference to this issue in the comments and I'll avoid bringing up ground covered here in your new issue.

[other questions]

I'll assume your other questions were rhetorical. I will respond briefly to @lorenzhs.

lorenzhs commented 9 years ago

I think you're trying to make Keybase perfect, while @tinloaf and I are "just" trying to make it better. That's our misunderstanding.

tinloaf commented 9 years ago

The new, hopefully on-topic issue is #986.

ghost commented 9 years ago

@lorenzhs

It may be getting lost that I personally don't host my private key on keybase.io. But since the feature exists, Keybase promotes its use, and they're targeting mass adoption, I think it's reasonable to consider that many, possibly most users will host their private keys. Thus I think it reasonable to view Keybase features through that lens.

When someone else has access to my private key, I'm screwed anyway. Any communication with that key is compromised. In that case, I have bigger problems that are not the concern of this issue.

People don't always know immediately when they've been compromised. Two-way proofs, by virtue of other users who may be tracking a compromised user, could aid in early detection. I see this as analogous to how Chromium's cert pinning lead to early detection of the DigiNotar attack.

The current Keybase setup is just as susceptible to a DDOS attack. Without the Keybase website or API, you have no way of finding out which proofs belong together, and finding the proofs can be very hard.

Agreed. But it's a nice property that if, for example, I find your Gist I can still verify it.

Your claim "Bad actor who takes over Keybase eventually has [...]" is plain wrong. Keybase does not have my private key, so the bad actor cannot forge my signed statements.

It's the users taking advantage of hosted private keys that's top of mind for me.

Though I've used state-sponsored bad actors like the NSA a lot, I'm also worried about bad actors on those users' WiFi networks.

If you're lying, that is ultimately your problem

It could also be the problem of people duped by the lie because they thought it was trustworthy.

ghost commented 9 years ago

I think you're trying to make Keybase perfect, while @tinloaf and I are "just" trying to make it better. That's our misunderstanding.

I think you're onto something, but I'd characterize it differently: Keybase is pretty good already, but adding more one-way claims makes it worse.

Now we know there's a fundamental disagreement. That's progress.

lorenzhs commented 9 years ago

Exactly. I don't think discussing this further will yield any more insights here, but our arguments are archived and linked in the new issue, so they're not lost.

malgorithms commented 9 years ago

Hey all -

You made good points here.

Unsure if I should be putting this here or your new topic #986 , but I think there's a clear and constructive distinction between one-way verifications and two-way verifications.

A one-way verification isn't a "verification" at all. It's simply a signed announcement. What do I mean? Well, imagine all these sitting alongside each other on keybase under a heading called "Announcements":

Having plain English signed and bundling them together makes them feel very different from proofs. I'm doing this to illustrate a point, but it's actually worth noting that one of the signature types we support is generally an "announcement" which is expected to contain a hand-written string. It's not in the UI yet. With something like a bitcoin address announcement (distinct from a remote proof, which is technically possible but annoying), we could make the standard both a sentence and some structure to make it extractable by software.

Formally speaking, in the code, Keybase currently has 6 types of signed statements that it allows into your signature chain. Only one of them is a 2-way "remote proof" which is the twitter, reddit, etc. two way proofs. The other 5 are all statements of one kind or another, such as a revocation, a public track announcement, a cryptocurrency address post, etc. These other types of statements are useful for different purposes. But they're totally different from remote proofs.

Anyway, in summary:

tinloaf commented 9 years ago

@malgorithms Great, that's exactly what I wanted to hear, assuming that "signatures other than 2 way proofs" includes "announcements" (way better name than one-way proofs) such as "I'd like my OTR conversations to be encrypted with key X". :) :+1: