Re: [xmpp] End-to-End Encryption Milestone

Dave Cridland <> Tue, 25 February 2014 13:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 781E21A06D8 for <>; Tue, 25 Feb 2014 05:26:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.322
X-Spam-Level: *
X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ze4-s36FjvWP for <>; Tue, 25 Feb 2014 05:26:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c02::229]) by (Postfix) with ESMTP id C144B1A06D2 for <>; Tue, 25 Feb 2014 05:26:57 -0800 (PST)
Received: by with SMTP id o6so372558oag.28 for <>; Tue, 25 Feb 2014 05:26:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UbK8Cuaz2JBSZX05Avl6w2tWq3zbtrdojQpCI7llb+Q=; b=TiFiViZEHcgr8l4dohqoMC06kYJ/+zCEkneDbrYzwL8d1yAz6o8hAaWCZRo46bUrNU M2eBCABMiRieR7zSd8Krto37uN3MQnSjhQaYWjeXE9rcCmA1G27g+zyoJicp49nbVGJS J/fK3aIkkasQLXrqgIAmij22E+SoXivyrl+BY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UbK8Cuaz2JBSZX05Avl6w2tWq3zbtrdojQpCI7llb+Q=; b=fWcO766R/hz4TI/Hb+8xOBqbwf9FtDEuay/93zbVhaftfUsTlAXgr5eYj3S1BG7tNv d3hBxN1b/i6nMSK+J5Je9Ixk/Xw9y3Xwprma+SL8AyQXGdmVEuYVsJVsQIwP2V2VOY+M 5ucuP4ax706Tk9peI/BQ/y8RaOtuabmcbvTTagJdkCNtbcgNeYJzD6Q+ET0Pj5anp6Vi pmM/HkI8P4mtUiOoHMYDLmzZmwUpKs8scwwymJp51jE/h6kR4jZgoG9G4nXkGNRobBK3 gGYOer+qapWYanFy536owYjw7m1da6RVSB5j4xAb3PByM9NCVv/u200kJtKmfESICelz AQdA==
X-Gm-Message-State: ALoCoQlgbuMFeqkLuDctCPYYjzTjcvJjo5HlYf4xZZ67t0Ynhce4LtHX5pxoL6UnuYENrInmg4Ua
MIME-Version: 1.0
X-Received: by with SMTP id bk19mr1248481oec.46.1393334816816; Tue, 25 Feb 2014 05:26:56 -0800 (PST)
Received: by with HTTP; Tue, 25 Feb 2014 05:26:56 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 25 Feb 2014 13:26:56 +0000
Message-ID: <>
From: Dave Cridland <>
To: Tobias Markmann <>
Content-Type: multipart/alternative; boundary=089e01184baecf538c04f33b0ab2
Cc: Ben Campbell <>, XMPP Working Group <>
Subject: Re: [xmpp] End-to-End Encryption Milestone
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Feb 2014 13:26:59 -0000

On Tue, Feb 25, 2014 at 12:11 PM, Tobias Markmann

> I think what's really needed is some kind of overview/comparison document
> about that current status. While the current requirements document is a
> start in listing some potential requirements, modern IM use cases are a bit
> more complex, w.r.t. multi-device and the mobile application scenarios.
> So basically a document that compares existing proposals, like OTR, PGP,
> XTLS and maybe even some more general e2e IM security solutions like the
> TextSecure protocol or multi-party OTR, and analyze those regarding their
> security, support for PubSub/MUC, support for offline messages, support for
> multi-device usage, and possibly even more.
That sounds really useful. I suspect that:

a) Even quite experienced XMPP developers probably don't know what's on
offer, and what they provide.

b) It'd help focus discussion enormously, by enumerating the requirements

> On Tue, Feb 25, 2014 at 12:23 PM, Dave Cridland <> wrote:
>> Doing it within the XSF would *possibly* be simpler in terms of process.
> Indeed. I don't know if the IETF is the right place for a status quo
> comparison document or if it'd be more attractive within the XSF with less
> process. I for one would gladly review and try to contribute as much as
> possible to such document. Reviewing current proposals and exposing their
> advantages and shortcomings, especially regarding multi-resource and
> offline usage, would be a great way to start looking for possible solutions
> for XMPP.
A comparison document such as you're suggesting could probably be done as
either; the process overhead isn't important either way. I suspect that
longer term, it'd be nice to maintain it (unless we think we'll find the
Final and Ultimate Solution to Encryption (FUSE), in which case it'll be
only useful as a snapshot.

If we want a "living document", then the XSF affords us that relatively
easily, whereas if we did it as an I-D, I wouldn't press for publication as
an RFC at all. In that sense, it'll be lower process within the IETF.