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

[Ximin Luo]

On 13/03/14 06:37, Tom Ritter wrote:
> I think something very important for protocols we design going forward
> is persistence of key material, ala ZRTP's.  The encrypted
> conversation I am having with Alice now is authenticated via the last
> encrypted conversation I had with Alice.  You can trick me by MITMing
> all my conversations with Alice, but as long as I get one conversation
> in that you don't - we'll be able to figure it out.
> 

It's not clear to me whether it would be appropriate/useful to store this stuff in the contact-verifier component I outlined below. Ratchet secrets are associated with *ongoing sessions*, which might be very long-term, but they are application-specific. (Can you think of a maybe-future-common use-case where multiple applications share the same session?) Although, perhaps it could be useful for an application that does not need any other persistent-secrets-storage, to "piggy-back" onto the service provided by the contact-verifier.

I think it probably is *inappropriate* to share this state across devices (one major feature of the contact-verifier). Proper operation of ratchets involves deletion of old secrets, but this can't be done if "there might be another device that needs this". This is why I don't share my OTR keys across devices. (Some people tell me they've done it, but they also never have concurrent sessions between multiple devices.) When we have multiparty ratchets, which I am looking into, that will solve this problem as well, so I think we don't need to spend extra effort solving it separately.

> My happiness with this design evolved in a good deal from discussions
> with some of the folks on this list at various events.  It's the
> implementation I'm a wee bit nervous about, as this system needs to be
> handle things like 'restarting after a lost device' and the ratcheting
> issues of what happens when we aren't in the same state because I
> think you received messages from me but you didn't.
> 

This can be done with a proper understanding of what all the components of the ratchet are used for. We can derive specific conditions under which it's *safe* to delete secrets - roughly speaking, for "remote secrets", you can delete old secrets when the other person has acknowledged a new secret; and for "local-only" secrets, you can delete old secrets when you yourself have committed the new ones to persistent storage.

Some rough notes here: https://github.com/infinity0/smc-notes/blob/master/ideal-ratchet.rst which is a generalised model of a ratchet, without reference to concrete crypto primitives. (Ps() and Pr() are the same as prevS() and prevR() that I mentioned in my other thread.)

> -tom
> 
> On 12 March 2014 08:18, Ximin Luo <infinity0 at pwned.gg> 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.
>>
>> 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
>>
>>
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>


-- 
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/20140313/0484558e/attachment.sig>