Switch back to email addresses as usernames

[davidlazar]

Currently, with usernames, there isn't a good recovery mechanism for users that lose their keys. Originally we were thinking to let a user reset their account if they haven't extracted a key in 30 days (with no further verification), but this would lead to users losing their usernames if they go offline for an extended period.

With email addresses, we could at least verify that the user owns their email address before resetting the account. This would mean that users don't have to worry as much about losing their username, even if they go offline for a long time.

This is technically an issue with Alpenhorn, but I'm posting it here for wider visibility.

[aa153]

I have updated vuvuzela-client today but can not register (tried with gmail and protonmail email accounts). Got the same error:

There were errors creating your account:
error response (404 Not Found) with unparseable body: "404 page not found\n"
error response (404 Not Found) with unparseable body: "404 page not found\n"
Post https://pkg2.vuvuzela.io:8443/registrar/preregister: dial tcp 128.31.25.215:8443: connect: no route to host

[davidlazar]

Sorry about that. New user registration is temporarily disabled while we transition to the new system. I've updated the website to reflect that. Everything should be up and running again in a week or so.

[taoeffect]

So what's stopping you from impersonating users?

[davidlazar]

The PKGs verify your email address when you create an account.

[taoeffect]

The PKGs verify your email address when you create an account.

That really doesn't make sense to me, as there's nothing secure about "verify [email]". If your servers have the ability to reset keys at will, it means the protocol is insecure.

I'm skimming the Alpenhorn paper right now to get a better idea, and I noticed a section on "Worst-case security" that says:

If users have out-of-band knowledge of each other’s public keys, Alpenhorn’s API can use them to defeat man-in-the-middle attacks, as in existing protocols.

OK, well:

1. It sounds like in the current design they don't.
2. If they did, you could throw out everything else as it would be totally unnecessary.

Alpenhorn’s client uses an SSH-like trust-on-first-use (TOFU) approach if out-of-band keys are not provided, by remembering the friend’s long-term signing key from their first add-friend request. If two users called AddFriend when at least one server was honest, then a later compromise of all servers does not allow an adversary to mount a man-in-the-middle attack.

That is in contradiction to what's implied by this issue: that servers can reset keys at will, meaning there is no TOFU.

In the absence of out-of-band keys, Alpenhorn could require each user to register their public key in a verifi- able ledger (such as Keybase [26] or Namecoin [36]), and to send a proof to new friends that their key is registered in such a ledger.

If Alpenhorn did this, which it doesn't, there would be no need for "PKGs", and the protocol would be secure. Rebooting Web Of Trust has two relevant blockchain-agnostic concepts for this: Decentralized PKI (DPKI) and Decentralized Identifiers (search for DID here).

Am I misunderstanding something?

[davidlazar]

Like Vuvuzela, Alpenhorn is anytrust. There are several PKGs operated by independent parties and Alpenhorn's security guarantees hold if all but one are compromised. The honest PKG will not reset a user's key without verification or until the account becomes inactive.

The "Worst-case security" section considers the case where our assumption doesn't hold. In that case, we could use public ledgers, Keybase, etc in addition to the PKGs, but I'd rather make the assumption hold by having more people contribute PKGs.

[taoeffect]

Like Vuvuzela, Alpenhorn is anytrust. There are several PKGs operated by independent parties and Alpenhorn's security guarantees hold if all but one are compromised.

I don't understand how that sentence is compatible with this sentence you wrote earlier:

we could at least verify that the user owns their email address before resetting the account.

Who is the "we" that is resetting the account? If they are independent, how are they able to reset it? Is there a conference call that is held for each request to reset the keys with the independent operators who all vote on whether or not the account should be reset? If not, how can you claim they are independent?

[davidlazar]

We haven't implemented account recovery, but I'm thinking it will work as follows:

1. The user requests to reset their account at https://vuvuzela.io.
2. The webserver forwards the request to each PKG.
3. Each PKG decides whether to honor the request: if the account has not been used to extract a key in 30 days, the PKG sends a verification email to the user (so the user will receive N emails, one from each PKG). The PKG ignores the request otherwise.
4. The user follows the instructions in each verification email to reset their key with each PKG.

The user can ensure that their key/account wont be reset by staying active (i.e., extracting a key from each PKG at least once every 30 days).

[taoeffect]

so the user will receive N emails, one from each PKG

The user follows the instructions in each verification email to reset their key with each PKG.

So I don't know whether users will find that workable. You might find some of the social-recovery stuff we've worked on as part of RWOT potentially useful (example). There are some projects lifting off the ground that actually implement these identity systems, and what's cool about them is that users have real ownership over their identity, and social-recovery can work with multiple devices that the user owns as well (2-of-3 multisig etc.).

[olivermj3]

PKG2 appears to be an issue. Can't connect due to inconsistent PKG status Has this been resolved?

PKG pkg1.vuvuzela.io:8443: OK
· PKG nickolai.srv.vuvuzela.io:54331: OK
· PKG pkg2.vuvuzela.io:8443: Post https://pkg2.vuvuzela.io:8443/status: dial tcp 128.31.25.215:8443: connect: connection refused
-!- Type /connect after resolving the issue to try again.