[Standards] XEP-0220: handling of invalid dialback key
stpeter at stpeter.im
Thu Apr 14 20:58:41 UTC 2011
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.
>> 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?
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
> If it never uses dial-back, why should the receiving server send
> 'invalid' instead of 'error'?
Could you clarify that scenario?
> And you might still generate valid dialback keys for
> dialback-with-dnssec to avoid that problem.
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.
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards