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. > benefits: stream compression is negotiated in one place (<features/>). > Additionally, compression doesn't break multiplexing. > >>> I have to say it's pushing me over to the >>> we-need-to-deprecate-dialback camp... solving it in our code for each >>> individual case is possible, but hacky at best. >> >> Designing something to replace dialback seems like "fun". Getting >> everyone to implement and deploy it seems even more fun. > > The xmppwg chairs will surely agree when you propose that! > >>> Even if we keep the same authenti...thingy around, at least we should >>> have something more integrated into our normal feature negotiation. >>> like SASL is. >> >> We had discussions long ago about defining a SASL mechanism for >> dialback. That would slot in rather nicely, no? > > The stream-restart model doesn't work with multiplexing. 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. Peter -- Peter Saint-Andre https://stpeter.im/
