By "the payload channel" I mean the Chan.T.FileTransfer, Chan.T.Call1, Chan.T.StreamTube or Chan.T.DBusTube whose contents are protected.
On 12/06/12 14:42, Simon McVittie wrote: > * Optionally (open design question: do we need this?), Alice's > connection manager could pop up a Requested=FALSE channel > representing the request "give me the certificate you want > me to use" If needed, this can't be an interface on the payload channel: it has to be a separate channel, a requestable property, or not offered at all. Rationale: if it was an interface on the payload channel, a legacy Handler (not supporting e2e) would never answer the question. The CM would have no way to know that the question would never be answered, so it would wait forever, and be unable to send session-initiate. Perhaps we don't need this: telepathy-gabble could generate a self-signed certificate per JID and use it unconditionally. In practice, nobody has a CA-signed XMPP client certificate anyway. The other thing we need before sending the Jingle session-initiate is to know whether we should offer Bob SRP (secure remote password). If Alice and Bob have pre-agreed a username/password, we want to offer SRP, by sending Alice's username when TLS commences; if they haven't, we don't; and ideally we don't want sending someone a file to always produce an interactive "do you have a SRP username/password? If so, what's your username?" prompt. Perhaps we should make the SRP username a requestable property of the channel, and not offer SRP without it? RFC 5054 describes a mechanism for advertising that you support SRP without providing your username, but it requires reconnecting. I'm not sure that we really want to start a new Jingle session for this... > * Optionally (open design question: do we need this?), Bob's > CM could pop up a channel representing the request "give me > the cert you want me to use" Similarly, this can't be an interface on the payload channel. There is no request here, so a requestable property is not possible either. It has to either be a separate channel, or not offered at all. > * If Alice has requested protection from active (man-in-the-middle) > attacks, i.e. Conn.I.Securable.Verified=TRUE, then her CM pops > up a channel analogous to the current Chan.T.ServerTLSConnection, > representing the question "do you trust that this is actually Bob?". This can't be an interface on the payload channel either. Rationale: during file transfers where Alice sends a file, Alice initiates the channel and Bob responds. We don't want to send the actual file until Alice has had a chance to either say "yes this is definitely Bob" or "I don't care, use a leap of faith". At the same time, we want it to happen (or, in this case, fail) in a finite time if unhandled. > * Because Alice might be planning to authenticate Bob informally > by recognising his voice, the verification channel probably > needs a method with the semantics "not verified, but let > application data flow anyway, and I'll make up my mind > later". I think there are four possible results, although maybe the CM doesn't need to know the difference between the last two, or even the last three: * consider to be unverified and abort * consider to be unverified, but proceed with caution * take a leap of faith, trust that this is really Bob, and store the key for the future (like ssh) * positively identify the peer as Bob and store the key for the future Unless we require/expect users to carry out elaborate key management, we can't assume that a changed cert is *necessarily* bad, either. If I talk to you from my laptop and then from my phone, it's entirely reasonable that they have different keys - so the UI can't scream about it as much as SSH does, and it would not be reasonable for the CM to reject the call from my phone unilaterally. The XTLS draft suggests using XTLS for XML streams, which gives you the ability to do secure key exchange once the XML stream is up (so, in principle, my laptop could tell you "here is the cert from my phone, which is also genuine"). That would require manual key management, though (I'd have to tell Empathy on my laptop about the cert I planned to use on my phone). > * If Bob has configured his CM to always request protection from > active attacks (design question: should this option exist?), > he gets a similar verification channel. If supported, I think this should be a channel (not an interface on the payload channel), for similar reasons. It doesn't necessarily matter for receiving a file, but is significant for Tubes or "reverse file transfer" (requesting a particular file from a peer, which XEP-0234 supports). The use of separate channels is good if you're doing all the cert/key/trust management in a separate application (like the way the Empathy.Auth sub-app handles ServerTLSConnection channels), but not so good if you want to integrate the authentication step into the same UI as the payload channel. I'm not sure how best to deal with that. I think we probably want to guarantee that the payload channel appears first (even though it won't be usable until the TLS and Jingle handshakes have completed), so that the authentication channel can point to it, the UI for the payload channel will already be active, and we can put together some way to tell Mission Control that you want to handle channels fitting a particular description (auth channels in this case) if and only if they point to a channel that you will also be handling. We can't do the "only if related" thing by just adding a channel filter per payload channel, because there are awkward race conditions (MC might process the new filter after it has already dispatched the related channel); it'll have to be some sort of secondary set of filters, or possibly just a second Handler head with OnlyIfRelated=TRUE (where "related" means "points to a channel being handled by the same unique name" or something). (We don't necessarily need to design or implement the "integrate authentication into payload's UI" part immediately, as long as we're confident that we haven't painted ourselves into a corner by making it impossible to implement.) S _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy