[Standards] XEP 0124 section 9?
steve at mundialnetworks.com
Tue Feb 13 22:40:43 UTC 2007
I'd like to suggest some clarifications for section 9 (Additional
In paragraph 1 second (last) sentence might be clearer if it read:
"However, before processing XML stanzas from the client, the connection
manager, MUST require /the server and client complete the /additional
preconditions/ /using either of the following methods:
I'd like to understand the recommendation against TLS negotiation
between the server and the client. Doesn't having a two TLS connections
(Server to connection manager and connection manager to client) make the
connection manager a tempting injection point for MITM attacks since the
connection manager must decrypt and re-encrypt data? While using
multiple encryption methods can sometimes lead to unpredictable results,
using TLS twice should be safe in this context.
I'd also suggest t the connection manager SHOULD reject https connection
requests if the connection manager can not establish a secure connection
to the server. Otherwise the browser based connections may appear to be
secure even when the XML stanzas are passed in the clear between the
connection manager and the server.
I suggest deleting 9.1 and 9.2 altogether as it implies the connection
manager is responsible for authentication not the server. I assume the
examples are to assist HTTP based client development. Referring the
reader to the appropriate sections of 3920 and 3921 might be better or
at least explicitly stating that the contents of the body wrapper are
forwarded to and from the server unaltered and that all errors are
communicated at the XMPP stanza level not in the HTTP responses.
Section 17 last paragraph does address the extreme end of protecting
communications however as XEP-0116 points out end to end encryption
capability has limited deployment in both XMPP components and clients.
Also HTTP clients are probably not able to detect if a connection
manager is a 'proxy' or an extension of a server.
A HTTP client can however detect if TLS negotiation with the server
succeeds or fails.
TLS session negotiation, while nowhere near as secure as an 'Esession'
and does not provide protection within the server, is at least commonplace.
Hence I'd recommend removing the admonishment against stream level TLS
in section 9 and advocate for it in section 17.
What have I missed?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards