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.
[email protected] is the same as [email protected]) 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
_______________________________________________
OTR-users mailing list
[email protected]
http://lists.cypherpunks.ca/mailman/listinfo/otr-users
