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

[Tom Ritter]

On 13 March 2014 06:02, Ximin Luo <infinity0 at pwned.gg> wrote:
> 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 in an ideal scenario, all my encrypted communication with Bob
(me being Alice) would be linked.  Not the same _session_ but I meant
in the sense of a continuation of key material.  Encryption was
opportunistic in conversation #1 (meaning there was no authenticity),
but in conversation #2, we use a secret from the first conversation.
Authenticity is not linked to a person, but to the cryptographic
identity of whoever I talked to in Conversation #1.

For example (monospace required):


Initial OTR Conversation --- PGP Conversation --- Unacknowledged OTR Message
                                     \
                                      ----------- PGP Email
                                       \
                                        --------- ZRTP Call ----------- OTR Chat

In this scenario, I talk with Bob on chat. We save a little bit of
that session, and I send Bob an email (or vice versa) which includes a
continuation of that session, Bob replies. I then send Bob an OTR
message which is a continuation of the PGP conversation - but Bob
doesn't reply.  Concerned, I send him a PGP email that is a
continuation of the prior PGP conversation (not the OTR Message).  Bob
still doesn't reply.  Very concerned, I initiate a ZRTP Call, which
Bob finally answers.  My next conversation with Bob (an OTR Chat) will
now include a continuation of the ZRTP session.

I admit this is wildly futuristic and would be quite difficult to
specify or build.



>
> 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.


I also do not share my OTR keys across devices - it's annoying enough
with unsynced OTR states due to laptop hibernations, I shudder to
think that nonsense that would cause.  But I do think that sharing the
state across devices is desirable.  The OTR/PGP/ZRTP example above is
quite complicated, it can be made simpler by focusing on a single
service.

[[[
Large Aside:

I've had an idea in my head for the past few months I haven't had time
to spec out for OTR. It basically involves a daemon running on a
server you control that operates your well-known XMPP account (say
tom at ritter.vg).  You generate a significant number of throwaway XMPP
accounts, abcdef000 at ccc.de through 999, and communicate with friends
using those accounts, but with your identity bound through a signature
on the throwaway from your well-known account.  There are two
sub-protocols happening inside OTR.  One protocol is to let a
communication partner know that this throwaway account is yours, and
they should communicate with you on it. The second is to have
real-time chat syncing between your authenticted devices, the way
non-OTR Google Chat works. (And a sub-protocol of #2 is contact list
syncing.)

This would be quite complicated, and maybe the pairs of throaway
accounts (one-three per contact) too numerous to be feasible.  But
from a feature standpoint it provides what I want. I want chat
transcript syncing between clients. I want a well-known identity
people can contact me at. I want anonymous throwaway accounts at
pop-up XMPP providers (like ccc.de) to resist message size and
frequency traffic analysis by my well-known provider (usually facebook
or google).  I want my well-known identity provider, if it has a
contact list at all in the XMPP sense, to be full of anonymous
throaways they cannot datamine.

In this scenario I would absolutely build the OTR session continuation
in across devices.
]]]



Anyway, I certainly respect the desire to scope a problem to within
something you think is reasonable for either a 'first phase' or 'thing
you want to build'.  I'm being more than a little futuristic here - I
just see some cool possibilities.

-tom