On 7 February 2018 at 08:55, Christian Schudt <christian.sch...@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.kinde...@gmail.com> > An: "XMPP Standards" <Standards@xmpp.org> > Betreff: [Standards] XEP-0198: Stream should be closed when 'h' value is to > high > Hello, > > 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. > > Thoughts? > > Guus > > > _______________________________________________ Standards mailing list Info: > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: > standards-unsubscr...@xmpp.org > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
