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.

<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?

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 :-)

Reply via email to