On Tue, Jul 2, 2013 at 7:39 AM, Kurt Roeckx <k...@roeckx.be> wrote: > On Tue, Jul 02, 2013 at 10:12:10AM -0400, Greg Troxel wrote: > > > > Not true - OTR's signing key to authenticate a session is similar to > > OpenPGP. The difference is that session keys are authenticated, not > > messsage content, and repudiability (word?) is achieved by using > > symmetric MACs and disclosiing them. > > I guess I need to go and look up how OTR really works. > > I want to discuss this more explicitly, because it is a fundamental feature of OTR and it also is in line with my usability intuitions. Also, I may not understand the subtleties correctly, so I want people to clarify any mistakes. If you are on this list, you should understand this fundamental aspect of OTR and furthermore, you should consider how that interacts with assumptions "the typical user" might make.
Caveat emptor: I'm new to the OTR protocol, so please verify every statement I make and do not take my word for it. Here goes: OTR is designed so that if one of the two parties records all network traffic, then shows that recording to a third party, they cannot prove the other party participated or authored any of the messages. The best they can do is to show someone who knows a shared session secret authored the messages. However, that includes the accuser themselves! Furthermore, after a conversation session ends, that secret can be made public, so that after that point, it's conceivable that anyone with any recording of the session could have modified their transcript at their whim. Someone who knows Alice's public key can produce a transcript ex nihilo that claims Alice participated in a conversation and said X, Y, and Z, all without Alice's participation in any way. Therefore, transcripts from OTR sessions are not useful for proving what conversations someone has participated in, nor what they have said. Perhaps non-intuitively a participant of a conversation can prove *to themselves* that Alice is indeed participating in a conversation and is indeed saying X, Y, and Z. This is the key value of OTR. Could anyone verify all of those statements are correct? I've only skimmed the first part of [1] but I'm familiar with the goals and technique by reading about mpOTR. The philosophy of OTR's protocol design is that these properties *matches user intuitions*. So by the same philosophy, the UI should reinforce that as much as possible. If there are PKI features, we should ask "do those match user intuitions?" For example, if there's a revocation protocol, what will user intuitions be about revocation? Also, how do we design a UI (across many different clients) that promotes "the right kind" of intuitions? regards, callme whatiwant [1] http://www.cypherpunks.ca/otr/otr-wpes.pdf > Kurt > > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >
_______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
