Subject: [xmpp] New(ish) draft: Secure Messaging in XMPP

From: Adam Roach <[email-masked]>
Date: Fri, 23 Oct 2015 16:18:06 -0500

XMPP folks:

Martin and I put together a proposal for an approach that allows for 
end-to-end encrypted XMPP conversations, including in the presence of 
MUC. Although not a completely implementable spec, this should give a 
good idea about the direction we have in mind:

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00

Anyone interested in this work should give it a read and provide 
feedback. In particular, I'm curious if anyone interested in 
implementing this kind of thing has requirements can't be addressed with 
the high-level approach we're describing.

Thanks!

/a

---

From: Thijs Alkemade <[email-masked]>
Date: Sat, 24 Oct 2015 10:55:17 +0200

> On 23 okt. 2015, at 23:18, Adam Roach <[email-masked]> wrote:
> 
> XMPP folks:
> 
> Martin and I put together a proposal for an approach that allows for end-to-end encrypted XMPP conversations, including in the presence of MUC. Although not a completely implementable spec, this should give a good idea about the direction we have in mind:
> 
> Anyone interested in this work should give it a read and provide feedback. In particular, I'm curious if anyone interested in implementing this kind of thing has requirements can't be addressed with the high-level approach we're describing.
> 
> Thanks!
> 
> /a

Hi Adam,

I've read through the draft, and there are still some things unclear to me.

Forward secrecy is never mentioned. From the design, I can't tell if it was a
requirement. The symmetric key that is generated in §6.2 can be decrypted by
anyone who has a log of all stanzas and the private Diffie-Hellman key of either
party. The symmetric key has a limited lifetime, but that is not enough if the
DH keys do not expire and I don't see the document mention that they do.

The support for offline messaging is also a bit unclear to me. §6.4 suggests
that a client can send a Symmetric Key Advertisement to a client that is
currently offline. But how would the sender obtain the DH public key for the
recipient if that key is advertised using presence (as stated in §6.1)? The
receiving client would also need to wait for the sender to be online to obtain
its DH public key before it can decrypt the key. (And the sender would be unable
to change their DH key until all advertisements have been acknowledged,
destroying forward secrecy.)

To be honest, I think the current OMEMO draft, while not perfect, matches my
requirements a lot better.

Regards,
Thijs

---

From: Philipp Hancke <[email-masked]>
Date: Sun, 25 Oct 2015 20:57:18 -0700

Am 23.10.2015 um 14:18 schrieb Adam Roach:
> feedback.

quite a number of comments and questions...

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.2.1
   Clients that wish to participate in encrypted messaging publish
   keying material to their presence

