[OTR-users] PGP integration?

[Kat Hanna]

On Sun, 23 Jun 2013, Ximin Luo wrote:

> On 23/06/13 16:44, 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?
>>
>> You need to become part of _some_ trust system. If you don't want to
>> join the DNSSEC PKI hierarchy, you have to find some other way to
>> outsource your trust yet retaining the ability to "lookup" OTR keys
>> indexed by "identity" or "email address".
>>
>> Someone could run a service using some kind of open "dns zone" using an
>> OTR bot of some kind. But in what juristiction would the
>> person/code/server be, and how well could you trust it?
>>
>
> PGP is *already* its own trust system, widely used to sign/encrypt emails. There are many keyservers around the world, in many different jurisdictions, that sync with each other. Importantly, you don't need to trust that infrastructure, you trust keys you personally signed yourself (physically outside of the system), and then you can transitively trust the keys that they signed, etc etc etc. For example, I can trust Linus Torvald's key because there is a trust path from me to him: http://pgp.cs.uu.nl/mk_path.cgi?FROM=5fbbdbce&TO=00411886+&PATHS=trust+paths
>
> I am proposing OTR keys should take advantage of this trust system that is *already in place*, by using the concept of "UIDs" that *already exists* in PGP keys, to associate a key with an IM address.
>
>>> 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.
>>
>> Even if we specify some global IM UID, where are they looked up? where
>> are they stored? How are they authenticate? How can those storage spaces
>> be trusted? Using DNS(SEC) is one way of addressing these issues.
>>
>
> On the PGP key itself, as per *existing standards*. The UID is interpreted in an application-specific way, e.g. a email address for PGP/MIME, or a server hostname for monkeysphere's SSH authentication. Likewise, we can have libotr interpret UIDs on PGP keys as IM addresses. Trust occurs as I described above; if my explanation is not clear, you can search "PGP web of trust" to read more on how it works.
>
> I don't know how far you are implementing your suggestion, but most of the key points you mentioned are *already present* in the PGP web of trust, and it would be better to re-use an existing system rather than trying to create a new one.
>
>>> 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.
>>
>> With libotr-4, at least the problems with multiple logins should be
>> resolved. The otr key in dns spec would need to account for a single
>> user having multiple OTR keys on different devices (though one should
>> really sync those up to be the same). Either by allowing more then one
>> Resource Record of type OTRFP, or by somehow encoding the "resource"
>> within the name as well.
>>
>
> Yeah I've been testing it out :) The issue I described is with that version. There was also another issue which I've filed a bug for on sf.net.
>
>>>>> 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.
>>
>> What you say is all too technical for the target common non-geek user.
>> The phrasing could probably be made a little stronger, eg something like
>>
>> "to confirm you are not attacked and are actually talking to the person
>>  you tried to talk to, please confirm...."
>>
>> Although this sounds pretty clumpsy. Anyone else with better text?
>>

I agree that a wording change should take care of this.

> How about:
>
> "To confirm that there is no-one intercepting or otherwise attacking your communication, please confirm <thing>. Note: It is vital you use this process here rather than asking via the (potentially insecure) channel itself."

This is *way* too long; nobody will read it. I'll add working on this to
my to-do list, though I'm not sure when the next version is going to go
out.

  -Kat