[Standards] XEP-0191: Simple Communications Blocking
Hi, XEP-0191: Simple Communications Blocking http://xmpp.org/extensions/xep-0191.html IMHO, as a non-english native (o not), the mapping with Privacy lists (XEP-0016) needs a little bit of clarification: A service SHOULD map the blocklist to the default privacy list, where each blocked JID is represented as a privacy list item of type jid and action deny. [4] If this is done and none of the user's clients ever use the privacy lists protocol, then the blocklist will always apply. The priority of blocked (jid+deny) items in the privacy list SHOULD be such that they come first in the privacy list. Is it a question of message, presence (in/out) or iq? Or all stanza types? Nÿco -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr http://linuxfr.org/ - http://fr.wikipedia.org/ - http://www.jabberfr.org/ - http://qsos.org/ Adhérez à l'April : http://april.org/
Re: [Standards] XEP-0191: Simple Communications Blocking
Is it a question of message, presence (in/out) or iq? Or all stanza types? Well, it should behave the same as the rules described in the XEP, so that means all stanza types (see 5.3). I'm not sure repeating the rules helps much in clarifying that. cheers, Remko
Re: [Standards] [Operators] [Fwd: Proposed XMPP Extension: Incident Reporting]
On Wed, Apr 29, 2009 at 5:42 AM, Peter Saint-Andre stpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI. This proposal emerged from discussions among some operators and server vendors at XMPP Summit #6 in February... The current proposal doesn't look bad. A few notes follow. The solution and suggestion elements should most certainly contain ip elements, the reporter in most cases won't know the IP, except in the case of suspicious registrations. Waqas also told me he had reservations about using the server's roster this way, and overloading presence subscriptions with something they are not. I'm not really fussed either way, but it would be interesting to know what others think of this. It would also be useful to have a way of forwarding reports on to other servers, perhaps including the originator. Otherwise perhaps we need a way to ask a friend server who they trust, as a means of bootstrapping our own list. Suggestion and solution elements could also be present in the initial report, not sure if the XEP is allowing this, but it should probably be said explicitly. One question is whether servers accept reports from unknown servers when the report relates to users on that server. For reasoning, see the blog post I wrote a while back at http://matthewstechnologyblog.blogspot.com/2008/05/jabber-abuse-handling.html - The idea is that the abuser's login server collects reports from anyone, and once satisfied that there really is a problem it can act (either automatically or by notifying the admin). Matthew.
[Standards] secure s2s multiplexing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Hildebrand and I have started working on an Internet-Draft that describes at least the requirements and possibly proposed solutions to the challenge of securely multiplexing multiple domains over the same XML stream. The deployment scenario we have in mind is for a hosting provider or application service provider to service multiple domains on the same machine or machines. With the increasing popularity of so-called cloud computing, some of these providers service thousands of domains (e.g., Google Apps). Because RFC 3920 specifies that each domain-to-domain link shall use two XML streams (one in each direction) and because currently XMPP has no method by which an existing stream can be re-used for additional domains, establishing connectivity between two XMPP clouds can quickly necessitate a large number of TCP connections. This is true even if the clouds have authenticated to each other using TLS and SASL with digital certificates issued by trusted roots. Therefore we think it would be desirable to define a method by which two XMPP clouds could optionally multiplex communications between themselves, so that an existing domain-to-domain stream could be re-used for additional domains. We see the following requirements: * The multiplexing method must be backwards-compatible with existing server-to-server connection methods. * Each party to a server-to-server communication must be able to determine if the other party supports multiplexing. * If the addition of a new domain to an existing domain-to-domain stream fails, the existing stream must not be terminated. * Multiplexing shall depend on presentation of a valid digital certificate for the multiplexed domain. * The certificate for a multiplexed domain should not be the same (i.e., have the same subject) as a certificate that has previously been accepted for the stream; however, if it is the same then it shall replace the previous certificate with the same subject (e.g., to present a new certificate with a different expiry time). * When a multiplexed domain is accepted for the stream, each name on the certificate (e.g., id-on-dnsSRV or id-on-xmppAddr) becomes valid for the stream. * The protocol used accept the initial certificate for a stream may be different from the protocol used to accept subsequent (multiplexed) domains for the stream. * The process of adding a subsequent domain shall not affect transmission of application data over the stream. * If the stream is resumed, all of the certificates that were accepted for the previous session apply to the resumed session. * It is a security violation to proceed with transmission of application data between two domains if multiplexing for those domains failed (however, this does not affect domains that have already been accepted for the stream). Is that list accurate and complete? Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn4b/MACgkQNL8k5A2w/vyJFACgy8MRHFPwHKYIyt46qfPyS7mO FxIAn37bp7hHvWzImbVAHoIxtv+G8iPD =5hZ/ -END PGP SIGNATURE-
Re: [Standards] secure s2s multiplexing
Peter Saint-Andre wrote: Joe Hildebrand and I have started working on an Internet-Draft that describes at least the requirements and possibly proposed solutions to the challenge of securely multiplexing multiple domains over the same XML stream. Btw, could you remove the other usage of 'multiplex' from RFC 3921bis? The deployment scenario we have in mind is for a hosting provider or application service provider to service multiple domains on the same machine or machines. With the increasing popularity of so-called cloud computing, some of these providers service thousands of domains (e.g., Google Apps). Because RFC 3920 specifies that each domain-to-domain link shall use two XML streams (one in each direction) and because currently XMPP has no method by which an existing stream can be re-used for additional domains, establishing connectivity between two XMPP The 'd' word. clouds can quickly necessitate a large number of TCP connections. This is true even if the clouds have authenticated to each other using TLS and SASL with digital certificates issued by trusted roots. Therefore we think it would be desirable to define a method by which two XMPP clouds could optionally multiplex communications between themselves, so that an existing domain-to-domain stream could be re-used for additional domains. We see the following requirements: * The multiplexing method must be backwards-compatible with existing server-to-server connection methods. * Each party to a server-to-server communication must be able to determine if the other party supports multiplexing. unidirectional or bidirectional s2s for this? For bidi we need a reverse-stream:features feature anyway. * If the addition of a new domain to an existing domain-to-domain stream fails, the existing stream must not be terminated. if the addition of a new domain to an existing stream fails, is it allowed to retry after x minutes? * Multiplexing shall depend on presentation of a valid digital certificate for the multiplexed domain. * The certificate for a multiplexed domain should not be the same (i.e., have the same subject) as a certificate that has previously been accepted for the stream; however, if it is the same then it shall replace the previous certificate with the same subject (e.g., to present a new certificate with a different expiry time). * When a multiplexed domain is accepted for the stream, each name on the certificate (e.g., id-on-dnsSRV or id-on-xmppAddr) becomes valid for the stream. This could be nasty with wildcard certificates. Explicit negotiation or no wildcards? * The protocol used accept the initial certificate for a stream may be different from the protocol used to accept subsequent (multiplexed) domains for the stream. You're mixing up 'certificate' and 'domain'. * The protocol used [to] exchange(?) the certificate for the initial domain on(?) a stream may be different from the protocol to exchange the certificates for subsequent (multiplexed) domains on the stream. * The process of adding a subsequent domain shall not affect transmission of application data over the stream. * If the stream is resumed, all of the certificates that were accepted for the previous session apply to the resumed session. * It is a security violation to proceed with transmission of application data between two domains if multiplexing for those domains failed (however, this does not affect domains that have already been accepted for the stream). I think it is ok to kill the stream. Is that list accurate and complete? looks good. philipp
Re: [Standards] secure s2s multiplexing
Philipp Hancke wrote: Peter Saint-Andre wrote: Joe Hildebrand and I have started working on an Internet-Draft that describes at least the requirements and possibly proposed solutions to the challenge of securely multiplexing multiple domains over the same XML stream. Btw, could you remove the other usage of 'multiplex' from RFC 3921bis? The deployment scenario we have in mind is for a hosting provider or application service provider to service multiple domains on the same machine or machines. With the increasing popularity of so-called cloud computing, some of these providers service thousands of domains (e.g., Google Apps). Because RFC 3920 specifies that each domain-to-domain link shall use two XML streams (one in each direction) and because currently XMPP has no method by which an existing stream can be re-used for additional domains, establishing connectivity between two XMPP The 'd' word. clouds can quickly necessitate a large number of TCP connections. This is true even if the clouds have authenticated to each other using TLS and SASL with digital certificates issued by trusted roots. Therefore we think it would be desirable to define a method by which two XMPP clouds could optionally multiplex communications between themselves, so that an existing domain-to-domain stream could be re-used for additional domains. We see the following requirements: * The multiplexing method must be backwards-compatible with existing server-to-server connection methods. * Each party to a server-to-server communication must be able to determine if the other party supports multiplexing. unidirectional or bidirectional s2s for this? For bidi we need a reverse-stream:features feature anyway. I think this should make the stream bidirectional. * If the addition of a new domain to an existing domain-to-domain stream fails, the existing stream must not be terminated. if the addition of a new domain to an existing stream fails, is it allowed to retry after x minutes? Sure, why not. * Multiplexing shall depend on presentation of a valid digital certificate for the multiplexed domain. * The certificate for a multiplexed domain should not be the same (i.e., have the same subject) as a certificate that has previously been accepted for the stream; however, if it is the same then it shall replace the previous certificate with the same subject (e.g., to present a new certificate with a different expiry time). PSA: I am not sure why this is a requirement. I think this is a part of the solution you and Joe have in mind. * When a multiplexed domain is accepted for the stream, each name on the certificate (e.g., id-on-dnsSRV or id-on-xmppAddr) becomes valid for the stream. This could be nasty with wildcard certificates. Explicit negotiation or no wildcards? Good question! * The protocol used accept the initial certificate for a stream may be different from the protocol used to accept subsequent (multiplexed) domains for the stream. You're mixing up 'certificate' and 'domain'. * The protocol used [to] exchange(?) the certificate for the initial domain on(?) a stream may be different from the protocol to exchange the certificates for subsequent (multiplexed) domains on the stream. Right. * The process of adding a subsequent domain shall not affect transmission of application data over the stream. * If the stream is resumed, all of the certificates that were accepted for the previous session apply to the resumed session. Hmm, Ok. * It is a security violation to proceed with transmission of application data between two domains if multiplexing for those domains failed (however, this does not affect domains that have already been accepted for the stream). I think it is ok to kill the stream. Agreed. Is that list accurate and complete? looks good. Looks good to me too.
[Standards] [Fwd: [Council] meeting minutes, 2009-04-29]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI. - Original Message Subject: [Council] meeting minutes, 2009-04-29 Date: Wed, 29 Apr 2009 21:12:30 -0600 From: Peter Saint-Andre stpe...@stpeter.im Reply-To: XMPP Council coun...@xmpp.org To: XMPP Council coun...@xmpp.org Results of the XMPP Council meeting held 2009-04-29... Agenda: http://mail.jabber.org/pipermail/council/2009-April/002551.html Log: http://logs.jabber.org/coun...@conference.jabber.org/2009-04-29.html Scribe: Peter Saint-Andre 0. Roll call Present: Dave Cridland, Ralph Meijer, Jack Moffitt, Peter Saint-Andre, Kevin Smith. Absent: None. Quorum achieved. 1. Agenda bashing Peter pointed out that Ralph and Jack still need to vote on approving version 1.8 of XEP-0124. 2. Roster Versioning Consensus to issue a second Last Call. 3. Advance XEP-0138 (Stream Compression) to Final? Consensus to issue a Call for Experience. 4. Advance XEP-0199 (XMPP Ping) to Final? Consensus to issue a Call for Experience. 5. http://xmpp.org/extensions/inbox/instant-gaming.html 6. http://xmpp.org/extensions/inbox/multi-user_gaming.html 7. http://xmpp.org/extensions/inbox/tictactoe.html 8. http://xmpp.org/extensions/inbox/tictactoe-mug.html Several Council members would like to review these further before publication, but no major objections were voiced. 9. http://xmpp.org/extensions/inbox/incident-reporting.html Consensus to publish after the authors split the server buddies functionality into a separate proposal. 10. Other business. Ralph and Jack voted +1 on XEP-0124 v1.8. Peter mentioned the XMPP Summit (July 20-21 in San Jose, California) and IETF 75 (July 26-31 in Stockholm). 11. Next meeting. May 6, 2009, in xmpp:coun...@conference.jabber.org -- for reminders, load http://xmpp.org/xsf/XSF.ics Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn5F18ACgkQNL8k5A2w/vyvqQCgtqMRS4FCExUXj5zZ/VydDg0k GAsAnj/veiUWUdgp6s1P25k56lY8kZb/ =qKBt -END PGP SIGNATURE-
