Subject: Re: [xmpp] [Standards] XEP-0170: compression after dialback

From: Joe Hildebrand <[email-masked]>
Date: Tue, 22 May 2012 09:49:30 -0600

On 5/22/12 9:23 AM, "Philipp Hancke" <[email-masked]> wrote:

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

Well, that's something for [email-masked].

As-chair: if we come up with a solution that fixes this compression problem,
makes dialback better, allows for better security going forward (including
the delegated trust problem), and still does multiplexing, we'd be more open
than you expect.  I feel like we're already chartered for that work, and
haven't made much progress on it.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 May 2012 11:04:24 -0600

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-masked]> 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.
>>
>>> 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/

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 22 May 2012 22:42:28 +0200

mostly xsf-land but since this touches multiplexing...
Am 22.05.2012 19:04, schrieb Peter Saint-Andre:
>>>> On 21 May 2012 09:08, Philipp Hancke<[email-masked]>  wrote:

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]
> 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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 May 2012 15:06:24 -0600

> avoid that if possible by retaining the assumption that the peer is

It seems to me that the security considerations in RFC 3749 (or at least
some of them) apply even if the peer is authenticated.

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

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

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

> nor pay for a trusted certificate.

I'll have to think about this for a while.

> can do some testing whether any of those changes would cause backward

Testing is good. Let us know what you discover. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 22 May 2012 23:30:15 +0200

Hi Joe,

> than you expect.

Anything I could come up with ends up reinventing dialback (the 
<db:result part mostly) without being backward-compatible.  Might be my 
lack of imagination though.

Dialback has some ugly issues such as the inability to renegotiate 
features or the domain-pair restriction, but otherwise is quite capable 
of solving the problem. If those problems ever become an issue they 
might still be negotiated via features in a fashion similar to 
bidirectionality.

> I feel like we're already chartered for that work, and

I think that this is mostly a problem of sitting down and writing the 
specification (and I still have some pending changes to xep-220 that I 
really need to write down and submit).

The building blocks such as dialback and d-w-d have already been 
specified (the latter only as a blog post) and implemented.
I'm quite interested in DANE and have most of the code ready to 
implement it.