check email proof regardless of the value of prevUpdate

[maditya]

@daniel-ziegler @andres-erbsen please review

[daniel-ziegler]

What is the reason for this change?

[yahoocla]

CLA is valid!

[maditya]

with the current logic, won't email proof check be skipped for the first update of a user? the diff looks weird, but the only thing changed in this PR is removal of if at https://github.com/yahoo/coname/pull/55/files#diff-2d77dfe3774d2b209ad7e5207d392fd9L57

[daniel-ziegler]

I think it was the other way around before, right? The email proof check was only done for the initial registration. After that, we assume that the requirement to sign updates with a key from the previous version ensures that only the user (or Yahoo, for the less-secure mode) has done any updates, so it shouldn't be necessary to also do another email proof. Maybe it doesn't hurt, though. What do you think?

[maditya]

I think it was the other way around before, right?

Yes. This is what happens when you're doing two things at a time :)

Maybe it doesn't hurt, though. What do you think?

Yes, I think it keeps things consistent - always require email proof for an update.

[andres-erbsen]

Quoting Daniel Ziegler (2016-03-23 10:48:17)

I think it was the other way around before, right? The email proof check was only done for the initial registration. After that, we assume that the requirement to sign updates with a key from the previous version ensures that only the user (or Yahoo, for the less-secure mode) has done any updates, so it shouldn't be necessary to also do another email proof. Maybe it doesn't hurt, though. What do you think?

Not requiring email proof after the initial registration would make developing clients much simpler. IIRC, the current .proto spec says that initial registration procedure is provider-defined, but all future client-server interactions are defined in the spec. This means that one can (and I am in fact planning to) build a general-purpose command line client that can look up and modify profiles on all coname servers (given the secret key, of course). Provider-specific registration would be supported by importing the key from a provider-specific client (e.g., a javascript snippet to run in the context of the E2E extension). If other profile updates than the first require provider-defined interaction, implementing a client like described will be a daunting task...

Just to make sure that we are on the same page about this, I will go over why I think not requiring email verification on future profile updates is totally okay.

Each user is either in "fail-open" mode where the user's key and the service provider's key can change the profile, or in "fail-closed" mode where only the user's key can change the profile. This difference is encoded in the user's profile by listing two or one keys in the update_policy field respectively.

• When a user changes their profile during normal use (not key reset / account recovery), they sign the entry update using their own key. By the assumption that the user is the only one who controls that key, verifying the signature is sufficient to check that the update is authorized by the user.
• When a user would like to change their profile but does not have access to their update signing key, they need to go through the service provider account recovery process. This does not happen during normal use, and does not do anything if the user has opted out from key reset by choosing "fail-closed" mode. I do not know the details of the Yahoo account recovery proccess, but these details really should not be relevant to the keyserver: through some rigorous process the user convinces the service provider that they indeed are the rightful owner of the account, and in response to this the service provider uses a key it controls to sign an update to the user's profile, installing a new key provided by the user. This process that vets the user's appeal and issues a signature if satisfied should live outside coname.

There is another benefit of this separation that I consider quite imporant: when Alice's device sees that Bob has a new key, it would normally display a warning that users would probably just learn to click through (regular key rotations are a good idea). I think Signal might require one to remove and re-add the contact. However, when Alice's device can verify that the signature that authorized the change was indeed given by Alice (and not by a third party), it would be safe to skip the message (which would avoid training users to click through security warnings). We may not implement this fine-grained warning logic in the first client, but I really don't want to set us on a path towards regular click-through warnings a la HTTPS.

Another possible benefit: if the service provider keys on "fail-open" users' profile are different and "fail-closed" users list two keys out of courtesy, then an adversary cannot trivially tell whether a user is in "fail-closed" or "fail-open" mode without taking control of the service provider first. How useful this obfuscation is is debatable, but one could argue that this can deter attacks against service providers (even when the targeted user is "fail-open").

[maditya]

Fair point. cc @adon-at-work this also requires changes to the extension. Specifically, the mode currently supported by extension is not really "fail-open" mode.