DN: Should Tor/I2P require signed nomination? Should we add WIP disclaimer to dn-1.0?

[JeremyRand]

Maybe also include Freenet in this category. As well as CJDNS, OnionCat, GarliCat, and ZeroNet, assuming that we add them to the spec at some point.

[indolering]

The trouble is that adding this capability will take some time and effort. I would prefer to see handling of non-traditional network addresses broken out of the main domain spec. This would enable us to support progressive enhancement of such features without having to replace the core spec each time we alter the handling of these different networks.

[JeremyRand]

@indolering that makes no sense. You could argue that every field should be broken out of the d/ spec by that logic. This is Git, we have the ability to see history of a file. So it doesn't require "replacing the core spec", it's a small change that everyone can vet and see the history of. Readability requires that this be in one place.

Also, taking time/effort isn't relevant here. I'm not proposing delaying the spec for those features. I'm proposing placing a warning next to the tor/i2p/freenet fields that their API is not considered stable and might be subject to revision, which as far as I can tell is true since we don't have a consensus on how to do backlink signatures (nor do we actually have a consensus, as far as I know, that we want to do backlink signatures at all).

[indolering]

@JeremyRand I was under the impression that specs would be replaced, not upgraded. I specifically remember being shot down when I suggested versioning....

If you refer to IFA-0000, it adopts the Python and Bitcoin convention of specs being finalized only after we have a working implementation ... maybe that is what you are referencing?

[hlandau]

I don't have any issue with breaking out tor/i2p/freenet into a supplementary specification, IFA-0002, which can remain a draft for the time being.

[indolering]

I think we should outline the syntax for Non-DNS Item Types in IFA-0001 and push network-specific details to IFA-0002. Then, if we need to break networks out into individual drafts we can do so without having to replace IFA-0001.

[indolering]

So, to get back to the original point of this thread:

Should Tor/I2P require signed nomination?

What attack would this prevent?

Should we add WIP disclaimer to dn-1.0?

It's Draft status...

[JeremyRand]

What attack would this prevent?

Right now someone can create a d/ name that references a Tor/I2P/Freenet service without having any ownership of that service. This makes phishing easier, because even if an end user knows which Tor/I2P/Freenet service he's going to, he doesn't know which of several d/ names is the correct one. Requiring the Tor/I2P/Freenet service to sign the d/ name would allow an end user to be confident that if he trusts the Tor/I2P/Freenet service, then the d/ name that references it is also trustworthy.

This was brought up by at least 2 Tor community members, including Fabio from GlobaLeaks.

[hlandau]

If they already know the correct hidden service, why don't they just use that? And site operators can publish the correct domain on their site.

I seriously doubt that people are going to go to the trouble of doing a reverse search for d/ names referencing a hidden service. It'd be simpler just to bookmark it.

This seems like an argument in favour of not making a reverse search tool for user use, not complicating references to hidden services.

[JeremyRand]

I agree that the use cases are limited. Some Tor community members think it is useful, though.

I think there are actually two separate questions here.

1. Should we provide a method for hidden services to publish signatures for d/ names if they want to?
2. If so, should it be required for the d/ name to resolve to the hidden service?

I think (1) is more clearly a yes than (2). But I'd have to think about this a bit more.

[hlandau]

How about this: We define "tor": [["d/..."]] to be equivalent to ["d/..."], and similarly for the other darknet services. This will allow future extension with something like: [["d/...", {...}]]. Current implementations must ignore everything but the first field.

[JeremyRand]

If I were designing a spec for .onion->.bit signatures, I would place the sigs in a different namespace, indexed by the .onion name (using a prefix match rather than an exact match to avoid squatter attacks). That way it's easy to look up a .bit if all you have is the .onion. So I don't see any need to mess with the d/ spec, other than stating that we might introduce additional constraints on what constitutes a valid value for the tor/i2p/freenet fields. Unless you see a reason to add additional data to the d/ name?

[hlandau]

If you're happy with the spec as it stands, then I take it this isn't a blocker for the finalization of domain-names?

[indolering]

This makes phishing easier, because even if an end user knows which Tor/I2P/Freenet service he's going to, he doesn't know which of several d/ names is the correct one. Requiring the Tor/I2P/Freenet service to sign the d/ name would allow an end user to be confident that if he trusts the Tor/I2P/Freenet service, then the d/ name that references it is also trustworthy.

You are assuming that someone will grep through the blockchain to find records with the address. This won't happen, anyone who has GlobalLeaks' onion address will visit that address to figure out GlobalLeaks' .bit domain. It's an order-of-magnitude more difficult to lookup the address from the blockchain.

Even if someone does search through the blockchain, wouldn't they notice that there are MULTIPLE domains pointing to that onion address?

And since the attacker is pointing the user to the correct network address, how would they intercept the information anyway? Doesn't this attack rely on a user looking up the domain (in a totally non-plausible manner) and then using it AFTER the attacker has altered the config to point to a .onion address they control?

If so, should it be required for the d/ name to resolve to the hidden service?

Even if we accept the scenario in which someone greps through the blockchain to find an address, what's to stop someone from putting the address into their record but misconfiguring it and using a sneaky import to resolve to a different onion address?

Should we provide a method for hidden services to publish signatures for d/ names if they want to?

No, not until they can articulate a plausible attack. As it stands, this feature does nothing to combat phishing, it just complicates the spec and implementations without any appreciable increase in security.

This is akin to airport security confiscating bottles of wine and pocket knives. If anything, such proposals decrease security because everyone wastes their time/effort on useless bullshit.

If GlobalLeaks' doesn't want other domains resolving to their website, they should alter their server configuration. Seriously, they need to alter their server config to prevent an attacker from dropping their site into an iFrame anyway, they might as well specify valid domains while they are at it.

I agree that the use cases are limited. Some Tor community members think it is useful, though.

That doesn't mean it's a good idea. The Tor community has raised issues in the past that didn't make sense because they hadn't fully thought through the system.

If they are worried about phishing then we should be working on technology that actually combats phishing. I don't believe that the TBB utilizes the PhishTank, but it would fairly trivial to add client-side blocking based on a static list of keywords. I eventually want to start publishing a list of domains with high-abuse potential.

[JeremyRand]

I've just asked the GlobaLeaks guys for some clarification on exactly what they need.

[JeremyRand]

@hlandau I would like a note in the d/ spec saying that we might revise the Tor/I2P/Freenet requirements in the future, so that people don't erroneously infer that we're guaranteeing a stable API. We can remove that note if we decide later that we're not going to use backlinks.

[hlandau]

A disclaimer has been added. Issue closed.