[Standards] XTLS revisited

Marcus Lundblad ml at update.uu.se
Mon Dec 15 16:12:02 UTC 2008


mån 2008-12-15 klockan 08:46 -0700 skrev Peter Saint-Andre:
> Recently I've been chatting with some folks off-list about end-to-end
> encryption. I've concluded that while it is possible to set up an
> end-to-end XML stream (XEP-0246) using Jingle (XEP-0247) and then
> upgrade that stream to encrypted using STARTTLS, we don't need that
> complexity because you already have a reliable connection to the other
> person: it's called XMPP (there's nothing to negotiate here and no need
> for SOCKS5 Bytestreams or ICE-TCP or any of that madness, just use XMPP
> for the transport). Therefore I suggest that we simplify e2e by using
> something very close to the original XTLS proposal to set up, use, and
> tear down and XTLS tunnel. I've outlined the protocol below.
> 
Would it make sense to use an in-band bytestream (XEP-0047) for the
tunneling part?
I'm not sure if that would be really appropriate for this case, since it
is a stream of potentially variable-sized data packets being sent.
Using IBB might allow more code reuse...

Just a thought

//Marcus

> 1. Initiator sends start request to responder
> 
> <iq from='romeo at montague.net/orchard'
>     id='xtls_1'
>     to='juliet at capulet.com/balcony'
>     type='set'>
>   <start xmlns='urn:xmpp:tmp:xtls'/>
> </iq>
> 
> 2. Responder tells initiator to proceed
> 
> <iq from='juliet at capulet.com/balcony'
>     id='xtls_1'
>     to='romeo at montague.net/orchard'
>     type='result'>
>   <proceed xmlns='urn:xmpp:tmp:xtls'/>
> </iq>
> 
> 3. Initiator and responder complete TLS handshake
> 
> <iq from='romeo at montague.lit/orchard'
>     id='xtls_2'
>     to='juliet at capulet.lit/chamber'
>     type='set'>
>   <data xmlns='urn:xmpp:tmp:xtls' method='x509'>
>     base_64(TLS-Handshake-Messages)
>   </data>
> </iq>
> 
> <iq from='juliet at capulet.lit/chamber'
>     id='xtls_2'
>     to='romeo at montague.lit/orchard'
>     type='result'/>
> 
> <iq from='juliet at capulet.lit/chamber'
>     id='xtls_3'
>     to='romeo at montague.lit/orchard'
>     type='set'>
>   <data xmlns='urn:xmpp:tmp:xtls'>
>     base_64(TLS-Server-Handshake-Messages)
>   </data>
> </iq>
> 
> <iq from='romeo at montague.lit/orchard'
>     id='xtls_3'
>     to='juliet at capulet.lit/chamber'
>     type='result'/>
> 
> 4. One party sends a stanza over the tunnel
> 
> 4a. Generate stanza
> 
> <message
>     from='romeo at montague.lit/orchard'
>     to='juliet at capulet.lit//chamber'
>     type='chat'>
>   <thread>act2scene2chat1</thread>
>   <body>
>     I take thee at thy word:
>     Call me but love, and I'll be new baptized;
>     Henceforth I never will be Romeo.
>   </body>
>   <active xmlns='http://jabber.org/protocol/chatstates'/>
> </message>
> 
> 4b. Strip off the routing data
> 
> <message type='chat'>
>   <thread>act2scene2chat1</thread>
>   <body>
>     I take thee at thy word:
>     Call me but love, and I'll be new baptized;
>     Henceforth I never will be Romeo.
>   </body>
>   <active xmlns='http://jabber.org/protocol/chatstates'/>
> </message>
> 
> 4c. Encrypt and base64-encode it
> 
>     base_64(TLS-Encrypted-Message)
> 
> 4d. Send it over the tunnel
> 
> <iq from='romeo at montague.lit/orchard'
>     id='xtls_4'
>     to='juliet at capulet.lit/chamber'
>     type='set'>
>   <data xmlns='urn:xmpp:tmp:xtls'>
>     base_64(TLS-Encrypted-Message)
>   </data>
> </iq>
> 
> <iq from='juliet at capulet.lit/chamber'
>     id='xtls_4'
>     to='romeo at montague.lit/orchard'
>     type='result'/>
> 
> 5. One party closes the tunnel
> 
> <iq from='romeo at montague.net/orchard'
>     id='xtls_10'
>     to='juliet at capulet.com/balcony'
>     type='set'>
>   <close xmlns='urn:xmpp:tmp:xtls'/>
> </iq>
> 
> 6. Other party acknowledges the close
> 
> <iq from='juliet at capulet.com/balcony'
>     id='xtls_0'
>     to='romeo at montague.net/orchard'
>     type='result'>
>   <closed xmlns='urn:xmpp:tmp:xtls'/>
> </iq>
> 
> That's it! Yes, there are some slight further complexities (e.g.,
> including "offer" information as in XEP-0250) and error flows to
> document, and we need to carefully define the use of X.509 certs, PGP
> keys, secure remote password, and other methods. But I don't think that
> end-to-end encryption needs to be much more complex than what I've
> outlined above (at least on the wire -- the complexities emerge from the
> user interface, cert/key management, etc.).
> 
> Dirk Meyer and I are working to update the original XTLS proposal
> accordingly, and will have a document to share in the next day or two.
> Until then, our work in progress is here (we'll post again once it is
> more stable):
> 
> http://xmpp.org/extensions/inbox/xtls.html
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://stpeter.im/





More information about the Standards mailing list