Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
Thanks for the feedback. On Tue, Jun 4, 2013 at 10:41 PM, Peter Saint-Andre stpe...@stpeter.imwrote: On 2/20/13 5:43 PM, XMPP Extensions Editor wrote: 5. Is the specification accurate and clearly written? I have several questions: Section 2.1: If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). Is there any reason why the should is not a MUST? It's a should not a SHOULD, too. While I don't think it'd be useful, I don't think it raises an interoperability concern. For instance, a server could suggest bidi after some traffic has flowed, and if the peer starts sending traffic back, great - if not, nothing's lost. As such, RFC 2119 language would seem inappropriate. Section 2.2: This isn't really negotiation, is it? More like simply enabling the feature (no parameters negotiated etc.). If I'm to be pedantic, I might suggest this is really a feature offer, and neither enabling nor negotiating. Happy to pick a term and stick to it throughout, but I'd note this is splitting hairs. Section 2.2: To enable bidirectional communication, the connecting server sends a bidi/ element qualified by the 'urn:xmpp:bidi' namespace. This SHOULD be done before either SASL negotiation or Server Dialback. Why is this not a MUST? I don't see what good it would do to negotiate / enable bidi after SASL negotiation or server dialback. As above - this shouldn't be SHOULD, but is typically or some such. Section 2.2: Also note that the receiving server MUST only send stanzas for which it has been authenticated - in the case of TLS/SASL based authentication, this is the value of the stream's 'to' attribute, whereas in the case of Server Dialback this is the inverse of any domain pair that has been used in a dialback request. This is already covered by RFC 6120 and XEP-0220. Does it need to be reiterated here? Yes, I thought so at the time. The distinction between what RFC 6120 and XEP-0220 says is in the direction. Section 3 has C: and S: but these are both servers. It might help to change them to S1 and S2 or I and R. Yes, R and I seem sensible. Add the TLS negotiation after proceed/ for Example 3 and Example 4? OK I think Example 5 is OK but I think it's mislabled (it's really about piggybacking / multiplexing, not stream setup before TLS as far as I can see). I'll take a look.
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
On 6/4/13 11:51 PM, Michal 'vorner' Vaner wrote: Good morning I did not write the XEP, not really read it whole, but from common sense: On Tue, Jun 04, 2013 at 03:41:34PM -0600, Peter Saint-Andre wrote: Section 2.1: If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). Is there any reason why the should is not a MUST? I can imagine a server not wanting to enable it for some domains and enable it for others. In such case, it would send the feature to those it wants it enabled for. Sure, that makes some sense. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/20/13 5:43 PM, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0288 (Bidirectional Server-to-Server Connections). Abstract: This specification defines a protocol for using server-to-server connections in a bidirectional way such that stanzas are sent and received on the same TCP connection. URL: http://xmpp.org/extensions/xep-0288.html This Last Call begins today and shall end at the close of business on 2013-03-19. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. 3. Do you plan to implement this specification in your code? If not, why not? I don't have any server code in which to implement it. 4. Do you have any security concerns related to this specification? No. 5. Is the specification accurate and clearly written? I have several questions: Section 2.1: If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). Is there any reason why the should is not a MUST? Section 2.2: This isn't really negotiation, is it? More like simply enabling the feature (no parameters negotiated etc.). Section 2.2: To enable bidirectional communication, the connecting server sends a bidi/ element qualified by the 'urn:xmpp:bidi' namespace. This SHOULD be done before either SASL negotiation or Server Dialback. Why is this not a MUST? I don't see what good it would do to negotiate / enable bidi after SASL negotiation or server dialback. Section 2.2: Also note that the receiving server MUST only send stanzas for which it has been authenticated - in the case of TLS/SASL based authentication, this is the value of the stream's 'to' attribute, whereas in the case of Server Dialback this is the inverse of any domain pair that has been used in a dialback request. This is already covered by RFC 6120 and XEP-0220. Does it need to be reiterated here? Section 3 has C: and S: but these are both servers. It might help to change them to S1 and S2 or I and R. Add the TLS negotiation after proceed/ for Example 3 and Example 4? I think Example 5 is OK but I think it's mislabled (it's really about piggybacking / multiplexing, not stream setup before TLS as far as I can see). Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrl8NAAoJEOoGpJErxa2pndoQAJfGfuToD7EOK6CsE2D9fVwH 5POwGSEbqGES74TrS+ditlGwCYgT5oaf73Lru8xHj6vHO/+98qD7ryXzJzEjGKqA 4liakwBUeS6IDESX54HaKyGXp+urrXkymswm9O3vylDN+gmONBiOtW1LF6oS8/50 UXNK0m9ShmC26psiJlSHXnKk+3akxXgOGZrE/ql4RO4hw8zs2ZCQvP2g823zipF6 k2oy0ZN9zBFXZjsFqKIEa5BivT4TLYpk9kQpE6vEAd2Qg9gBQWkg4Hx5zfnLVaWd DKpkKJGVlt0JR/PIz3RV35zZPXNXRvKt2V7NGtSQg5eMcmVyQ7k6UosD+NR2bu/O wblAzj1+LU0ruQkI3Keq6pdGjaF10i8tUtlzcWJKI6qTZKe31TJVzew0sFPX0LXs VEug7hPl9LiUxpNatTBdGcksIfkKBggQdiVKRURuefRw9spJmn0QQXwJLfTqKb4E bqnq4CVyeKceM1im8o6vM6XszGgVrZ/qavdWpKijTXEyShGNM3w0tuKR24crr6Lo 9pLDVC2AEdAQNOtreOT5V3IWjHbi8VX6+Xj08g5D7K0LFw3tUSyRRyxw3VnJQzaD +K2diOqaBvkse0t+3t930ocKoEabx0b03UXoTJJXOPhxg8UOmGbiNPynFme3IR82 gLtPOA+BS3LgpnPAkSK/ =hsP4 -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
Good morning I did not write the XEP, not really read it whole, but from common sense: On Tue, Jun 04, 2013 at 03:41:34PM -0600, Peter Saint-Andre wrote: Section 2.1: If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). Is there any reason why the should is not a MUST? I can imagine a server not wanting to enable it for some domains and enable it for others. In such case, it would send the feature to those it wants it enabled for. With regards -- Anyone who goes to a psychiatrist ought to have his head examined. -- Samuel Goldwyn Michal 'vorner' Vaner signature.asc Description: Digital signature
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
Am 08.04.2013 18:45, schrieb Philipp Hancke: Am 19.03.2013 02:49, schrieb Kim Alvefur: 4. Do you have any security concerns related to this specification? The elevation of any method of domain spoofing to also include possible interception of outgoing stanzas. Mistakes by, or compromise of a CA, faulty certificate validation etc might make it possible to do a MITM without needing to do anything DNS related. [...] Does the following paragraph address this? compromised is vage on purpose, thanks Dave. Note that bidirectionality may broaden the impact of an attack that allows spoofing of XMPP stanzas (such as the unsolicited server dialback attack described in XEP-0220 or the usage of compromised certificates) by delivering stanzas to the wrong target. Patch attached, thanks zash. diff --git a/extensions/xep-0288.xml b/extensions/xep-0288.xml index 293f96f..52b578a 100755 --- a/extensions/xep-0288.xml +++ b/extensions/xep-0288.xml @@ -34,6 +34,12 @@ jiddave.cridl...@isode.com/jid /author revision +version0.5/version +date2012-08-10/date +initialsph/dwd/initials +remarkpAdditional security considerations about the quot;unsolicited dialbackquot; attack on bidirectional connection./p/remark + /revision + revision version0.4/version date2012-07-23/date initialsph/initials @@ -212,7 +218,7 @@ C: db:result from='capulet.lit' to='conference.montague.lit' type='valid'/ section1 topic='Security Considerations' anchor='security' pThis specification introduces no security considerations above and beyond those discussed in citeRFC 6120/cite or citeXEP-0220/cite. !-- one might explain why not... http://mail.jabber.org/pipermail/xmppwg/2004-February/002026.html -- - Note that when using Server Dialback, a server must be very careful when receiving a lt;db:result/gt; of type 'valid' without having sent a corresponding request to add the domain pair given by the 'from' and 'to' attributes. In particular it MUST NOT route stanzas to the domain given in the elements 'from' attribute over this XML stream without further proof of the peers identity./p + Note that the impact of the quot;unsolicited server dialbackquot; attack described in citeXEP-0220/cite is considerably larger for bidirectional streams, e.g. a vulnerability which allows spoofing might also route messages to the wrong targets. Additionally, dialback elements with a quot;typequot; attribute also need to be handled in incoming connections./p /section1 section1 topic='XMPP Registrar Considerations' anchor='registrar' section2 topic='Protocol Namespaces' anchor='registrar-ns'
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
Patch attached, thanks zash. hrmpf, wrong patch, even though git should handle that gracefully. This one is right. diff --git a/extensions/xep-0288.xml b/extensions/xep-0288.xml index b94baf1..6d3b2f6 100755 --- a/extensions/xep-0288.xml +++ b/extensions/xep-0288.xml @@ -220,7 +220,7 @@ C: db:result from='capulet.lit' to='conference.montague.lit' type='valid'/ section1 topic='Security Considerations' anchor='security' pThis specification introduces no security considerations above and beyond those discussed in citeRFC 6120/cite or citeXEP-0220/cite. !-- one might explain why not... http://mail.jabber.org/pipermail/xmppwg/2004-February/002026.html -- - Note that the impact of the quot;unsolicited server dialbackquot; attack described in citeXEP-0220/cite is considerably larger for bidirectional streams, e.g. a vulnerability which allows spoofing might also route messages to the wrong targets. Additionally, dialback elements with a quot;typequot; attribute also need to be handled in incoming connections./p + Note that bidirectionality may broaden the impact of an attack that allows spoofing of XMPP stanzas (such as the unsolicited server dialback attack described in citeXEP-0220/cite or the usage of compromised certificates) by delivering stanzas to the wrong target./p /section1 section1 topic='XMPP Registrar Considerations' anchor='registrar' section2 topic='Protocol Namespaces' anchor='registrar-ns' @@ -242,6 +242,6 @@ C: db:result from='capulet.lit' to='conference.montague.lit' type='valid'/ pThis document requires no interaction with IANA;./p /section1 section1 topic='Acknowledgements' anchor='ack' - pThanks to Justin Karneges and Torje Henriksen./p + pThanks to Justin Karneges, Torje Henriksen and Kim Alvefur./p /section1 /xep
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
I'm good with that. On 23 Apr 2013 13:10, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 08.04.2013 18:45, schrieb Philipp Hancke: Am 19.03.2013 02:49, schrieb Kim Alvefur: 4. Do you have any security concerns related to this specification? The elevation of any method of domain spoofing to also include possible interception of outgoing stanzas. Mistakes by, or compromise of a CA, faulty certificate validation etc might make it possible to do a MITM without needing to do anything DNS related. [...] Does the following paragraph address this? compromised is vage on purpose, thanks Dave. Note that bidirectionality may broaden the impact of an attack that allows spoofing of XMPP stanzas (such as the unsolicited server dialback attack described in XEP-0220 or the usage of compromised certificates) by delivering stanzas to the wrong target. Patch attached, thanks zash.
Re: [Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
On 2013-02-21 01:43, XMPP Extensions Editor wrote: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. 3. Do you plan to implement this specification in your code? If not, why not? I have written an implementation for Prosody. http://prosody-modules.googlecode.com/hg/mod_bidi/ 4. Do you have any security concerns related to this specification? The elevation of any method of domain spoofing to also include possible interception of outgoing stanzas. Mistakes by, or compromise of a CA, faulty certificate validation etc might make it possible to do a MITM without needing to do anything DNS related. 5. Is the specification accurate and clearly written? Yes. -- Kim Zash Alvefur signature.asc Description: OpenPGP digital signature
[Standards] LAST CALL: XEP-0288 (Bidirectional Server-to-Server Connections)
This message constitutes notice of a Last Call for comments on XEP-0288 (Bidirectional Server-to-Server Connections). Abstract: This specification defines a protocol for using server-to-server connections in a bidirectional way such that stanzas are sent and received on the same TCP connection. URL: http://xmpp.org/extensions/xep-0288.html This Last Call begins today and shall end at the close of business on 2013-03-19. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
