Dirk Meyer wrote:
Jonathan Dickinson wrote:Requiring serverless messaging is a deceiving lure.
It is not. That's link-local or zero-configuration networking, and it's quite a popular technology (see XEP-0174, iChat's Bonjour mode, etc.).
What if the client is behind a symmetric NAT? Or some NAT that simply doesn't working with STUN (or ICE/SIP/whatever)? They can't open a encrypted session?No, in that case they need the "help" of a server. IMHO the real use case for serverless messaging is in the LAN. Back to my application control using XMPP: I want to access my set-top box from other devices in my LAN even if my DSL link is down.
Agreed, this is an important use case.
If there is a XEP that defines a stream in a stream (I think there was), one would open a new stream to a remote contact and simply do a starttls. In the case that both clients can be accessed (if they are behind a supporting NAT, or have a public IP) they can open the stream to each other directly and do a starttls.That is the basic idea of XEP-0247 with the help of XEP-0246. We either use serverless messaging or XEP-0247 to open a "connection" to the peer and use XEP-0246 to open a new stream and use starttls. The question we had (and that is the reason I started the discussion) is: how to verify the TLS certificates.
Thanks for bringing the thread back to the original topic. We had some discussions about this at the XMPP Summit in Portland a month ago, but no hard conclusions. There's no stable JID (you have a link-local address) but perhaps the certificate could also be tied to a stable JID and you form an association between the stable JID and the link-local JID.
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
