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

[Ximin Luo]

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.

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/9c810fc4/attachment.sig>