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?
