[Standards] XEP-0198: Stream should be closed when 'h' value is to high
dave at cridland.net
Wed Feb 7 09:11:18 UTC 2018
On 7 February 2018 at 08:55, Christian Schudt <christian.schudt at gmx.de> wrote:
> This would follow the "Principle of Least Surprise", since terminating the
> stream may seem a bit harsh for the user.
There are other surprises than just closing the stream, here. If the
client acknowledges more stanzas than the server sent, then we really
cannot know if it's out by merely the delta, or by much more - that
is, if the server sends 10 stanzas and the client acknowledges 20, we
don't know if the client (or, indeed, server) has miscounted by 10,
and all stanzas are acknowledged, or if it has miscounted by 20 and
none of them are.
> Also keep in mind this sentence: "Stream management errors SHOULD be
> considered recoverable".
That was intended, I think, to mean responses to <enable/> shouldn't
result in a closed stream.
It's difficult to recover this one.
We could sent an <iq/> and <a/> together, and wait for the response,
otherwise blocking the stream. Complex, in programming/architecture
terms on the server, but perhaps possible. That would allow us to
resynchronize the counter. Perhaps. That *might* be sufficient to
argue that a stream close with a counter mismatch is a SHOULD rather
than a MUST, but I don't think I'd want to implement it.
> Are there any real-world scenarios where this issue could happen? A MitM
> attack on an unencrypted stream?
> Otherwise I think it can only happen due to an programming error.
> I think if there any security issues (like a MITM attack), the stream should
> be closed.
> If a wrong 'h' value can only happen due to a programming error, it should
> be silently handled/logged by programming logic.
> Kind regards,
> -- Christian
> Gesendet: Mittwoch, 07. Februar 2018 um 08:40 Uhr
> Von: "Guus der Kinderen" <guus.der.kinderen at gmail.com>
> An: "XMPP Standards" <Standards at xmpp.org>
> Betreff: [Standards] XEP-0198: Stream should be closed when 'h' value is to
> XEP-0198 Stream Management relies on a stanza count that is being send as an
> acknowledgement that a certain amount of session data has been received (the
> 'h' value). The XEP does not specify what should happen if the
> acknowledgement is off - when the remote entity appears to acknowledge data
> that was never / not yet sent.
> This situation was discussed briefly in the sidelines of the summit.
> Terminating the stream came up as the suggested way to handle such a
> situation. It is worth noting that such behavior is already allowable:
> "misuse of stream management MAY result in termination of the stream." (but
> this is not further specified in the XEP).
> I propose that the XEP is updated with an instruction to, upon detection of
> an invalid acknowledgement, terminate the stream with stream error.
> _______________________________________________ Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
> Standards-unsubscribe at xmpp.org
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards