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.
[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/>
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.
