[Standards] LAST CALL: XEP-0220 (Server Dialback)

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 21 16:01:31 UTC 2013


Old thread alert.

On 4/29/13 12:40 AM, Philipp Hancke wrote:
> On Tue, 16 Apr 2013, XMPP Extensions Editor wrote:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0220 (Server Dialback).
>>
>> Abstract: This specification defines the Server Dialback protocol,
>> which is used between XMPP servers to provide identity verification.
>> Server Dialback uses the Domain Name System (DNS) as the basis for
>> verifying identity; the basic approach is that when a receiving server
>> accepts a server-to-server connection from an initiating server, it
>> does not process traffic over the connection until it has verified the
>> initiating server's key with an authoritative server for the domain
>> asserted by the initiating server. Additionally, the protocol is used
>> to negotitate whether the receiving server is accepting stanzas for
>> the target domain. Although Server Dialback does not provide strong
>> authentication and it is subject to DNS poisoning attacks, it has
>> effectively prevented address spoofing on the XMPP network since its
>> development in the year 2000.
>>
>> URL: http://xmpp.org/extensions/xep-0220.html
>>
>> This Last Call begins today and shall end at the close of business on
>> 2013-05-10.
>>
>> Please consider the following questions during this Last Call and send
>> your feedback to the standards at xmpp.org discussion list:
>>
>> 1. Is this specification needed to fill gaps in the XMPP protocol
>> stack or to clarify an existing protocol?
>> 2. Does the specification solve the problem stated in the introduction
>> and requirements?
>> 3. Do you plan to implement this specification in your code? If not,
>> why not?
>> 4. Do you have any security concerns related to this specification?
>> 5. Is the specification accurate and clearly written?
>>
>> Your feedback is appreciated!
> 
> Digging out my print copy i found some notes regarding stream
> compression and session managment in 2.1.1 (after example 3).

Really old thread alert. :-)

> Have we resolved
> http://mail.jabber.org/pipermail/standards/2012-May/025999.html
> and
> http://mail.jabber.org/pipermail/standards/2012-May/025998.html
> ?

I don't think we have.

The first-listed post was about compression after dialback.

In that message you wrote:

   The reason why stream compression is after some kind of
   authentication is probably to have an asserted idenity of the peer
   and avoid offering it to parties whose trust level is not high
   enough (aka: you trust those parties never to send zlib bombs).

That's an accurate description of the concern we had with offering
compression before authentication.

However, you make a good point about the need for stream restarts after
dialback under the order of operations mandated in XEP-0170. It seems
that we had not thought that through in detail with regard to dialback.
The points you raise seem compelling. This seems to require a change to
XEP-0170 -- and as you said that "might be necessary for things like
0198 and 0288 anyway".

I propose that we make the following change to XEP-0220 in Section 2.1.1:

OLD
Naturally, the Initiating Server can also enable or negotiate other
stream features at this point, such as Stream Compression [9] and Stream
Management [10].

NEW
Naturally, the Initiating Server can also enable or negotiate other
stream features at this point.

And then start an effort to review and revise XEP-0170.

The second-listed post was about XEP-0198 and dialback. Here again the
issue is the order of operations, governed by XEP-0170. So my conclusion
is the same: let's fix XEP-0170.

Peter

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





More information about the Standards mailing list