[Standards] XEP 0124 section 9?

Steve Shaffer steve at mundialnetworks.com
Tue Feb 13 22:40:43 UTC 2007

I'd like to suggest some clarifications for section 9 (Additional 

Item 1)
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:
Item 2)

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.

Item 3)
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.

Item 4)
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.

Item 5)
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?

Steve Shaffer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070213/ec4d83e2/attachment.html>

More information about the Standards mailing list