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<[email protected]> >>>>> 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. > > <db:result/> 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/
