[Standards] XEP-0220: handling of invalid dialback key
stpeter at stpeter.im
Thu Apr 14 22:19:12 UTC 2011
On 4/14/11 3:27 PM, Philipp Hancke wrote:
> 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?
>> 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.
So, in DNA, if a DNSSEC-based verification doesn't work out, the
Authoritative Server returns an error, not "invalid"?
> 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.
I completely agree with that.
In fact that might be an argument for moving XEP-0220 and XEP-0288 to
the XMPP WG. I'd like to get XEP-0220 to Draft before we do that.
Alternatively we could Retract it and submit it as an Internet-Draft,
since it basically updates RFC 3920 anyway. I plan to ask the XMPP
Council about this at its meeting next week.
>>> 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.
>> 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.
You're right about the queueing -- I misunderstood the spec so I've
clarified that queueing refers to outbound stanzas.
I'm still not convinced about forcing the receiving server to close the
stream categorically, but I'll think about it further...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards