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

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Nov 2015 15:39:10 +0100

Martin Thomson <[email-masked]> writes:

> 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.

I believe there is a logical mistake here -- supporting logging does not
mean you cannot support forward security.  I'm firmly on the side that
logging is an essential property of a chat system that I would use,
however I acknowledge that NOT logging is an essential property of a
chat system some other people would use.  While forward security is less
critical to the first category (something I'm not sure I would agree
with fully), it appears essential to the second category.  A system that
supports forward security appears more general to me than one that
doesn't.

I would welcome a detailed analysis of pro's and con's between this
proposal and OMEMO, to identify if there is anything the OMEMO approach
could learn and pick up from this approach.

/Simon

> 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: Bartosz Małkowski <[email-masked]>
Date: Thu, 5 Nov 2015 09:42:04 +0100

Hi!

I’m curious why IQ stanzas should be encapsulated into IQ stanzas instead of Message stanza.
I think that any kind of stanza what should be protected by e2e encryption should be encrypted and encapsulated with Message stanza. Then this Message is only transport layer.

--
Bartosz Małkowski
Tigase Polska
xmpp:[email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Thu, 5 Nov 2015 09:46:42 +0000

On 5 November 2015 at 08:42, Bartosz Małkowski <[email-masked]> wrote:

> I think that any kind of stanza what should be protected by e2e encryption
> should be encrypted and encapsulated with Message stanza. Then this Message
> is only transport layer.
>
>
I think you want stanzas to be encapsulated as the same stanza in order to
maintain the same semantics on, for example, routing, error handling, etc.

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>
>

---

From: Bartosz Małkowski <[email-masked]>
Date: Thu, 5 Nov 2015 11:11:38 +0100

> Wiadomość napisana przez Dave Cridland <[email-masked]> w dniu 05.11.2015, o godz. 10:46:
> 
> I think you want stanzas to be encapsulated as the same stanza in order to maintain the same semantics on, for example, routing, error handling, etc.

My point of view is, that envelope is just an envelope and shouldn’t be related to content.

If I want to send <iq type=„set” id=„1"> then I just send:

<message to=„X" >
  <encrypted xmlns=„…”>
    enc(<iq to=„X” type=„set” id=„1”></iq>)
  </encrypted>
</message>

and in response I will receive

<message from=„X" >
  <encrypted xmlns=„…”>
    enc(<iq from=„X” type=„result” id=„1”></iq>)
  </encrypted>
</message>

In case of using IQ envelope for IQ stanzas: what type of stanza should have envelope if response type is error? Also error?

<iq type=„error” from=„X” id=„1">
  <encrypted xmlns=„…”>
    enc(<iq type=„error” from=„X” id=„1"/>)
  <encrypted>
</iq>

I think that envelope should be independent from content. Let it be IQ stanza or Message stanza, but the same type of envelope for all type of contents.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 8 Nov 2015 22:33:21 -0800

> My point of view is, that envelope is just an envelope and shouldn’t be related to content.

I would have suggested that if it weren't for the reason Dave
identified.  Routing rules in XMPP are a little more complicated than
might be ideal.  message and iq are not routed consistently, nor do
they receive the same store-and-forward treatment.