First we'll talk the Domain Name System, foundation of PSYC's old federation operation mode. Further below find some thoughts on PSYC2's DNS-free mode of operation.
Contents |
PSYC1 Federation Style
Solid: Paranoid DNS
As an alternative to SASL or even using two TCP lines instead of one (Jabber dialback), psyced makes paranoid checks on the DNS credentials. Old-school, but works.
TLS-circuits however use a different strategy.
Solid: Dynamic DNS
Thanks to the consequent no-cache DNS resolution approach implented in psyced, even a dynamically changing IP address can serve up steady uniform network identifications.
All implementations of PSYC should support dynamic changes in the mapping from hostname to internet address this way. Should that not be the case, file a Bug Report.
Interestingly, we encountered one XMPP implementation, which not only caches DNS hostnames for a while - it does so for weeks until restart. The excessive caching trap in action.
DynDNS on your own domain name
How to configure dynamic DNS on your own domain name? Like this:
home.iswherethestuff.is. 44 IN CNAME example.homelinux.org.
44 is a particularely short TTL (time to live).
Liquid: DNS SRV in use
When a PSYC uniform has to be mapped to a host and port pair and no port is given in the uniform, a DNS SRV lookup SHOULD be performed to retrieve the real host and port number. The lookup is performed on _psyc._tcp.hostname (See also: RFC2782).
NOTE: The DNS SRV lookup SHOULD NOT return more than one host:port pair, as PSYC currently does not support mapping of hostnames to multiple IPs. Multiple hostnames of a PSYC node SHOULD NOT resolve to multiple ip:port combinations. These things have to be taken care of by the administrators of the PSYC nodes at the moment.
When UDP is selected as a transport, _psyc._udp.hostname MAY be consulted.
Should the SRV lookup fail or a port number was provided in the uniform, a forward hostname resolution of the A/AAAA or CNAME records is performed.
The resulting IP number and port of the resolution process may point to an already existing circuit. That circuit SHOULD be reused. If the root of the uniform hasn't already been verified as being a valid _target for that circuit, a _request_authorization is necessary.
SRV lookup may be circumvented by the user by allowing him to override the physical host and port numbers explicitly. This is different from restricting the user to provide a different uniform containing the port number.
A minimal application MAY leave out DNS resolution altogether, if the implications are understood and accepted. Best practice for SRV usage in 2008 is to support it in all PSYC applications, but to not deploy SRV usage in actual installations, if possible.
Try to support DNS SRV lookup, but avoid using it since there are still some platforms and applications that cannot easily implement SRV (like psyced on windows, or PSYC clients in Flash). This will change in the long term, but for now appended port numbers are safer.
If you set-up a SRV for psyced, and want it to also actively send using a port-less name, use the _uniform_node tuning. For XMPP in psyced, _xmpp-server is used according to specification.
Liquid: Using DNS as a directory service for PSYC
An idea from 1994 which is actually implemented in part in psyced. See Directory Service for details.
Vapor: DynDNS by certificate
tjgillies suggested we could be running our own dynamic DNS service, so we can provide psyced installers which will automatically install dynamic hostnames if the administrator doesn't have one of her own.
lynX went on to think that such a dynamic DNS service could be controlled by TLS-PSYC circuits. You just configure your desired hostname within our dyn.psyced.org domain, then send an update request to psyced.org which will authenticate you by your server's certificate or self-signed public key. First time you use it, psyced.org stores your certificate for that hostname - next time it serves you the desired hostname only if you still have that certificate.
This could be a tool to help build a web of trust as discussed in Encryption to circumvent the problem of lack of authority of certification authorities.
PSYC2: Addressing by public key
A fundamental new paradigm in communication software design as implemented by all pseudonymous systems is the idea that the recipient's public key is itself the address, so there can be no misunderstanding and no spoofing.
This is typically done by looking up the public key in a distributed hashtable. In the case of Tor Hidden Services the fingerprint is used and mapped to a pseudo domain name ending in .onion
A DHT can be seen or used as a generalized form of domain name system, only it isn't as established and omnipresent as DNS. In fact somebody has to run the DHT, which is not an appealing job. Usually nodes that participate in a P2P network also provide DHT functionality unless bandwidth or other restrictions do not recommend it. In the case of Tor for example, dedicated heterogeneous servers deliver the job, making Tor routers particularely lightweight.
Liquid: Resolution by Tor Hidden Services
As usual Tor hands out a very simple way to switch from traditional DNS to key addressing by DHT: Simply set up a hidden service and use its onion address. That is what psyced is currently trying to upgrade to. No need to run traditional federation at all. PSYC upgrades to Tor, then figures out GNUnet next:
Liquid: Resolution by GNS
But given we have a DHT, a resolution system could allow for any string to be a search item that resolves to a public key and a choice of current IP services. Since in our world you cannot own a word, other people may also be allocating that word. The DHT would store as many matches for any word or word combinations as people want to allocate, thus when you look for "news" you are likely to get plenty of keys while if you tell your customers to lookup "tom's hairdryer" only a spammer may intentionally want to collide with that. Your customers will be prompted with a choice of services and public keys. If the public key is also printed on the piece of paper they are holding in their hands they can pick the correct one and start cryptographically secured communications. Even better if they can just hold the card in front of the webcam and the software finds a public key in a QR code.
Some of these thoughts are actually superceded by the scientific work of the GNUnet developers which has led to an amazing privacy-enhancing technology for resolution called GNS (formerly GADS).
Vapor: Social resolution by GNS
Social networking: One of the key jobs of such a look-up DHT must also be to replace Facebook's ability to find long lost old friends. FB does it by suggesting people should use their real name and surname, so depending on the uniqueness of that name you have half a chance of finding her using the search box and a centralistic database. You can also search by e-mail address of course. In DHT-based thinking the person should allocate her email and former email addresses and several combinations of the <realname,birthdate> tuple so that people can find you if they know your name and year of birth, or your name and birthday without the year, or just your name and maiden name. Enough for people from high school days to find you. Your registration app would have to guide you through a good set of combinations worth registering. I suppose entries need to be refreshed on some weekly basis to avoid the DHT from getting messed up with old invalid data. Luckily GNS is really good at handling the privacy for these use cases.
Which other DHT-based resolution schemes have been written out in detail or are actually implemented and in use?