[Standards] XEP-0220: handling of invalid dialback key

Peter Saint-Andre stpeter at stpeter.im
Thu Apr 14 18:11:54 UTC 2011

Version 0.5 of XEP-0220 (server dialback) was, I think, a bit
schizophrenic about handling of incoming connections. [1] It said this
in Section 2.2.1:


This subsection describes the interaction between the Originating Server
and the Receiving Server, from the perspective of the Receiving Server....

This key MUST be verified before the Sender Domain ('sender.tld') is
authorized to send stanzas....

Note: the Receiving Server MUST continue to accept and process stanzas
for already verified domain pairs, and MUST continue to process both
<db:result/> and <db:verify/> elements.

After the validity of the key has been established (for example, by the
Authoritative Server), the domain pair is to be considered as verified
and the Receiving Server MUST accept stanzas from the Originating Server.

In addition, the Originating Server is notified of the result. This is
done by creating a <db:result/> element which MUST possess a 'from'
attribute whose value is the Target Domain, MUST possess a 'to'
attribute whose value is the Sender Domain, and MUST possess a 'type'
attribute whose value is either "valid" or "invalid"....

If the type is 'invalid', the Originating Server is attempting to spoof
the Sender Domain. The Receiving Server MUST terminate the XML stream
and the underlying TCP connection and SHOULD log the attempt.


Here is why I think that's schizophrenic. The receiving server is
required to accept and process stanzas for already verified domain
pairs. However, if verification of a new domain pair fails, then the
receiving server is required to treat all previous verifications as now
invalid (despite the fact that they were valid before). That seems wrong
to me, and potentially very problematic given that we plan to use
dialback for domain name assertions [2] in the XMPP WG. In particular,
domain name assertions might lead to re-use of a given stream for a very
large number of domain pairs (say, 10,000), and forcing the receiving
server to close that stream because domain pair #10,001 is invalid seems
like a pretty serious operational burden. IMHO it would be best to leave
that decision up to local service policy and not mandate it in the spec.

Therefore in version 0.6 of XEP-0220 I changed the last paragraph cited
above to:

   If the value of the 'type' attribute is "invalid", this means that
   the Originating Server's identity (as valid for the Sender Domain)
   could not be verified by the Receiving Server. Queued stanzas MUST
   be returned to the respective senders with an
   <internal-server-error> stanza error and the underlying stream MAY
   be closed unless it is being used by other domain pairs. Note that
   the Receiving Server might choose to terminate the TCP connection.

I'd be fine with changing "MAY" to "SHOULD" here, but I think "MUST" is
too strong.

Feedback is welcome.


[1] http://xmpp.org/extensions/attic/xep-0220-0.5.html

[2] http://tools.ietf.org/html/draft-ietf-xmpp-dna-01

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110414/a1793fd7/attachment.bin>

More information about the Standards mailing list