IETF Logo Mail Archive

Re: The ecosystem is moving

Paul Wouters <paul@nohats.ca> Fri, 13 May 2016 17:05 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F5F12D610 for <ietf@ietfa.amsl.com>; Fri, 13 May 2016 10:05:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=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 Ue_A3FyYF6uG for <ietf@ietfa.amsl.com>; Fri, 13 May 2016 10:05:17 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3952712D607 for <ietf@ietf.org>; Fri, 13 May 2016 10:05:17 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3r5x7G1CmBz1J6; Fri, 13 May 2016 19:05:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jcQQf5COM_6S; Fri, 13 May 2016 19:05:13 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 13 May 2016 19:05:13 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3FA426721F1; Fri, 13 May 2016 13:05:12 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3FA426721F1
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2E00E40A706C; Fri, 13 May 2016 13:05:12 -0400 (EDT)
Date: Fri, 13 May 2016 13:05:11 -0400
From: Paul Wouters <paul@nohats.ca>
To: Martin Rex <mrex@sap.com>
Subject: Re: The ecosystem is moving
In-Reply-To: <20160513165714.035DB1A4B7@ld9781.wdf.sap.corp>
Message-ID: <alpine.LRH.2.20.1605131301300.10810@bofh.nohats.ca>
References: <20160513165714.035DB1A4B7@ld9781.wdf.sap.corp>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/8DVRepvvuwu8Zeth8hysIrHXZ0M>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, "ietf@ietf.org Discussion" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2016 17:05:19 -0000

On Fri, 13 May 2016, Martin Rex wrote:

> IMO, Moxie points to a number of real problems, but I think his
> conclusions about the causes are wrong.

I agree.

> Well, getting a jabber client _with_ support for TLS turned out to
> be another royal PITA, because it wasn't available for my old Linux
> distro, and compiling it my self would have required to obtain and
> compile at least three dozen other libs and toolkits it depends upon,
> and what my existing Linux distro had was "too old".

That must have been an epicly old server because I've been using pidgin
with TLS for many years.

> I only wanted to join IETF meetings remotely, and they're public anyways,
> so I was just fine without TLS and my old client, but the XMPP freaks
> running this stuff seemed to be fiercly determined of breaking backwards
> compatibility just for the fun of it, giving a shit about their users,
> similar to the developers of the newer client software, which gave a shit
> about compiling the client software on a 5 year old linux distro.

Not "just for the fun of it", but specifically for RFC-7258

> There things that WhatsApp achieved in a straightforward and
> user friendly manner:
>
>   - signing up as a new user is *EASY*
>
>   - getting the newest of their client software for a 5+ year old
>     Android (e.g. Android 4.1) is no more difficult that getting
>     it for bleeding edge OS releases
>
>   - Interoperability with installed base was not impaired when
>     rolling out the encryption-enabled clients

And a day after the announcement I tried this with a friend of mine. We
both updated Whatsapp, and we ended up with my client saying "chats are
now encrypted" and the other endpoint saying "chats are not encrypted,
the other end needs to upgrade". Two days later this problem
automagically solved itself without an app update on either end.

How could an end-to-end encryption fail in such a way? There is either
some really untrusted GUI code lying, or some server-based "trusted"
MITM happening here.

Paul

v2.23.0 | Report a Bug | By Email