Specify Overlay Network via URI?

[indolering]

It would be ideal if users could specify overlay networks within the URI. This is somewhat similar to Ryan's unofficial epoch proposal which specifies the ownership period using a integer, such as example.1.bit. Note, however, that from a usability/psych standpoint users cannot be relied upon to validate the URI and the primary use case is for security conscious configurations.

I'm unsure of the best way to go about this and I'm sure that the following ignores a raft of implementation issues. Whatever the method, it is preferable that the lookup fail if the system does not support the given transport.

One option is to append the transport like a domain such as example.bit.onion, which would be passed to the DNS layer. Given the likelihood that .onion will be reserved to prevent piracy leaks, it may be prudent to add this to the section on Tor in IFA-0002, which deals with non-DNS record types, including Tor. While a .bit.onion address would never collide with real onion address, I am ignorant to how .onion addresses are handled and someone should at least check with them before adding support.

We cannot ensure that other suffixes can be used without risking stepping on future gTLDs. One possible workaround would be to use a single character, such as example.bit.i2p.x or a reserved suffix such as .invalid (which SIP apparently uses). It is also possible that the IEFT or ICANN could reserve a TLD for special use names, such as .alt. At the very least, it would probably be wise to keep IFA-0002 as a Draft until the fate of the .alt proposal is resolved.

[hlandau]

I think this is more of a long term thing, so let's change the label.

[JeremyRand]

FYI, I suggested using an invalid/reserved DNS label to indicate what network should be used. The example I gave was using a hyphen or underscore to prefix the network, and using that label as the 2nd-level label. So wikileaks._tor.bit or wikileaks.-tor.bit would result in NXDOMAIN for all queries except for the query asking for the "tor" field.

I'm not sure whether this will break some things that DNS does; after all, hyphens and underscores are probably reserved for a good reason. Maybe @hlandau can offer feedback?

@indolering I'm not sure why you mention a URI; the examples you give are domain names, not URI's. The URI has nothing to do with this.

[JeremyRand]

Totally as an aside, @indolering what use case are you intending here? I was generally aiming this at being a debugging tool, sort of like the .exit TLD. I don't see any application as a security feature; am I unaware of something?

[hlandau]

Some web servers, such as Apache, refuse to serve for hostnames which contain underscores, on the grounds that underscores must not appear in hostnames. I don't know whether it enforces this for all labels or the first one, but I'm guessing it probably enforces it for all of them. Of course there will be vhosting issues with this anyway.

A suffix such as xz--tor would probably be better, since this aligns with how IDN solved the problem, by playing on the general prohibition on consecutive dashes in domain names. But consecutive dashes should be fully supported, I think YouTube's CDN uses them a lot.

[JeremyRand]

@hlandau Does Apache allow hostnames to start with a hyphen? My understanding is that ICANN disallows 2nd-level domain labels to start with a hyphen.

[hlandau]

I doubt it prohibits this, but you'd have to test it yourself.

[indolering]

Totally as an aside, @indolering what use case are you intending here? I was generally aiming this at being a debugging tool, sort of like the .exit TLD. I don't see any application as a security feature; am I unaware of something?

I meant it as a security feature, to ensure a connection is using a specific transport.

FYI, I suggested using an invalid/reserved DNS label to indicate what network should be used. The example I gave was using a hyphen or underscore to prefix the network, and using that label as the 2nd-level label. So wikileaks._tor.bit or wikileaks.-tor.bit would result in NXDOMAIN for all queries except for the query asking for the "tor" field.

I was aiming for a syntax that would ensure that it is passed to DNS. Using a syntax that would force the DNS client to throw an error and prevent the lookup is a good idea. However, it could cause issues with applications that perform error checking on the URL.

I'm not sure whether this will break some things that DNS does; after all, hyphens and underscores are probably reserved for a good reason. Maybe @hlandau can offer feedback?

We could implement this at the application level. However, if we take that route, I would probably be more in favor of overloading the port designation (wikileaks.bit:tor).

@indolering I'm not sure why you mention a URI; the examples you give are domain names, not URI's. The URI has nothing to do with this.

Uhh, a domain name is a URL and a URL is a URI.

[indolering]

The Apache issue is a good point, we might not be able to do this just on the DNS level : (

[JeremyRand]

I meant it as a security feature, to ensure a connection is using a specific transport.

Specifically under what circumstances does this improve security?

Uhh, a domain name is a URL and a URL is a URI.

A URI may sometimes contain a substring that is a domain name (though this does not always occur), but I have never seen a URI that is a domain name.

[indolering]

Specifically under what circumstances does this improve security?

The use-case is very similar to that of epoch notation. It would allow Wikileaks to give instructions that would ensure all browser requests are routed to a Tor hidden service instead of through exit nodes. It would also be helpful for configuration files (email client, etc).

For some reason, I thought this feature was generally agreed upon as a good idea. If this isn't something that you plan on implementing, then it should probably be tabled.

A URI may sometimes contain a substring that is a domain name (though this does not always occur), but I have never seen a URI that is a domain name.

Let's not devolve into an argument on the finer points of category theory : )