[messaging] Separation of concerns, usability, and partial verification

[Ximin Luo]

On 12/03/14 15:18, Ximin Luo wrote:
> This is a brief outline on the architecture of an independent/central "verification" program. This could be part of a keyring, or a contact manager, or even a combined contacts/keys manager that some UX folks were suggesting at the CTS IV. It would let a user:
> 
> 1. store cryptographic material to authenticate their contact, either a public-key fpr, or a shared secret for kex, or whatever.
> 2. store/set the *verification status* of the material. this could be:
>   - full (physical), i.e. via a physical communication of fingerprint or shared-secret
>   - delegate, i.e. sent via a friend (the friend must themselves be verified). (one idea for mpOTR/groupchat is to have the initiator send all public keys to everyone else.)
>   - saw-multiple, i.e. saw the contact use/communicate the key via these insecure but independent channels/mediums (e.g. via email, phone, IM from several accounts)
> 3. read some subjective comment/advice about how "safe" the current situation is
> 4. set the *overall policy* for letting other applications treat a contact as "valid". e.g. require-full, require-friend-trust, allow-but-warn-if-new (i.e. a form of TOFU)
> 5. perform physical verification via technical means, such as scanning a QR code
> 6. sync this state to other trusted devices
> 
> The point being that identity/key verification is a logistics and usability issue, and not really a cryptographic issue.
> 

One can extend these processes to other identity-related metadata too, such as email addresses / phone numbers (the "real-world" analog to a fingerprint).

For example, often people will sign all the email addresses on a GPG key, without checking if the signee actually owns each address. This is not an obvious thing to do, since everyone is so focused on (OMG) fingerprints. One bug I noticed for the debian keyserver is that it performs no verification of email updates on submitted keys, so any Debian Developer can claim they own obama at whitehouse.gov, and Debian keyring infrastructure will automatically import this.

A further consequence is that, such an architecture would encourage contact managers to secure (auth-encrypt) ALL contact metadata.

> It is semi-relevant to the other thread - we want to support not only fpr verification, but other methods of verification too, including "soft" verification (inc. the effortless TOFU) that is easier but not secure against Nation-State-Adversaries.
> 
> Advantages:
> - user can set strict/loose verification policy based on their own preference, in one single place, that affects all applications
> - saves application writers from having to think about these issues
> - unified UI for verification
> - synced between different devices. most crypto-application writers will not bother with this, it is too hard and a separate concern from their program.
> 
> Disadvantages:
> - the component's verification-status data-model may not cover everything that a certain application needs. this can be fixed with time, however, and it will eventually benefit all applications, not just a single one.
> - most developers of contact managers aren't security-trained. you would hope that developers of keyrings are a bit better, but we still see things like http://gaganpreet.in/blog/2013/07/24/kwallet-security-analysis/ mistaking EBC for CBC
> 
> Thoughts?
> 
> X
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140312/9b95dff0/attachment.sig>