we've stopped putting stuff into presence quite a while ago...
See PEP question below. (I assume you don't require compat with ancient 
services like google talk that could never be bothered to implement 
post-2004 features like PEP)

    Each client generates new keying material that is bound to the full
    JID that they use (that is, each client has its own keying material;
    there is no key associated with a user's bare JID).

This is problematic with server-chosen resource parts which change with 
each login. 'static' resources like 'desktop', 'work' or 'iphone' are a 
thing of the past. PEP is likely the answer here.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.2.2

    Prior to sending a message, a client first retrieves and validates
    the presence of the intended recipient.

Can you explain what you mean with 'first retrieves and validates the 
presence of the intended recipient'?

I suspect the presence model you have in mind is not what XMPP commonly 
does... which is 'broadcast' so no retrieval.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.3
    A user founds a MUC in the usual fashion (see [XEP-0045], section
    10.1).  Two changes are made:

broken link. I would also suggest replacing 'founds' with 'creates' for 
consistency of terminology. But that's just me.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.3.1

    The inviting client generates a signed invitation and sends this to
    the bare JID of the offline user

using what key? The bare JID has no key. If not using MAM this message 
might be delivered to the next client that signs on which might not be a 
client that can decrypt the message.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4
   <x xmlns="...identity#assertion">

Can you please use other element names? <x/> is very non-descriptive 
which is the reason that new xmpp extensions don't use this style anymore.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4.1
    The server uses the client's authentication
    credentials, which are usually bound to a connection, to determine if
    the client owns the identifier.

the identifier being [email-masked]/resource?

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4.2
   generates an error, or a message containing the identity.

s/message/result (this refers to an iq-result)

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5

    The routing and message handling information from the cleartext
    (element basename plus to, from, and type attributes)

For <iq/> this should include the id attribute?

    That is, <iq> stanzas produce encrypted <iq> stanzas; <message>

we usually write this as <iq/> and <message/> (also elsewhere)

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.1

    This removes the language indicator from the unencrypted stanza.

Note that the server might re-add the stream's xml:lang when forwarding. 
Not a problem I think, I would just omit the xml:lang in the example. 
It's rarely used anyway.

   To do: check with someone who might know.

should be ignored. Note that the lack of <body/> might affect storage, 
see http://xmpp.org/extensions/xep-0313.html section 5. Also resource 
locking, carbons etc. Multi-client is a hard problem.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.2.3
    Since there is an expectation of reliability and in-order message
   delivery, clients should highlight where message are missing.

This reliability is only partially achieved when crossing s2s. I need to 
ponder more on this.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.3

    A signature on messages is necessary to prevent impersonation of
    other MUC participants.

wait, why is this now talking about MUC again?

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.5
   Encrypting status is highly desirable.

You'll end up encrypting 'user has been unavailable for 15 minutes' -- 
in languages some of the users friends don't even understand. In 
practice few people use the status.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.6
   Thus, clients are required to suppress chat state notifications when
    a peer is offline.

I think that's already in XEP-0085. Since you don't have presence for 
the peer you don't know their chat state support and should not send 
chat states.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-6.1
Please, don't put stuff into <presence/>. Use PEP. You also want to use 
XEP-0335.

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-7
I think using 'roster' here is confusing since that is used in 6121 and 
XEP-0045 for slightly different purposes (neither of which makes any 
assertions about validity).

https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-8

I like the idea. It is better than 'just use sasl anonymous' since the 
server can provide this service only to authenticated clients.
In terms of implementation, I think this better described as an 
xmpp-to-xmpp transport.

There is something here which puzzles me:
   Clients are able to include the new pseudonym in any interaction that
   they initiate

Are you assuming that client that requested this would send stanzas with 
from=[email-masked]/someresource'?

Servers will typically override any client-set 'from' which seems to 
have impact on the crypto scheme you're proposing.

---

From: Florian Schmaus <[email-masked]>
Date: Mon, 26 Oct 2015 18:13:55 +0100

> Anyone interested in this work should give it a read and provide

What Thijs and Philipp said so far.

What's the motivation behind using Presence to announce the Keys? PEP
appears to be a much better choice.

I also think that it should be possible, although very inefficiently in
terms of bandwidth, to design an XEP which uses OMEMO for MUC
encryption. Which makes me wonder what your selling points compared to
OMEMO are?

- Florian

---

From: Florian Schmaus <[email-masked]>
Date: Wed, 28 Oct 2015 13:42:47 +0100

On 28.10.2015 01:41, Martin Thomson wrote:
> On 27 October 2015 at 02:13, Florian Schmaus <[email-masked]> wrote:
>> Which makes me wonder what your selling points compared to
>> OMEMO are?
> 
> It would help to know what OMEMO is.

http://conversations.im/xeps/multi-end.html

The XSF participated this year in Google's Summer of Code. One project
was called "Axolotl support for Conversations". Axolotl is the OTR
competitor designed by the WhisperSystem's people and is used in
TextSecure. Conversations is an open source XMPP client for Android. One
outcome of this GSOC project was the aforementioned OMEMO XEP.

- Florian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 Oct 2015 16:08:30 +0900

On 29 October 2015 at 09:02, Martin Thomson <[email-masked]> wrote:
> I don't think that Axolotl is a good model
> for the general use case.

Since Florian asked nicely, here's the text I wrote about a year ago
regarding PFS:

For a system where the messages are stored, this is largely a
pointless exercise. Destroying the messages is also necessary to
ensure that they cannot be recovered.

We value function over perfect security and consider logging to be a
critical part of a functional chat system.

Furthermore, forward secrecy requires that a round trip between two
parties occurs to establish a properly ephemeral key. This means that
any initial message to any other device either cannot have forward
secrecy, or it cannot include any content. In the latter case, content
could only be carried once the receiving device has replied with their
ephemeral share. (Other systems address this in part by provisioning a
public store with shares ahead of any need for others to use them, but
these systems work poorly in multi-party scenarios.)

In the case where there are multiple agents in a chat - a scenario we
consider to be critical for usability reasons - if any one user agent
is offline, any message encrypted for that agent has to use a key that
can only be unilaterally updated. Messages destined for the offline
agent will necessarily depend on the private keying material on that
agent, which cannot be updated.
<<<

I think that there was a separate note about the value of PFS for some
exchanges.

---

From: Andreas Straub <[email-masked]>
Date: Thu, 29 Oct 2015 19:05:53 +0100

Hi,

I'm the person behind the OMEMO spec, so I'm obviously a bit biased, but
I thought I would weigh in on this specific point.

> ensure that they cannot be recovered.

I feel strongly that there's nevertheless a significant benefit to be
gained from some form of forward secrecy. It's still the difference
between an attacker having to break one secret and being able to decrypt
the entire history, versus having to break one secret per message (or
sub-chain in the axolotl world). I would actually argue that in a
stored-messages scenario, frequent key update is *even more important*,
because the impact of a broken secret can be so much higher.

> (Other systems address this in part by provisioning a

Are there any specific problems with multi-party scenarios you could
elaborate on? We've been using just this approach with OMEMO (and I'd
argue it's been pretty successful so far), so I'd be very interested if
there is something that we've neglected to consider here.

> agent, which cannot be updated.

You make a good point here, in that conversations that involve a device
that is offline for long periods of time must necessarily degrade their
forward secrecy accordingly.  However, this is not necessarily the
average use-case. In fact, its a rare edge case. I would argue that a
protocol which always provides the highest level of forward secrecy that
is possible in any situation is preferable, even if in certain
pathological cases, the security will degrade to a fixed-secret
equivalent level.

> critical part of a functional chat system.

I agree wholeheartedly. People have come to expect such features from a
modern instant messaging service, and rightfully so. But OMEMO actually
achieves these while also providing forward secrecy. I don't think that
we should give up on forward secrecy altogether just because we can't
achieve *perfect* forward secrecy in every situation.

Cheers,
Andy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 30 Oct 2015 06:10:55 +0900

> because the impact of a broken secret can be so much higher.

I think that you will find that the proposed design does have the
ability to perform frequent key updates for both symmetric and
asymmetric keys.  It's just that we don't have anything that would
allow something like the Axolotl per-message switch.

> elaborate on?

Elaboration was in the next paragraph :)  I don't think that there is
much more to it.

> pathological cases, the security will degrade to a fixed-secret

My experience with this is that this is far from unusual, rather that
it is the norm that one or several participants in a discussion are
offline, potentially for extended periods.  The real challenge is in
deciding if you are willing to cut them out of the conversation
entirely at some point.

> achieve *perfect* forward secrecy in every situation.

Ultimately I agree.  I think that the only place we might disagree is
how far toward the ideal we intend to aim.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Oct 2015 09:41:55 +0900

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Oct 2015 09:42:33 +0900

On 24 October 2015 at 17:55, Thijs Alkemade <[email-masked]> wrote:
> Forward secrecy is never mentioned.

I guess the section I wrote up on it was lost.