Peter Saint-Andre wrote: > I have no objections to that approach. So send raw TLS handshake over > IBB or SOCKS5 Bytestreams or ICE-TCP or whatever. Correct?
Yes, right after it is open. >> We know that we want to use TLS, there is no point in doing all >> this. We can negotiate XEP-0250 while we create the stream in >> (2). After that, give the stream to the TLS lib and wait until it is >> set up. I propose: >> >> 2a. Initiator and responder agree on transport and negotiate IBB or >> SOCKS5 (or future ICE-TCP) connection >> >> 2b. Initiator and responder exchange XEP-0250 information > > Couldn't that be part of the Jingle offer? I would foresee something > like this: > > <iq from='[email protected]/foo' > id='jingle1' > to='[email protected]/bar' > type='set'> > <jingle xmlns='urn:xmpp:jingle:0' > action='session-initiate' > initiator='[email protected]/foo' > sid='851ba2'> > <content creator='initiator' name='e2e-tls'> > <description xmlns='urn:xmpp:jingle:apps:tls'> > <methods> > <method name='x509'> > > <print>72:72:DF:06:3A:4D:7D:80:97:0E:53:77:0A:8F:CD:A9:80:A3:CB:38</print> > </method> > <method name='openpgp'> > > <print>E5:59:E9:8A:9B:C9:ED:0F:60:21:FD:EA:34:BF:24:E4:0D:B0:FE:FC</print> > </method> > <method name='srp'/> > </methods> > </description> > <transport xmlns='urn:xmpp:jingle:transports:ibb:0'/> > </content> > </jingle> > </iq> > > That is, I'd like to negotiate an e2e TLS session with you over IBB. > Hint: I could use X.509, OpenPGP, or SRP as the TLS method. For X.509 > I'd use a certificate whose fingerprint is "72:72:DF:..." and for > OpenPGP I'd use a key whose fingerprint is "E5:59:E9:..." and for SRP > we'd use some shared secret known to the two of us. Yes, that could be the starting point of XEP-0250. But the peers need to agree what method to use. The initiator needs to send its offer to the recipient in the Jingle initiate. Now the recipient knows what methods will work. E.g. if it has no way to verify the openpgp key, it can not be used. So XEP-0250 defines an offer back with the the recipient's keys, removed by the methods that the recipient knows will fail. Now the initiator needs to check if it can verify the recipient's keys and defines what method should be used. This is what I want to do in 2b. > Would it be better for the responder to be the TLS server and the > initiator to be the TLS client? That is similar to how we do things for > c2s right now (receiving entity is the TLS server). Yes, we could do that, too. I only made it that way because the recipient starts the stream opening. Dirk -- Ever notice how fast Windows runs? Neither did I...
