[OTR-users] PGP integration?

[Ximin Luo]

On 22/06/13 17:41, Paul Wouters wrote:
> On Sat, 22 Jun 2013, Ximin Luo wrote:
> 
>> 1. Unfortunately if I sign my OTR key (a file) using my PGP key in the usual
>> way, this creates a non-revocable signature using the "S" ability of the key.
>>
>> What we really want is to create revocable certification of the OTR key using
>> the "C" ability of the key, which is the same thing that's done when signing
>> other people's keys (as opposed to files).
> 
> I'm writing a draft to put the OTR key in your DNSSEC zone. Revoking
> that is done by simply removing the DNS record, or replacing it with a
> revoked key.
> 

But what about people that don't have DNS zones?

What are the difficulties of coming up with a standard to describe instant messaging UIDs? As a start, we can do XMPP surely, that seems simply enough since there is no ambiguity? I know that IRC is problematic due to weak authentication and the fact that you can login from multiple servers (e.g. username at irc.debian.org is the same as username at irc.oftc.net) but these do not seem like intractable problems.

One nuance is that when you change the XMPP resource in a client, currently OTR regenerates the key which is a bit of a usability pain, but there may be a security argument here that means this is not avoidable.

>> 2. I'd like to bring up the issue of UIDs again because without a web-of-trust,
>> OTR is stupidly hard to use, since you must verify keys with every single
>> recipient. (Man-in-the-middle attacks destroy the credibility of non-verified
>> sessions.)
>>
>> IMO the terminology used is extremely misleading too, e.g. [1] "authenticating
>> your buddy helps to ensure that the person you are talking to is who he/she
>> claims to be" completely ignores the issue of MitM.
> 
> I am confused. It is _exactly_ talking about MITM here?
> 

The wording does not sound like MitM to a non-technical user. It sounds like you're just verifying the endpoint, not any potential men-in-the-middle who would be simply parroting what the endpoints say. It also sounds like it's something you can do manually within the content of the messages. But this is not enough

Attack:
A ->Q-> M       B
A       M ->Q-> B
A       M <-A<- B
A <-A<- M       B

Looks exactly the same as:
A ->Q-> B
A <-A<- B

from A's point of view.

I'm guessing the Q/A verification method basically treats ANS as a shared secret (i.e. ANS is never actually sent by B in a way that would be decryptable by M), but the wording of this also implies to the user that it's something they can just do manually without going through the formal protocol.

X

> Paul