Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02

Ben Campbell <ben@nostrum.com> Wed, 23 April 2014 19:24 UTC

Return-Path: <ben@nostrum.com>
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 003571A049A for <xmpp@ietfa.amsl.com>; Wed, 23 Apr 2014 12:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham
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 GJ9z2HrjwsGt for <xmpp@ietfa.amsl.com>; Wed, 23 Apr 2014 12:24:38 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA2F1A04FA for <xmpp@ietf.org>; Wed, 23 Apr 2014 12:24:36 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3NJOQdw006797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 23 Apr 2014 14:24:28 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net>
Date: Wed, 23 Apr 2014 14:24:27 -0500
X-Mao-Original-Outgoing-Id: 419973867.001563-8945aade8d22b9522e301c8d643e0abb
Content-Transfer-Encoding: quoted-printable
Message-Id: <6322B641-3846-4A62-9BBC-0A8A30F50DE6@nostrum.com>
References: <F8275190-9346-4879-9843-A3DF6C604F8C@nostrum.com> <9372C947-DE5D-4115-B1DD-3E1D216C9D62@nostrum.com> <9D46867E-ADA1-4530-AF23-B43AC6E68B3E@andyet.net>
To: Lance Stout <lance@andyet.net>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/lXRuHRFEEibyFNBgl5gu8HJpQLE
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02
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: <http://www.ietf.org/mail-archive/web/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: Wed, 23 Apr 2014 19:24:40 -0000

On Apr 22, 2014, at 6:29 PM, Lance Stout <lance@andyet.net> wrote:

> 
> On Apr 22, 2014, at 2:49 PM, Ben Campbell <ben@nostrum.com> wrote:
>> 
>> The WGLC has completed. Authors, please let the list know when you believe all feedback has been addressed. (Note: "addressed" does not necessarily mean "accepted".)
> 
> Draft -06 has been published, which I believe addresses all feedback so far.
> 
> 
> I note there is a pending question on connection managers, but I don't believe that the use of a connection manager affects any of the actions prescribed in the latest document. CMs should be transparent.
> 
> 
> We do have Security Considerations listed in XEP-0124 for BOSH connection managers, which amount to 'use TLS from the CM to the backend', and 'use e2e encryption on the client' because guaranteeing anything about a CM's behaviour is beyond scope. I can expand the Security Considerations for this document to do the same, if people deem that necessary.

So here's the basis of all of my connection manager questions. This may be based on a completely wrong understanding of connection managers on my part, so do not hesitate to tell me I am clueless if that's the case. :-)

If an XMPP implementation, especially a server, is behind a connection manager, is it aware of that fact? Is it assumed to implement this draft? Are we requiring special behavior of the server, without the server knowing it needs to do it?

If the answer is yes, then I may have concerns in two areas:

1) Is the connection manager expected to "adapt" server behavior to follow this draft?

2) What is the impact of adding a new TLS intermediary, when the server expects a direct SA with the client? Your comment above _might_ be sufficient, but is there any plain vanilla XMPP server behavior and/or security assumptions that break down? Any concerns from a SASL perspective?