When should nicknym query or fallback to which lookups?
I think it boils down to the question: Should nicknym fallback to other sources if a provider-domain key cannot be found ? And which nickserver should do this (the answering one or the querying one ?)
Provider <> providermail:
Should nicknym, when it finds another LEAP-enabled provider, use their nicknym as the sole provider of truth?
I think the answer is yes: when the other provider is new and doesn’t carry over any old, existing mail accounts. or has decided to fall back to global keyservers, then we use that answer.
There are 2 workarounds for end-users to overcome any problems mentioned above, that require action from them and aren’t foolproof:
1. Upload their existing public key through the webinterface (how does the provider example.com know which user is LEAP-enabled and which isn’t?). (who does upload which key ?)→ user can upload their own pubkey to their provider through the webinterface. I think both ‘solutions’ are fine to silence criticasters, but would be seldom used and rather confuse users than anything else.
2. insert the public keys of their correspondents in their bitmask keyring (see I2)
Situation: Provider example.com doesn’t want to migrate all accounts to LEAP enabled email at once.¶
User alice@example.com has opted into the new LEAP-powered setup, user bob@example.com hasn’t.
carol@another.leap is at a different provider.
| I for Internal | A for Another LEAP enabled provider | |
| Interally on the same LEAP provider | One LEAP provider to another LEAP provider | |
| From alice@example.com to bob@example.com | From carol@another.leap to bob@example.com | |
| 1: Bobs key is correctly published to keyservers | Nicknym can’t find bobs key locally, falls back to global keyservers and finds it. | Nicknym.another.leap can’t find bobs key at nicknym.example.com and successfully gets it by falling back to keyservers. |
| Email is sent encrypted, everyone happy. (Currently this fallback is deactived in nickserver, so alice won’t be able to find bobs key and the email would be sent in clear text) | ||
| Sending unencrypted locally is acceptable as it doesn’t leave the provider | Sending unencrypted between providers is bad until we fingerprint certificates against TLS downgrad attacks | |
| 2: Bobs key is NOT published to keyservers | Nicknym can’t find key neither locally nor by falling back to keyservers. | Nicknym.another.leap can’t find bobs key neither at nicknym.example.com nor by falling back to keyservers. |
| Without any manual steps, the email would be sent in clear text. Since Alice is a pro-user and tickles bitmask-ctl to import Bobs keys (hopefully soon possible with Bitmask UI). Another, maybe easier approach would be to ask bob to sent here his key attached to a mail in which case keymanager would import it automatically (right ?). Bob gets encrypted mail. Everyone happy. (Current behaviour is the same after manually importing bobs key) | ||
| 3: Bobs key is published to keyservers but he has forgotten his password | Nicknym can’t find bobs key locally, falls back to global keyservers and finds it. | Nicknym.another.leap can’t find bobs key at nicknym.example.com and successfully gets it by falling back to keyservers. |
| Alice mails Bob but he can’t decrypt the mail and sees mangled garbage. They curse on their example.com and bitmask and move on to Facebook Chat. Facebook is happy. (Current behaviour like 1: mail gets sent unencrypted) | ||
| Sending unencrypted locally is acceptable as it doesn’t leave the provider | Sending unencrypted between providers is bad until we fingerprint certificates against TLS downgrad attacks | |
| 4: Eve uploads a fake key for bob to keyservers | Nicknym can’t find bobs key locally, falls back to global keyservers and finds it. | Nicknym.another.leap can’t find bobs key at nicknym.example.com and successfully gets it by falling back to keyservers. |
| Alice mails Bob but he can’t decrypt the mail and sees mangled garbage. They curse on their example.com and bitmask and move on to Facebook Chat. Facebook is happy. (Current behaviour like I1: mail gets sent unencrypted) | ||
| Sending unencrypted locally is acceptable as it doesn’t leave the provider | Sending unencrypted between providers is bad until we fingerprint certificates against TLS downgrad attacks | |
