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

Thijs Alkemade <thijs@xnyhps.nl> Sat, 24 October 2015 08:55 UTC

Return-Path: <thijs@xnyhps.nl>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3D81B2F37 for <xmpp@ietfa.amsl.com>; Sat, 24 Oct 2015 01:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.083
X-Spam-Level:
X-Spam-Status: No, score=0.083 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsY-BQfE_EeV for <xmpp@ietfa.amsl.com>; Sat, 24 Oct 2015 01:55:29 -0700 (PDT)
Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C6A1B2F35 for <xmpp@ietf.org>; Sat, 24 Oct 2015 01:55:28 -0700 (PDT)
Authentication-Results: xnyhps.nl; dmarc=none header.from=xnyhps.nl
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1445676921; bh=qVT7nrrQdcEGZlVYx4XccWSBC1+nlBNRlmY3zCMC9ws=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=afJpBn3YqWAD7uymWUfXes9SEqlKmhZAR7EC4u+U1RG4/mtlmdFevqsd/gob9cben W3HOi97MCnnwyPJitn4LmhMY2/5JQeeVwNiBI9z8kfrXvJLB5zAkbeGyM3HAizlmKi oV63GFNIyLcvnSxNcm2tMD2o+36JlzzY4x/xdmYM=
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.5.2
From: Thijs Alkemade <thijs@xnyhps.nl>
In-Reply-To: <562AA40E.40407@nostrum.com>
Date: Sat, 24 Oct 2015 10:55:17 +0200
Message-Id: <6340BA7B-A6DD-4F9C-82C3-6B39E97D62D9@xnyhps.nl>
References: <562AA40E.40407@nostrum.com>
To: Adam Roach <adam@nostrum.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/9t-qNxicTDkozFfUKZrcqC6Pt8I>
Cc: Martin Thomson <martin.thomson@gmail.com>, XMPP Group <xmpp@ietf.org>
Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Oct 2015 08:55:31 -0000

> On 23 okt. 2015, at 23:18, Adam Roach <adam@nostrum.com> 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:
> 
> 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

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