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.
