Re: [Standards] [xmpp] XEP-0170: compression after dialback
On Tue, 2012-06-05 at 10:39 +0200, Philipp Hancke wrote: > No backward compability issues with m-link or prosody. Is anyone else > doing s2s-compression or 0198? > > Prosody currently (not sure if Matthew is already ahead of my > testing version) doesn't offer compression or session managment on > dialback links so there is nothing to be worried about. Both of those are activated after stream restarts, and the lack of such when doing dialback is the reason for the above. I did get started on trying to get Prosodys compression plugin to work without stream restart, but I'm not finished. The session management plugin has a setting for enabling it on s2s streams. -- Kim Alvefur
Re: [Standards] [xmpp] XEP-0170: compression after dialback
On Tue, 22 May 2012, Peter Saint-Andre wrote: pro: works with multiplexing and retains the current security properties of xep-0138. Additionally, that still enables the receiving server to use the (authenticated) peer name to selectively offer/deny certain features based on black/whitelists. cons: you don't get compression if you neither implement tls compression nor pay for a trusted certificate. I'll have to think about this for a while. Requires some minor changes to xeps 0138/0170/0198 afaics. I'll see if I can do some testing whether any of those changes would cause backward compability issues. Testing is good. Let us know what you discover. :) No backward compability issues with m-link or prosody. Is anyone else doing s2s-compression or 0198? Prosody currently (not sure if Matthew is already ahead of my testing version) doesn't offer compression or session managment on dialback links so there is nothing to be worried about. M-Link offers compression and session managment on dialback links and lets me activate both features before dialback.
Re: [Standards] [xmpp] XEP-0170: compression after dialback
Am 22.05.2012 23:06, schrieb Peter Saint-Andre: [...] Pandoras box actually... XEP 0138 might need restrictions similar to those described in the security considerations of RFC 3749. I'd like to avoid that if possible by retaining the assumption that the peer is authenticated. It seems to me that the security considerations in RFC 3749 (or at least some of them) apply even if the peer is authenticated. True, I'm slightly worried about finding the right maximum size though. However, it seems that 0138 compression is still quite effective even when sending a flush after each stanza. Whereas "flush" reminds me that there seems to be some controversy about sync flush vs. partial flush (which is what 0138 uses), see http://www.bolet.org/~pornin/deflate-flush.html -- I think that is something which can/should be dealth with by the lower layer. [snip] I don't think we'd need to restart the stream after each new domain is added. But let's add "multiplexing doesn't force a stream restart" to the requirements and figure out a way to make that happen. In the dialback world, yes. In the world of dialback-bis via SASL (or whatever), we'd make that explicit. Or just use dialback syntax for the sake of backward compatibility. There is a solution for the compression issue (and sm likewise, bidi is already doing that) which seems quite easy and pragmatic: Compression is only offered together with TLS and if the peer certificate is trusted (for some definition thereof) -- the same conditions when SASL EXTERNAL is offered. When you say "compression is only offered together with TLS", do you mean that only TLS compression is offered, or that stream compression (XEP-0138) is offered only if TLS is in use? erm... rephrased: 0138 compression shall only offered if the peer is using TLS with the null compression method and the peer certificate is trusted. That way initiating server can choose between sasl or dialback (which the receiving server might/should implement as a d-w-d variant). If I understand you, that means (for s2s streams) you can do either (1) TLS + SASL EXTERNAL + TLS-compression or (2) dialback + stream compression. TLS (with compression) + SASL or TLS (without compression) + stream compression + SASL TLS (with compression) + dialback TLS (without compression) + stream compression + dialback (order from left to right) Get alot easier if you decide not to do sasl :-)
Re: [Standards] [xmpp] XEP-0170: compression after dialback
On 5/22/12 2:42 PM, Philipp Hancke wrote: > mostly xsf-land but since this touches multiplexing... > Am 22.05.2012 19:04, schrieb Peter Saint-Andre: >> On 5/22/12 9:23 AM, Philipp Hancke wrote: >>> On Tue, 22 May 2012, Peter Saint-Andre wrote: >>> On 5/21/12 7:22 AM, Matthew Wild wrote: > On 21 May 2012 09:08, Philipp Hancke > wrote: >> The argument of keeping the negotiation of stream features in one >> place >> mentioned in my mail about 0198 applies to this, too. >> (the root cause of both problems is the inability of dialback to >> renegotiate >> stream features after authenti... err... whatever, but i don't >> see any way how we could change that. >> > > Yes, Prosody had this issue come up with both compression and 198 > recently. What are the costs and benefits of doing compression before dialback? >>> >>> cost: you're more vulnerable to "certain denial of service attacks" -- >>> I'd note that you might already be vulnerable by offering/using TLS >>> compression to a peer that you can't authenticate. >> >> Good point. > > Pandoras box actually... XEP 0138 might need restrictions similar to > those described in the security considerations of RFC 3749. I'd like to > avoid that if possible by retaining the assumption that the peer is > authenticated. It seems to me that the security considerations in RFC 3749 (or at least some of them) apply even if the peer is authenticated. > [snip] >> I don't think we'd need to restart the stream after each new domain is >> added. But let's add "multiplexing doesn't force a stream restart" to >> the requirements and figure out a way to make that happen. > > In the dialback world, yes. In the world of dialback-bis via SASL (or whatever), we'd make that explicit. Or just use dialback syntax for the sake of backward compatibility. > There is a solution for the compression issue (and sm likewise, bidi is > already doing that) which seems quite easy and pragmatic: > > Compression is only offered together with TLS and if the peer > certificate is trusted (for some definition thereof) -- the same > conditions when SASL EXTERNAL is offered. When you say "compression is only offered together with TLS", do you mean that only TLS compression is offered, or that stream compression (XEP-0138) is offered only if TLS is in use? > That way initiating server can choose between sasl or dialback (which > the receiving server might/should implement as a d-w-d variant). If I understand you, that means (for s2s streams) you can do either (1) TLS + SASL EXTERNAL + TLS-compression or (2) dialback + stream compression. > pro: works with multiplexing and retains the current security properties > of xep-0138. Additionally, that still enables the receiving server to > use the (authenticated) peer name to selectively offer/deny certain > features based on black/whitelists. > > cons: you don't get compression if you neither implement tls compression > nor pay for a trusted certificate. I'll have to think about this for a while. > Requires some minor changes to xeps 0138/0170/0198 afaics. I'll see if I > can do some testing whether any of those changes would cause backward > compability issues. Testing is good. Let us know what you discover. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] [xmpp] XEP-0170: compression after dialback
mostly xsf-land but since this touches multiplexing... Am 22.05.2012 19:04, schrieb Peter Saint-Andre: On 5/22/12 9:23 AM, Philipp Hancke wrote: On Tue, 22 May 2012, Peter Saint-Andre wrote: On 5/21/12 7:22 AM, Matthew Wild wrote: On 21 May 2012 09:08, Philipp Hancke wrote: The argument of keeping the negotiation of stream features in one place mentioned in my mail about 0198 applies to this, too. (the root cause of both problems is the inability of dialback to renegotiate stream features after authenti... err... whatever, but i don't see any way how we could change that. Yes, Prosody had this issue come up with both compression and 198 recently. What are the costs and benefits of doing compression before dialback? cost: you're more vulnerable to "certain denial of service attacks" -- I'd note that you might already be vulnerable by offering/using TLS compression to a peer that you can't authenticate. Good point. Pandoras box actually... XEP 0138 might need restrictions similar to those described in the security considerations of RFC 3749. I'd like to avoid that if possible by retaining the assumption that the peer is authenticated. [snip] I don't think we'd need to restart the stream after each new domain is added. But let's add "multiplexing doesn't force a stream restart" to the requirements and figure out a way to make that happen. There is a solution for the compression issue (and sm likewise, bidi is already doing that) which seems quite easy and pragmatic: Compression is only offered together with TLS and if the peer certificate is trusted (for some definition thereof) -- the same conditions when SASL EXTERNAL is offered. That way initiating server can choose between sasl or dialback (which the receiving server might/should implement as a d-w-d variant). pro: works with multiplexing and retains the current security properties of xep-0138. Additionally, that still enables the receiving server to use the (authenticated) peer name to selectively offer/deny certain features based on black/whitelists. cons: you don't get compression if you neither implement tls compression nor pay for a trusted certificate. Requires some minor changes to xeps 0138/0170/0198 afaics. I'll see if I can do some testing whether any of those changes would cause backward compability issues.
