On the IPv4 + NAT Internet, it is only possible to do real peer-to-peer connections within a single private internet (peer to peer connections cannot cross NAT gateways). However in the IPv6 Internet, there is no NAT and there is a single monolithic global address space. In theory any IPv6 node with a global address can connect directly to any other IPv6 node with a global address, anywhere in the world, so long as no router or firewall between those nodes blocks the port used.
Peer-to-peer direct will become very common, especially on 5G devices like cellphones and IoT devices. Client/Server using centralized servers works fine on the IPv6 Internet, but is not required as it is on the IPv4 + NAT Internet.
One of the major advantages of real peer-to-peer connections is that only one network link is involved (compared with two or more in the IPv4 + NAT Internet). TLS works much better on a single link, than over multiple links. However we can take it one step further, and treat the two nodes as real peers. With PeerTLS, both nodes use a client cert, that identifies a person or device instead of a node (as is the case with a server cert).
First, PeerTLS can provide true end-to-end encryption. There is no intermediary node where traffic will be in plaintext. Second, it can provide certificate based mutual strong authentication, so both parties know for certain who the other party is. This is not possible with traditional TLS, especially when multiple links are involved. This also allows very strong whitelisting and blacklisting that can be enforced during the TLS handshake.
If someone doesn’t have a certificate from an issuer you trust, or is on a blacklist, your node can actually drop the connection attempt during the handshake. This can eliminate much fraud and unwanted commercial messages (SPAM). There should be some mechanism for people to request being added to your whitelist based on their certificate, or you could permit connections from anyone with a valid cert from an organization (if you trust that organization to issue certs only to acceptable contacts).
While there isn’t any intermediate server, every node has both a client component that can initiate outgoing connections, and a server component that can accept incoming connections. On a real OS (e.g. Windows or MacOS) the server component can be running at all times. When an incoming connection is accepted, the server component can spawn a thread or process to handle it. An “incoming connection” window can appear to handle that connection.
When you initiate an outgoing connection, again a thread or process can be spawned to handle it, and an “outgoing connection” window will appear. This will allow multiple messaging sessions on a single node.
On mobile devices, due to limited screen real estate and a simpler OS, it will typically only handle one incoming connection or one outgoing connection at any given time. It’s possible some kind of “call waiting” popup could alert you that someone is trying to connect if a session is already in progress.
This requires that every user of the system be issued a valid client certificate, capable of doing client and server authentication. Based on testing, most existing client or S/MIME certs will work. However, certs that only include an email address (E=<your email>) will not provide as good an authentication. It is recommended that certs for PeerTLS include at least userID or email, plus Common Name, e.g. Eemail@example.com, CN=Lawrence Hughes. The SixID userId uses the same syntax as an email address, but you could request a certificate with UserID instead of email, e.g. UIDfirstname.lastname@example.org, CN=Lawrence Hughes.
That way, when you have an incoming call you can see who is calling you, by name in addition to email or userID. In theory the user’s name could be retrieved from a contact database based on the supplied certificate.
Need for a Better Directory Service for End-to-End Direct Connections
Traditional Client/Server messaging with intermediate servers can use DNS for clients to find one of the relatively small number of largely static intermediate serves (for Email, Chat, file transfer, etc).
But DNS has some shortcomings for totally decentralized, peer-to-peer direct messaging:
- DNS still largely involves manual registration, in many cases by editing text files (zone files). This will not scale to billions of nodes.
- DNS uses caching which could cause problems with mobile nodes – by the time the information propagates through caches, you will be gone.
- DNS has no per-user authentication. If I register my information in DNS via protocol, anyone else could modify or delete that.
- DNS can only lookup IP addresses by Fully Qualified Domain Names. This means the server end is identified by a nodename, not a person or device. Most 5G devices will not even have FQDNs, and even if they do, how could I discover the nodename for your phone, so I could lookup your IP address.
- IPv6 addresses will be very dynamic, especially on mobile devices, like phones. If I go to a coffeehouse that provides IPv6 by WiFi, or if I move from office to home, I will be getting new IPv6 addresses frequently. I need to be able to securely update my IP address, and other people need to be able to retrieve it based on my email address, userId, telephone number, etc – not by nodename.
Because of this, I created a radically new directory service called SixID. It addresses all of the above issues. Like IRP, it supports per-user authentication, with username/password or Strong Client Authentication with a client digital certificate (which could be the same one used for PeerTLS).
Each Internet subdomain can have its own SixID server, discovered via DNS SRV records. I plan to even implement recursive queries like DNS can do. You will ask your local server to resolve someone by useriD, and if that userID is not hosted on your SixID server, it will be able to find the server that does host that userID do a query on your behalf, and return the information to you. This means SixID can become a global directory service (at least for queries by userID).
SixID includes your client cert as one of the aspects of your identity, so if I want to send an encrypted file to you by FTPS or Peer-to-peer SMTP, I can obtain your cert from SixID and send an S/MIME encrypted message directly to you. You will have the private key needed to open the file or message.
It also includes your key material (cert and private key) in PKCS12 format, protected with a passphrase known only to you. This will provide key backup and recovery.
SixTalk (now in development) uses IRP to obtain client certs automatically from any IRP enabled CA. It can also register the obtained key material in SixID (both certificate and PKCS12), and optionally escrow your key material for compliance.
Compared to current messaging platforms (Skype, WhatsApp, Messenger, Signal, etc), SixTalk has the following advatanges:
- Fully IPv6 compliant, including end-to-end direct, but can still work over IPv4 in legacy Client/Server mode
- Real end-to-end encryption and mutual strong authentication in end-to-end direct mode
- Uses industry standard protocols (VoIP/SIMPLE, FTPS, etc)
- Integrated with SixID / Active Directory with per-user authentication
- Fully automated certificate management via IRP