[Standards] Proposed XMPP Extension: Instant Stream Resumption

Florian Schmaus flo at geekplace.eu
Tue Mar 1 22:15:54 UTC 2016


On 01.03.2016 20:52, Dave Cridland wrote:
> FWIW, ISR is 1-RTT, unless you pipeline through, which doesn't really
> count. Calling it 0-RTT is marketing.

Independent on which label you put on that claim, it doesn't change that
the it is true.

> So the main reason I'm thinking of wrapping ISR around SASL is because
> ISR replaces SASL to some degree, which is where Thijs and Tobias's
> concerns come from.

The way I see it, is that it does not replace SASL, not even to some
degree, as SASL is (still) used to authenticate entities. ISR does
authenticate a stream resumption in an efficient manner.

> If you wrap ISR around SASL - and we can discuss removing the stream
> restart post-SASL in this case, too - then the security properties of
> the authentication portion of ISR become a matter of choosing the SASL
> mechanism, which is both vastly simpler to define and also allows us to
> easy handle things like hash agility.

I deliberately choose to not build ISR on top of SASL. First, I believe
it's not possible to achieve a zero round trip resumption doing so. And
secondly, it just feels wrong to have the stream in a different state
after <success/> depending on whether or not ISR is used.

> To put it another way, ISR effectively combine the authentication and
> 198 into one step. Your proposal builds ISR by taking '198, and adding a
> brand new authentication mechanism. I'm suggesting that it seems
> worthwhile to explore building it the other way around, so we take SASL
> and add the '198 bits we need onto that.

I'm looking forward seeing something like that put in a more formal
specification. But I fear that it won't be able to achieve the same
properties as ISR, will be a more elegant and/or straightforward solution.

> The net result will be identical, except that the bits most likely to
> require changing have already-existing discovery and selection.
> 
> For example, assuming we remove post-SASL stream restarts if ISR is in
> play, using SASL PLAIN gives the same number of RTTs, and the same
> security properties, as the original ISR proposal. Using YAP would be
> 1-RTT with channel binding. Using SCRAM would be 2-RTT, with SASL-level
> mutual authentication.

That *is not* an identical result. ISR using HMAC and
tls-server-end-point provides mutual authentication and channel binding
with a zero round trip resumption [1].

> I think your proposal is trying to be a one-size-fits all approach, and
> I don't think such an approach is either viable or desirable.

I think most mobile developers using XMPP would disagree. The
"Token-based reconnection" ProtoXEP was created because of this
requirement. And I also pointed out [1, p19] that the round trip intense
session establishment process is an issue for mobile XMPP.

We have SM, CSI, MAM, and soon hopefully MIX. And another important
building block for mobile friendliness is a zero round trip stream
resumption mechanism providing good security properties.

- Florian


1: Note that this is not the ISR version submitted as ProtoXEP, but the
one based on the input from Thijs, which happened after the submission.
2:
https://archive.fosdem.org/2015/schedule/event/xmpp_and_android/attachments/slides/749/export/events/attachments/xmpp_and_android/slides/749/xmpp_and_android.pdf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160301/8ed18b11/attachment-0001.sig>


More information about the Standards mailing list