Does anyone have further thoughts on the use of TLS? Peter Saint-Andre wrote:
Forwarding an older message from the [EMAIL PROTECTED] list...-------- Original Message -------- Date: Tue, 13 Feb 2007 14:40:43 -0800 From: Steve Shaffer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Standards] XEP 0124 section 9? I'd like to suggest some clarifications for section 9 (Additional Preconditions) 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? Regards Steve Shaffer
smime.p7s
Description: S/MIME Cryptographic Signature
