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

Philipp Hancke fippo at goodadvice.pages.de
Thu Apr 14 20:22:16 UTC 2011


Peter Saint-Andre wrote:
[...]

> Here is why I think that's schizophrenic. The receiving server is
> required to accept and process stanzas for already verified domain
> pairs.

I think we disagree about the usage of 'invalid'.

> 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

The result is invalid because the authoritative server explicitly told 
the receiving server that the originating server is not authorized.

That is quite different from cases where verification fails because - 
for example - the receiving server can not contact the authoritative 
server. This is to be handled by type='error'.

> 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

Don't attempt to send keys for domains that you don't own.

Even better: do certificate-based d-w-d or the dnssec d-w-d and avoid 
the dial-back thing.

> 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:

slightly reformatted...

>     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.

correct.

>     Queued stanzas MUST
>     be returned to the respective senders with an
>     <internal-server-error>  stanza error

This happens on the originating server.

>     and the underlying stream MAY
>     be closed unless it is being used by other domain pairs.

as does this.

 >     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.

You are trying to specify the behaviour of the _originating_ server? MAY 
is fine with me, since the next thing the originating server receives is 
usually a </stream:stream>, hence it does not make much difference.


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?



More information about the Standards mailing list