On 16 April 2013 21:16, XMPP Extensions Editor <[email protected]> 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?
Definitely needed. > 2. Does the specification solve the problem stated in the introduction and > requirements? Yes, it does. > 3. Do you plan to implement this specification in your code? If not, why not? We have, except for the newer "errors" portion of the protocol and "multiplexing sender domains". Support for errors is planned. > 4. Do you have any security concerns related to this specification? Nothing not already documented. > 5. Is the specification accurate and clearly written? The nature of the protocol is confusing, and it isn't helped by carrying legacy baggage and not fitting very nicely into the rest of XMPP. Nevertheless, I think the specification does a decent job at trying to present everything logically, and I didn't have that much trouble implementing it. Editorially there seem to be some issues with internal references. For example links and text about section 2.4, which is about advertising support and not errors in particular. Overall I think this is a good useful document of a protocol that isn't going away any time soon. Someone asked only yesterday if Prosody could be configured to do TLS authentication *and* dialback (i.e. requiring both to pass). Regards, Matthew
