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 [email protected] 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/
