REQUEST FOR COMMENTS (literally): The d/ specification

[hla]

The draft Domain Names specification is now available: https://github.com/hlandau/ncdocs/blob/ ... n-names.md

This is a literal request for comments (not an RFC). If you have any questions, comments or issues with the specification, please post them now or forever hold your peace.

Overview
The new specification sanitizes a lot of the cruft that has built up in the specification listed on the wiki. It also makes breaking changes for the cause of greater sanity and syntactic consistency. While implementations are free to support older syntaxes, this document specifies the directives which should be considered preferred for use going forward.

Note in particular that the format for SRV and TLSA records has changed substantially. import has been clarified and delegate deprecated, as import is a superset of its functionality. An experimental mechanism for the opaque insertion of otherwise unsupported DNS records has been added. DNSSEC-enabled delegation via NS and DS is, of course, supported.

Further changes may still be made, but I think this is pretty close to the finished result.

[phelix]

whooha

The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace

+1

Could you give an example of how a TLS record looks like?

IMHO at least for the end user international characters should not be allowed. It makes tricking users way easier. Consequently I vote for disallowing "xn--" altogether.

[biolizard89]

whooha

The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace

+1

Could you give an example of how a TLS record looks like?

IMHO at least for the end user international characters should not be allowed. It makes tricking users way easier. Consequently I vote for disallowing "xn--" altogether.

There was a discussion about IDN homograph issues a while back on this forum; I think it was mentioned that most browsers will refuse to load domains that are mixed-script. I'm not sure if that's sufficient protection, and I haven't actually tested that behavior.

[hla]

whooha

The JSON object SHOULD be encoded as compactly as possible, without unnecessary whitespace

+1

Could you give an example of how a TLS record looks like?

IMHO at least for the end user international characters should not be allowed. It makes tricking users way easier. Consequently I vote for disallowing "xn--" altogether.

The following example record from RFC 6698:

Code: Select all

  _443._tcp.www.example.com. IN TLSA (
      0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
            7983a1d16e8a410e4561cb106618e971 )

translates to:

Code: Select all

{
  "map": {
    "www": {
      "map": {
        "_tcp": {
          "map": {
            "_443": {
              "tls": [[0,0,1,"0qveJA180+5rSyjFTfA0uXmDodFuikEORWHLEGYY6XE="]]
            }
          }
        }
      }
    }
  }
}

I'm against disallowing IDN. There's no need to second-guess this decision, as it's already been made. If you're paranoid about it, just display xn-- domains literally, don't refuse to process them. If the user types an IDN domain, that can be translated to punycode; what the user types should be an adequately trustworthy indication of the desired endpoint.

[biolizard89]

As was stated on IRC, Hugo's format for TLSA is definitely simpler to process for DNS bridges than Pagel's draft, and also easier for people who know DNS to use. Maybe this is a stupid question, but how is the "allow subdomains" bool handled in Hugo's spec?

I don't see any problem with allowing IDN's myself.

[domob]

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.

[biolizard89]

Is this thread a good place to discuss the format of "import" in Hugo's spec? I know that was in a different thread prior to the spec being posted here... @Hugo do you prefer that to be here or in the other thread?

[phelix]

@hla: thanks for the example. I like the encoding. Besides that the nesting looks horribly complicated but I guess we can't get around it.

This may not be the right place to discuss but I have a very strong opinion against allowing IDN: http://en.wikipedia.org/wiki/IDN_homograph_attack Also I see only a tiny benefit from IDN.

[biolizard89]

This may not be the right place to discuss but I have a very strong opinion against allowing IDN: http://en.wikipedia.org/wiki/IDN_homograph_attack Also I see only a tiny benefit from IDN.

According to https://en.wikipedia.org/wiki/IDN_homog ... the_attack , Firefox uses a TLD whitelist, while Chromium blacklists IDN's whose charset is not entirely from exactly 1 of the user's chosen languages. Generally I think Chromium's approach makes more sense; does anyone know why Firefox doesn't do this?

[johnc]

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