[Standards] Proposed XMPP Extension: Instant Stream Resumption

Matthieu Rakotojaona matthieu.rakotojaona at gmail.com
Wed Feb 17 21:46:38 UTC 2016


Le mercredi 17 février 2016 19:18:01 CEST, Florian Schmaus a écrit :
> requiring the initiator to save the server cert and verify that it
> hasn't changed

Be aware that this will probably "soon" be impossible with TLS 1.3 which 
allows 0-RTT Handshake (see 
https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2): application data 
will be sent along with TLS handshake info by the client, which means the 
server certificate won't be visible by the client until after the token (or 
its transformed version) has already been sent.

Moreover, there are legitimate cases where the server cert can change yet 
security hasn't been compromised: a certificate is renewed, the initiator 
is redirected to another server of the cluster through the location 
attribute.

> You are right, exposing the 'tok' in <inst-resume/> without having the
server verified seems like a bad idea.

What are the cases where a MiTM server could decipher 'tok', after the 
*mandatory* TLS dance has been done, yet shouldn't have been ? I only see 
the case where the MiTM server has gotten hold of the legit server's 
private key, in which case:

* the legit server is owned
* the MiTM server doesn't even need to bother with ISR, it can ask 
everybody to re-auth through standards ways. It's going to be even more 
juicy for him because he'll have access to actual passwords (he can send 
PLAIN as the only accepted mechanism, does any client give the possibility 
to refuse a PLAIN auth ?)
* (possibly more controversial) it's the domain of TLS anyway, it's not 
XMPP's role to add yet another layer of hand-made security


Actually it seems to me that TLS remains the part that does server 
"authentication", and the token replaces only the SASL exchange for client 
authentication.

Thinking about it, maybe the server could actually send an authenticated 
blob as token, so that clients would use it as a challenge for the next 
authentication; along with the already existing resumption (198) and 
pipelining (305) mechanisms, it would look like that:

Client			     Server

[TLS hello]          --------->
                     <--------- [TLS response]
[TLS end]            --------->
[XMPP <stream>]      --------->
[XMPP <resume>]      --------->
[XMPP SASL w/ token] --------->
                     <--------- [XMPP <stream>]
                     <--------- [XMPP SASL confirmation]

      [XMPP data]    <-------> [XMPP data]

Or, with future TLS's 0-RTT handshake:

Client			     Server

[TLS handshake]      --------->
[XMPP <stream>]      --------->
[XMPP <resume>]      --------->
[XMPP SASL w/ token] --------->
                     <--------- [TLS response]
                     <--------- [XMPP <stream>]
                     <--------- [XMPP SASL confirmation]

      [XMPP data]    <-------> [XMPP data]

ie, 0-RTT handshake XMPP. There's probably a flaw somewhere though.

-- 
Matthieu Rakotojaona


More information about the Standards mailing list