[Standards] Proposed XMPP Extension: Instant Stream Resumption

Florian Schmaus flo at geekplace.eu
Sun Mar 13 11:37:01 UTC 2016

On 02.03.2016 00:22, Dave Cridland wrote:
> On 1 Mar 2016 10:17 pm, "Florian Schmaus" <flo at geekplace.eu
> <mailto:flo at geekplace.eu>> wrote:
> If a client sends a stanza prior to receiving the response to an
> authentication request, it's doing so prior to channel binding having
> completed. That may fit your security model, I suppose.
> Certainly the stream hasn't been authenticated or resumed as far as the
> client knows until one round trip time later.

My fault, what I figured out as term and meant to write was "zero round
trip overhead stream resumption", but somehow my fingerers typed
something different. No one wants to use a stream before the response is
verified. That is why every ISR version states in the introduction
section that there is "exactly one (besides the round trips required by
the TLS handshake)" round trip required.

>> > 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.
> Um. Didn't I demonstrate that in my previous mail? Or at least, the same
> number of round trips.
>> And
>> secondly, it just feels wrong to have the stream in a different state
>> after <success/> depending on whether or not ISR is used.
> Okay. But it feels wrong to me to have different authentication
> mechanisms. We don't design authentication mechanisms here. The times we
> have, like XEP-0078, haven't ended well.

You are *always* designing some sort of authentication mechanism, be it
for authentication of the stream, in the resumption case, or for
authenticating the XMPP entity.

>> > 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].
> The mutual auth from TLS? Sure. But a YAP variant can do that; the last
> draft happens to use a different binding, is all.
> The main difference with my approach is that if a particular hash
> algorithm gets weakened, switching is a well defined process.

Hash agility is already solved in the latest ISR version. I'm also
considering adding support for Channel Binding agility. But right now,
'tls-server-end-point' is fixed: A short survey performed by me amongst
various server and client library developers showed that this CB type is
easy to implement, because most/all TLS APIs provide access to the cert,
which is the only requirement for implementing this.

I've worked on ISR on the last couple of days and I'm going to send the
new version to the XSF Editor later. I try to be available in the next
XSF Council meeting for questions, but if I don't make it, then please
feel free to ask me any questions in xsf@ or on this ML thread.

- Florian

-------------- 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/20160313/9bb6de2b/attachment.sig>

More information about the Standards mailing list