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

Philipp Hancke fippo at goodadvice.pages.de
Thu Apr 14 21:27:44 UTC 2011

Peter Saint-Andre wrote:
> On 4/14/11 2:47 PM, Philipp Hancke wrote:
>> Peter Saint-Andre wrote:
>>>> Actually, I mostly disagree with the "removed requirement for the
>>>> Receiving Server to close the stream if the dialback key is invalid"
>>>> stuff. From the security POV, why should the receiving server not
>>>> terminate the stream?
>>> Because, from the performance point of view, it doesn't want to discard
>>> the 10,000 valid domains it already supports on that stream. That's a
>> The average stream has probably one domain pair. Do you want me to make
>> a simple extrapolation of the power law to demonstrate that most domains
>> will not even have 500 domain pairs?
> Sure they won't. But the few services that do virtual hosting will do it
> on a massive scale.

You did not get the joke :-)

Karma might be a reason why you actually do not want to multiplex on 
such a scale.

>>> huge cost to impose on the server just because the 10,001st domain has a
>>> DNSSEC problem. For traditional dialback the force-close requirement is
>>> fine. For dialback as used for domain name assertions with DNSSEC it
>>> seems too strong to me.
>> If DNSSEC is used, when does the receiving server ask the authoritative
>> server to verify a dialback key?
> http://tools.ietf.org/html/draft-ietf-xmpp-dna-01
> I grant that I need to think about that spec further, but I don't want
> to make DNA impossible because of a requirement in XEP-0220 that applies
> to the one-to-one federation model but not the virtual hosting
> federation model.

I do not see any conflicts. As noted on the XMPPWG list, DNA actually 
requires support for dialback errors, but otherwise I do not see why it 
would not work as described.

However, I think that DNA needs a "big picture" merge with 220 
(multiplexing), 288 (bidi) and the d-w-d spec that dwd promised to write 
some time ago.

>> If it never uses dial-back, why should the receiving server send
>> 'invalid' instead of 'error'?
> Could you clarify that scenario?

The receiving server will only "forward" invalid, never generate it itself.

>> And you might still generate valid dialback keys for
>> dialback-with-dnssec to avoid that problem.
> Possibly.
> Anyway, here is revised text:
> If the value of the 'type' attribute is "invalid", then the Originating
> Server's identity (as valid for the Sender Domain) could not be verified
> by the Receiving Server. In this case, the Receiving Server MUST NOT
> process any queued stanzas from the Originating Server but instead MUST
> return any queued stanzas with an<internal-server-error>  stanza error.

No. The originating server MUST NOT send any stanzas before it receives 
a valid dialback result, so there are no stanzas to process and no 
stanzas to be bounced. That is the whole point of all this dialback 
stuff, that you negotiate the domain pair before sending any stanzas to 
avoid bouncing stanzas.

> In addition, it is strongly RECOMMENDED for the Receiving Server to
> close the underlying stream (the only reason the Receiving Server might
> not close the underlying stream is if the stream is already being used
> for other domain pairs that have already been validated).

-1. But that is mostly because I think that 'invalid' is currently only 
used in cases where it is justified to close the stream.

More information about the Standards mailing list