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

Philipp Hancke fippo at goodadvice.pages.de
Mon Nov 17 03:10:16 CST 2008

Peter Saint-Andre wrote:
> This Last Call has ended. I received some feedback off-list, which I
> will consolidate and post to the list next week.

Not neccessary. I finally had the time to fully read this version :-(

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?
Probably. However, it should explain, why dialback is preferable over
a simple DNS lookup. I can think of at least two reasons.

3. Do you plan to implement this specification in your code?
No. My current implementation has worked well enough for five years.

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?
No. See below for details. I have read various versions of this.
RFC 3920, 3920bis, all versions of 220. The description has changed
quite a lot in each version...

> (The XMPP Standards Foundation (XSF) [4] has worked to make
> certificates easier to obtain by running the XMPP Intermediate
> Certification Authority [5].)

This 'advertisement' is completly misplaced. Anyone reading this
spec wants to find out about dialback, not about the ICA.

> because the certificate presented by the peer service during TLS
> negotiation is self-signed and local service policies stipulate that
> it is preferable to weakly identify the peer service via Server
> Dialback rather than depend on the self-signed certificate for
> identity verification.

I think I criticized this sentence multiple times now, with no effect.
Now I would like an explanation: what service policy _uses_ self-
signed certificates for identity verification?

Section 2 is very boring. I read RFC 3920, I know how to resolve
addresses, how to open a connection etc. Why is this repeated?
Most error cases described herein belong to 3920bis.

> there is no IP address associated with this domain since it is merely
> asserted by the Originating Server

There is an ip address associated with this connection. Usually it is
the, but for sake of the argument it is better to use
a different address.

> The Receiving Server SHOULD include the dialback feature

I still do not see a reason for this. If the sending side is not using
sasl, it will assume that is has to authenticate - using dialback.
If SASL is used, dialback is unnecessary, at least according to
the XEP.

2.2.1: I agree with what Matthias said in <45794891.8080305 at tthias.eu> .
Jer came up with a smart method to check the dialback keys, but it is
not the only way of doing it.

Example 17+18: can not happen unless you piggyback. Otherwise, that
error would have occured earlier (example 11).

2.5.2: what happens to the connection between receiving and
authoritative server? As said before, this may be closed by
the receiving server, however this is left unspecified here.
The authoritative server MUST NOT close this connection.
> The Receiving Server then SHOULD also terminate the XML stream and the
>  underlying TCP connection between the Receiving Server and the
> Authoritative Server.

MAY also terminate. Closing this connection makes no sense usually.

> Support for piggybacking is OPTIONAL.

This is consensus? I certainly disagree, even though I used to highly
dislike piggybacking. The passive part of piggybacking is not difficult
to implement.

> db:result type='error'

Not necessary if the spec demands support for (passive) piggybacking.

The specification fails to describe 2-connection dialback and
3-connection dialback. The former is reusing the R2A connection as
the new O2R, the latter opens a TCP connection just for the verification
of the dialback key. Usually, this will also use SSL for that, which
then results in even more roundtrips and perceived latency.

More information about the Standards mailing list