On 12/06/12 14:42, Simon McVittie wrote: > There are two broad use-cases: Text, and the rest. In this mail I'm only > going to consider the non-Text case, because Text is more complicated.
OK, so how does this change for Text? Because I'm mainly interested in securing non-Text at the moment, what I'm mainly trying to do here is to check that I haven't accidentally made e2e security for Text, with OTR and/or XTLS, impossible. Odd things about Text ===================== One thing that's different about Text (in XMPP, IRC, SIP and probably many more) is that the Telepathy Channel is, in some sense, artificial. Each message is an individual protocol transaction, and we group them into a Channel for convenience. Another is that there are (at least) two viable ways to secure Text in XMPP, namely XTLS (as applied to an end-to-end XML stream, as suggested in its RFC draft) and OTR. XTLS uses the extension mechanisms provided by XMPP, whereas OTR operates in a different layer. If each of XTLS and OTR has advantages over the other, we get into a problematic situation where choosing which one to use is difficult, because we have to know in advance which security properties the user prefers. Luckily, I don't think we have to do that: XTLS seems to have all the desirable properties of OTR, except possibly "strong deniability" (and as I said in an earlier email, I don't see how its version of strong deniability is actually any better than what you get from XTLS). If that wasn't the case, I think the solution would be to enhance one of the protocols (in the case of XMPP my choice would be XTLS, because it preserves extensibility) so that it has whatever properties are missing, so that we can unambiguously declare it to be "better" if both are supported. We should still support OTR for interop with other clients, though. Start of session ================ When starting a session, we have the same choices as for non-Text, except that we also get to decide whether to use XTLS or OTR, or just send plain-text messages. If the user has configured "no opportunistic security, please" (i.e. they want server-side logging) then we use plain-text messages and it degrades to the current situation. If we can do standard XMPP capability discovery (roughly: the peer is on our contact list and this isn't a limited, non-XMPP server like Facebook or MSN) we can know whether they support XTLS. If we can't do capability discovery, or they don't support XTLS, perhaps we can know (via OTR's ingenious whitespace hack) that they support OTR. I don't think interactively asking the user "should I use XTLS, OTR or neither?" whenever they initiate a chat is appropriate, so let's not do that. Authentication ============== If we've initiated a secure session (either XTLS or OTR) we can behave a lot like the non-Text sessions I described in a previous mail - start off secure against passive attackers, with the option to become secure against active attackers. All good. The next point of difference is that instead of certificates or SRP, OTR offers raw keying material or the "Socialist Millionare's Protocol". One way to deal with OTR keys would be to consider the OTR public key and fingerprint formats (as described in "Public keys, signatures and fingerprints" in OTR Protocol v2-3.1.0) to be a third "certificate" format, alongside our existing "x509" and "pgp" formats, and do certificate exchange in the same way we'd exchange self-signed X509 certificates. SMP requires each participant to enter a secret, and then checks that they entered the same secret, whereas SRP requires one participant to enter a username and password, then has the other verify it - so they're structurally different, and should be different interfaces (or possibly different channel types). Upgrading to protected ====================== The next point of difference is if we want to upgrade from an unprotected channel to a protected one. I see two ways we could do this: Upgrading --------- Short version: "the unprotected Channel becomes protected". More specifically, have the Securable interface on every payload Text channel, whether it's protected or not. In an unprotected channel, every security property will be FALSE (although I suppose if there's a property for "at least as secure as in-band" - which would be FALSE in current RTP calls, for instance - then that one will be TRUE, because basic Text messages *are* in-band). When a protected Jingle or OTR session is negotiated, attach it to the previously-unprotected Channel, and flip some of the "security property" bits to TRUE. All subsequent messages sent in that Channel go through the protected session. To upgrade the unprotected Channel to protected, you would have to call a method on that Channel (probably on the Securable interface) listing security properties you wanted to insist on. If an unprotected message is received while negotiating a protected session, there's an undesirable ambiguity: was that message protected? It comes down to timing, which is subtle. It gets particularly subtle if you can still receive unprotected messages - perhaps from another resource - after the protection has been negotiated. See "Downgrading to unprotected", below, for correct handling. This does have the advantage of avoiding having two parallel Text channels with TargetHandle = Bob, in common situations. However, that can't be avoided in corner cases (see "Downgrading to unprotected") so I don't think it's worth putting effort into reducing it. A naive (non-Securable-aware) UI would provide continuity here, by continuing to use the same window/tab for all of the messages. I'm not sure whether that's an advantage or not. Replacing --------- Short version: "have the protected session be a separate Channel". When a protected Jingle or OTR session is negotiated, create a new Channel, with some of its Securable "security property" bits TRUE (probably everything except Verified, in practice). It could have a reference to the old unprotected Channel (much like upgrading 1-1 Text to a Conference), or that could be implied by being 1-1 with the same target handle. Optionally still have the Securable interface on unprotected Text channels anyway, but the "security bits" will all be FALSE and can't become TRUE. (I think we might want this so that Encrypted=FALSE can be requestable, for people who want to insist that a particular channel is server-side-loggable?) A naive (non-Securable-aware) UI would either mix the unprotected and protected channels into the same window or tab (if it ignores Channel boundaries and distributes messages by target handle), or put the protected session in a new window or tab (which has some advantages, to be honest - it makes it more obvious where you're typing!). A Securable-aware UI would have to respect Channel boundaries anyway, since the Securable properties are per-Channel. This has the disadvantage that you get more than one Text channel with the same Contact TargetHandle - but in the situations below I don't think that's avoidable, so, we'll have to live with it. It has the advantage that it maps 1:1 to what will happen with Call, StreamTube, FileTransfer channels, where each channel is either unprotected or protected, and they never change state (except for Verified which is special). The reason I think it's OK for verification to be special is that it can be somewhat retroactive. If Alice and Bob establish an encrypted channel and send some inconsequential messages, then perform a verification handshake before saying anything actually secret, then those inconsequential messages were, in fact, just as secure as the secret messages they send later - they just didn't know it yet! Downgrading to unprotected ========================== Given a protected Channel, it might seem a stupid idea to downgrade, but in practice it'll happen, and we need to make sure it's obvious and non-damaging. In XTLS, nothing stops you from holding two entire conversations, one in the protected XTLS channel and one in-band and unprotected. If we don't forbid this entirely, they should be parallel Channels - given any Channel, it should be instantly obvious whether messages are protected or not. You certainly shouldn't have to look at each individual message, I don't think. (It might be useful for loggers if we *also* copy the current security properties into each message's header, though.) In OTR, the OTR conversation is in-band (it's basically just Base64 wedged into text messages). I assume that once OTR has got started, messages that aren't valid OTR are considered to be an error, but on balance it seems better to show them to the user (with a big fat warning that the text is no longer authenticated) than not. XMPP has the additional quirk that you can have multiple resources. If Alice has an OTR or XTLS conversation with Bob from her laptop, which is idle but being "kept alive", it seems entirely valid for Alice to initiate a separate unprotected conversation with Bob, perhaps from a mobile phone which can't do OTR or XTLS. (I wonder whether the Pidgin reference implementation of OTR knows about resources?) It would be Badâ„¢ for a Channel's security to drop (race condition between Bob reducing the Channel's security, and Alice pressing Send on a sensitive message), so whenever a less-secure conversation starts, I think that should be a separate Channel. I think this is an argument in favour of the "replacing" model for upgrades, to make it symmetrical - every time there's a change in security level (except for verification which is special), there's a new channel. We could consider making it impossible to send unprotected messages while a protected conversation with the same peer exists (by making SendMessage suppress the <message> and report a temporary delivery failure). I think this would have to be per-resource, for the "non-OTR-capable phone" use-case above - Bob's IMs to Alice's phone aren't going to be e2e secured, but perhaps he doesn't care. If we *receive* an unprotected message - even at an unexpected time in the protocol, like halfway through an OTR conversation - I don't think there's any justification for not displaying it ("destroying information is bad"), but we do need to make it absolutely clear that it's unprotected and could be the result of tampering. I think it's enough to separate it into a separate Channel lacking the "this is protected" indicator, and write this into the spec: When a UI handling a Channel is asked to handle a less secure Channel with the same peer, it MUST separate it from the old Channel as much as it would for a channel whose peer was different (e.g. putting it in a separate window or tab). If it is asked to handle an equally secure or more secure channel with the same peer, it MAY separate that from the old Channel in the same way, or handle it in the same context (e.g. the same window or tab). When a UI establishes a secure Channel, it MUST Close any less secure Channels that it was handling in the same context (e.g. window or tab), so that if more messages from the peer arrive, they are placed in a separate context. | In a typical UI this results in obvious visual separation | between the protected messages and any further unprotected | messages (which could either be authentic, or from an | attacker). No messages will be lost, because if there | are unacknowledged messages when the unprotected Channel | emits Closed, the connection manager will "reopen" that | Channel, resulting in a new UI context to display them. I think this has addressed all the differences between Text and other channels, unless anyone can point out more? S _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy