Accepted by council vote from 2017-12-13.
Minor changes
Based ISR on SASL2.
Second draft.
First draft.
This XEP specifies an instant stream resumption mechanism based + on &xep0198;, allowing XMPP entities to instantaneously resume an + XMPP stream. This can be seen as the complementary part to &xep0305; + allowing for fast XMPP session (re-)establishment.
+ +Compared to the existing stream resumption mechanism of XEP-0198 + § 5, the approach defined herein reduces the round trips + required to resume a stream to exactly one. This is + achieved by using just a secure short-lived token to resume the + stream.
+ +XMPP entities providing Instant Stream Resumption MUST announce + that functionality as stream feature, but only if an instant stream + resumption is possible at this stage. The ISR stream future consists + of an <isr/> element qualified by the 'htpps://xmpp.org/extensions/isr/0' + namespace. And since ISR requires TLS, this means that the + <isr/> stream feature only appears on TLS secured + connections.
+ +The ISR stream feature element MUST contain a <mechanisms/> + element as defined in &rfc6120;. This element contains the SASL + mechanism which are available to be used for instant stream + resumption.
+ +Every ISR enabled entity SHOULD support the HT-SHA-256-ENDP + mechanism, support for HT-SHA-256-UNIQ is RECOMMENDED. The family + of HT SASL mechanisms is specified in &sasl-ht;.
+ +In order to obtain an ISR token, the requesting entity must add an
+ 'isr-enable' element qualified by the 'htpps://xmpp.org/extensions/isr/0' namespace to the
+ <enable/> element as defined in &xep0198; when attempting to
+ enable Stream Management. This <isr-enable/> element MUST contain a
+ 'mechanism' attribute containing the name of the SASL mechanism the
+ requesting entity will use when performing ISR with the returned
+ token. The entities involved in ISR MUST only use or allow this
+ mechanism when performing ISR with the according token. This
+ effectively pins the SASL mechanism
Next, the <enabled/> Nonza (see &xep0360;) which is send as + positive reply upon a request to enable Stream Management, MUST + contain an 'isr-enabled' element qualified by the 'htpps://xmpp.org/extensions/isr/0' + namespace containing a ISR token as value of its 'token' attribute. The + token MUST be newly generated by a cryptographically secure random + number generator and MUST contain at least 128 bit of entropy. The + <isr-enabled/> element can optionally also contain a + 'location' attribute + which specifies the preferred IP address or hostname, and a TCP port + number of the host which should be used for instant stream + resumption.
+ +The <enabled/> Nonza containing an ISR token MUST only be + sent over TLS secured connections.
+ +In order to instantaneously resume an XMPP stream the initiating + entity, which is either an XMPP client or server, must posses a + valid ISR token. After it has obtained the ISR token, using the process + described in the previous section, it first determines the host for + resumption, and after that, tries to perform the instant stream + resumption.
+ +The lookup mechanism order to determine host candidates for ISR + resumption is as follows:
+ +The host candidates retrieved by those mechanisms SHOULD be + tried by the initiating entity in this order.
+ +Note that the hosts announced by the 'location' attribute + qualified by the 'htpps://xmpp.org/extensions/isr/0' namespace MUST be connected to + using TLS from the beginning, i.e. <starttls/> MUST NOT be + used, instead the TLS handshake is performed right after + establishing the connection.
+ +This order prefers hosts which allow connections where TLS is + enabled from the beginning. This is desirable to reduce the + required round trips by skipping the <starttls/> step.
+ +After the remote host on which the instant stream resumption + should be performed was determined, the initiating entity connects + to the host, and establishes TLS by either
+ +Now the initiating entity sends an XMPP <stream> open + element followed by a <authenticate/> Nonza as specified in + the &xep0388;. The initiating entity must also provide a + <inst-resume/> element qualified by the 'htpps://xmpp.org/extensions/isr/0' + namespace, which must contain a <resume/> element as defined + in &xep0198;.
+ +If the with-isr-token' attribute is set to 'false', then the + SASL mechanism is performed as when traditionally authenticating + the XMPP session. If the value of the attribute is 'true', which is + the default value for this attribute, then the "password" given to + the SASL mechanism is the ISR token. Note that this implies that only + SASL mechanisms which take a password/token can be used this + way.
+ +Note that the initiating entity SHOULD pipeline the instant + stream resumption request together with then initial + <stream> open element. The initiating entity is able to do + so since it already knows that the service supports ISR because it + announced an ISR token.
+ +Servers MUST destroy the ISR token of a stream after an instant + stream resumption was attempted for that stream with an invalid ISR + token. Server implementations MUST implement the ISR token comparision in + linear runtime.
+ +On success the server replies with a <success/> nonza as + specified in the &xep0388;, which must include a + <inst-resumed/> element qualified by the 'htpps://xmpp.org/extensions/isr/0' + namespace. This element MUST contain a new ISR Token found in + the 'token' attribute. It also MUST include a <resumed/> as + specified in &xep0198; containing the sequence number of the last by + Stream Management handled stanza in the 'h' attribute and the + 'previd' attribute.
+ +In case of an successful Instant Stream Resumption authenticated + by an ISR token, the server MUST immediately destroy the ISR token after + authentication, i.e., it MUST no longer be possible to perform an + ISR using that ISR token and Stream Management ID (SM-ID, see + &xep0198;) tuple.
+ +After the <inst-resumed/> was received and has been + verified both entities MUST consider the resumed stream to be + re-established. This includes all previously negotiated stream + features like &xep0138;. It does however not include the specific + state of the features: For example in case of Stream Compression, + the dictionary used by the compression mechanism of the resumed + stream MUST NOT be considered to be restored after instant stream + resumption.
+ +Note that this behavior is different from &xep0198; + stream resumption, where "outer stream" features like compression + are not restored. Since such a behavior would be counterproductive + towards the goal of this XEP, it specifies that the negotiation + state of such "outer stream" features is also restored (besides the + features which where already negotiated at ISR-time, i.e. TLS).
+ +If the server was able to authenticate the initiating entity + but is unable to resume the stream instantly it MUST reply with a + <success/> Nonza as defined in the &xep0388; containing + a <inst-resume-failed/> element qualified by the + 'htpps://xmpp.org/extensions/isr/0' namespace. This + <inst-resume-failed/> MUST contain a <failed/> + element as defined in &xep0198;.
+ +Instant stream resumption errors SHOULD be considered + recoverable, the initiating entity MAY continue with normal + session establishment; however, misuse of stream management MAY + result in termination of the stream. Since the initiating entity is + authenticated, it could continue with resource binding by using + &rfc6120; § 7. or &xep0386;.
+ +As specified in the &xep0388; § 2.6.3, sole SASL authentication + may not be sufficient for authentication. In this case, the remote + entity sends a <continue/> element as defined in &xep0388; + to request the local entity to perform another + task.
+ +If the server is unable to authenticate the initiating entity
+ it replies with a <failure/> Nonza as defined in
+ &xep0388;. The server MUST delete any state of the stream which
+ was attempted to resume in case the SM-ID was correct but the
+ authentication failed.
After the ISR authentication has failed, the initiating entity + could continue with normal authentication (&xep0388;, + …).
+ +Any ISR data SHALL NOT be part of TLS 1.3 0-RTT + early data. (TODO: Shall we weaken this requirement to allow early + data?. It would be technically possible if the sender does not add + additional data, for example Stanzas, after the ISR/XEP-0388 data at + the end of the early data. And if the receiver does ensure that the + existence of such additional data is causing an ISR failure.)
+ +It is of vital importance that the Instant Stream Resumption + Token is generated by a cryptographically secure random + generator. See &rfc4086; for more information about Randomness + Requirements for Security.
+ +This document requires no interaction with &IANA;.
+ +The ®ISTRAR; includes 'htpps://xmpp.org/extensions/isr/0' in its registry of protocol namespaces (see &NAMESPACES;).
+ +TODO: Add after the XEP leaves the 'experimental' state.
+ +Thanks to Jonas Wielicki, Thijs Alkemade, Dave Cridland, Maxime + Buquet, Alexander Würstlein and Sam Whited for their feedback.
+ +