Re: The ecosystem is moving

Ted Lemon <mellon@fugue.com> Fri, 13 May 2016 17:33 UTC

Return-Path: <mellon@fugue.com>
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 0A8B612D1C7 for <ietf@ietfa.amsl.com>; Fri, 13 May 2016 10:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 Pk3mrUjC7M9u for <ietf@ietfa.amsl.com>; Fri, 13 May 2016 10:33:40 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A39012D1E1 for <ietf@ietf.org>; Fri, 13 May 2016 10:33:40 -0700 (PDT)
Received: by mail-lb0-x22b.google.com with SMTP id ww9so20092077lbc.2 for <ietf@ietf.org>; Fri, 13 May 2016 10:33:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n+CNNfuFz3UJWJWTMUAjMUenyT6wgtnpkYzHYAXGpvk=; b=SK1rog9m3kR8xAfTQGG1boEChRK88xFlTelAZ2d7Ts7tUCAsOK4tR8swRYiooJsVSc pC0HTxqYv8PtvmJeHYQCEEob/KbXgyIIi7O4vX5jCV1yXaJL15VU1GNbG9SPZlEwMI7r M3U2aRwuqW3J+jgEe58gvJcvpzXLD+vE6wn9xLmoCXsDbsakhtYlK1Xuu1HnEB/5JYXs G5AtEeO01laMN7P/9n6EqNq0Jg7Vz98nLZcaGUtCScgicih9khqIL5jt7KuSz5Ex5fJk Vt7ApHmbqcaTsbNhkphgEzSb7xWbIwykxJDs1V3A8P8cdkKWBtsZuumBV/UvQbRslHo8 Mzug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=n+CNNfuFz3UJWJWTMUAjMUenyT6wgtnpkYzHYAXGpvk=; b=IJOymA+jqM9EAf32JxbR3kVoGDA3nvvVJ5aZMjgq8x4Q5bi6fEOycqKc93vUYEyH+M wvLno572AWvC0pTJwck3gdPt3C8wPHi6g8s18yI+x2VwrNvs+Jt18oLHrYN4I7NQgDZt YSV7PnfKDTWoHGI7PycjkpBogNrarxXu92yAvx2BpM+xKhd9bDmZCF9+zJh2vWYS1ptR mzgU2oE1cfXik2WFdanj37S5TnNbIIGJmj84B8sdVbC8N3+BBbKxNYQxth64hb0qOdmE oLUTUQP7AdCmULeNkBzRn9SWeIDoyhdydH+8vi7/z0mz96yAUbFQYJY3FXkDiFLMZA/Y dUDg==
X-Gm-Message-State: AOPr4FVyygGr0o0RlWTtzR+2D9qgs2uqJIq52F+/5tc9TgFfqKRUlFT9p+5KNrG67Ateo4KzlzDj4zo5TrMrgQ==
X-Received: by 10.112.169.8 with SMTP id aa8mr7069228lbc.110.1463160818318; Fri, 13 May 2016 10:33:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.153.135 with HTTP; Fri, 13 May 2016 10:32:58 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.20.1605131301300.10810@bofh.nohats.ca>
References: <20160513165714.035DB1A4B7@ld9781.wdf.sap.corp> <alpine.LRH.2.20.1605131301300.10810@bofh.nohats.ca>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 13 May 2016 13:32:58 -0400
Message-ID: <CAPt1N1=DOL7ysKb0pspZz+EbyVaVn=KCSeqQ=MBBU0vCXDcPpw@mail.gmail.com>
Subject: Re: The ecosystem is moving
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="001a11c3878ad3553a0532bcacf5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/9_nI9jl4EWWkBkz2d8zqm61MBxE>
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:33:43 -0000

I have to agree with Martin's general conclusions here: using XMPP is
really hard, both as an end-user and as a provider.   I am able to get it
working about one out of every three IETFs.  The sticky wicket tends to be
finding a place that will both host my XMPP account _and_ interoperate with
the IETF's XMPP server.

Why doesn't the IETF just operate an XMPP server on which IETF participants
can get accounts?   Layer 9, or is it just really hard?

On Fri, May 13, 2016 at 1:05 PM, Paul Wouters <paul@nohats.ca> wrote:

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