REQUEST FOR COMMENTS (literally): The d/ specification

https://bit.namecoin.org/
biolizard89
Posts: 1974
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by biolizard89 » Thu May 21, 2015 9:20 am

johnc wrote:Not sure if related, but how does NMC handles TLS revocations?
This guy is working on that and i think it could very well either use namecoin or give his opinion.

https://github.com/ChristopherA/revocab ... cates-hack
In Namecoin, to revoke a TLS cert, you remove its fingerprint from your name. The changes will usually propagate worldwide in about 40 minutes (10 minutes for a Namecoin block; 30 minutes for NMControl's cache to clear). I think it is possible to reduce that from 40 minutes to about 10 seconds via a combination of accepting unconfirmed name operations (which are safe), and smarter NMControl cache handling.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by phelix » Thu May 21, 2015 11:02 am

biolizard89 wrote:
johnc wrote:Not sure if related, but how does NMC handles TLS revocations?
This guy is working on that and i think it could very well either use namecoin or give his opinion.

https://github.com/ChristopherA/revocab ... cates-hack
In Namecoin, to revoke a TLS cert, you remove its fingerprint from your name. The changes will usually propagate worldwide in about 40 minutes (10 minutes for a Namecoin block; 30 minutes for NMControl's cache to clear). I think it is possible to reduce that from 40 minutes to about 10 seconds via a combination of accepting unconfirmed name operations (which are safe), and smarter NMControl cache handling.
There is a difference though: a name can't be revoked once it's stolen whereas with Allen's method you only need a copy of the key to do so.

Translated to Namecoin it would mean this: If a name moves to another address it is revoked. IMHO this is worth pondering on.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 1974
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by biolizard89 » Thu May 21, 2015 11:24 am

phelix wrote:
biolizard89 wrote:
johnc wrote:Not sure if related, but how does NMC handles TLS revocations?
This guy is working on that and i think it could very well either use namecoin or give his opinion.

https://github.com/ChristopherA/revocab ... cates-hack
In Namecoin, to revoke a TLS cert, you remove its fingerprint from your name. The changes will usually propagate worldwide in about 40 minutes (10 minutes for a Namecoin block; 30 minutes for NMControl's cache to clear). I think it is possible to reduce that from 40 minutes to about 10 seconds via a combination of accepting unconfirmed name operations (which are safe), and smarter NMControl cache handling.
There is a difference though: a name can't be revoked once it's stolen whereas with Allen's method you only need a copy of the key to do so.

Translated to Namecoin it would mean this: If a name moves to another address it is revoked. IMHO this is worth pondering on.
I actually brought this up a while back, see https://forum.namecoin.info/viewtopic.php?f=5&t=2226
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

biolizard89
Posts: 1974
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: REQUEST FOR COMMENTS (literally): The d/ specification

Post by biolizard89 » Thu May 21, 2015 4:13 pm

domob wrote:I'm also for IDN. If there are security concerns, the browser should handle them adequately (disallowing mixed script or even displaying the xn-- literally in case of paranoid users). I have no opinion on the draft apart from that, since I'm not a DNS or d/ expert.
@Daniel, you should look at the "import" part of the spec, as it differs from the spec that we partially implemented for NMControl (and it has an effect on the id/ namespace, specifically saying that "import" is no longer namespace-agnostic).

@Hugo, a few more comments:

I would like the "import" spec description to include some more non-normative examples, particularly of the subdomain selector.

Also, I would like to see an optional third argument to an import, which consists of an array of the fields being imported. E.g. ["ip", "ip6"] would restrict the import to just those two fields (after applying the "import" fields in the imported name) rather than also importing things like TLS fingerprints. A value of ["*"] would be the default, and would import everything.

Finally, we should consider whether we should (possibly as a future revision) limit the "tor" and "i2p" fields to only be permitted to point to Tor and I2P domains that have authorized the d/ name in question (e.g. by signing the d/ name with the .onion key). Both Fabio from GlobaLeaks and Jesse from OnioNS think that this is a highly useful property. I don't want to delay approval of this spec while we figure out the format for such a signature, but if it's something that we even might do in the future, there should be a note in the spec saying that users of "tor" and "i2p" should be aware that the spec may change in a way that will require changes to existing name configurations.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply