[Proposal] Changes to TLS spec + Enforcement of TLS for http

[phelix]

So, long story short... I agree with you. However, we should get feedback from phelix / moa / snailbrain / domob. And Indo should be able to respond.

My understanding of TLS matters is very limited. It would be nice if you could agree on a solution. As you wrote the TLS plugin you are the namecoin TLS chief

[Pagel1928]

biolizard89 brought up an issue with the current TLS proposal:

What should happen when there is a TLS record present, and a ip and onion record, where the user does not want to specify the TLS record for the onion?

For example the following json:

Code: Select all

{
   "ip":"192.168.1.1",
   "ip6":"2001:4860:0:1001::68",
   "tor":"eqt5g4fuenphqinx.onion",
   "tls":{
      "tcp":{
         "443":[ [ 1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1 ] ]
      }
   }
}

This would imply the tls record for tcp port 443 would be applied to ip/ip6 and tor.

A possible solution is formating it like this:

Code: Select all

{
   "ip":[
      "192.168.1.1",
      {
         "tls":{
            "tcp":{
               "443":[ [ 1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1 ] ]
            }
         }
      }
   ],
   "ip6":[
      "2001:4860:0:1001::68",
      {
         "tls":{
            "tcp":{
               "443":[ [ 1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1 ] ]
            }
         }
      }
   ],
   "tor":[ "eqt5g4fuenphqinx.onion" ]
}

This is pretty ugly, any thoughts about how we could do it better?

*edit* The array would have to go one more deep, since you can already have multiple ip addresses in one record, but you might want to associate a TLS fingerprint with a specific ip.

*edit 2* An additional thing to notice, is that includeSubdomains only makes sense when using ns records.

[sugarpuff]

DNSChain now includes partial support for this (work-in-progress) specification.

Please see `tls2tlsa` in globals.coffee for the details. Feel free to submit PRs to add improved support!

[biolizard89]

For the record, the reason FreeSpeechMe hasn't implemented this spec is because the spec is poorly defined to the point that it's not possible IMO to make a sane implementation.

The main issues are (if I recall correctly):

1. No mechanism for HSTS-style enforcement. I think HTTP clients should assume HTTPS if there's a port 443 cert listed. This should be configurable by the name owner, but should be enabled by default. Something like {"notls80": "true"} to force port 80 connections to not upgrade to HTTPS on port 443.
2. No mechanism for restricting TLS to certain resolvers. Something like {"notls": ["onion", "i2p"]}.

[Pagel1928]

My previous post covers both of your issues. ( http://forum.namecoin.info/viewtopic.ph ... t=10#p7549 )

If a fingerprint is present it must be enforced. It is a lot nicer because the authentication is bound directly to the "location" (ipv4/ipv6/onion).

[biolizard89]

My previous post covers both of your issues. ( http://forum.namecoin.info/viewtopic.ph ... t=10#p7549 )

If a fingerprint is present it must be enforced. It is a lot nicer because the authentication is bound directly to the "location" (ipv4/ipv6/onion).

I think we're in agreement that fingerprints should be enforced under normal circumstances. (HTTP is a special case because someone might want to run a non-HTTP service on port 80, while running HTTPS on port 443.)

I think your example syntax uses a lot of storage. Is there a practical, real-world benefit to enforcing different sets of certs for IPv4 and Tor? If either set of certs is compromised, you're screwed, so why not list all of those certs together and just have a "notls" field which accepts a list of resolvers which don't use TLS? Uses way less storage, and is more backward-compatible, for what I think is no practical disadvantage.

[crosser]

I don't think that attaching tls fingerprints directly to the ip elements is a right thing to do. Even if we ignore the "strange" syntax, imagine you have one server that is accessible over several ipv4 and several ipv6 addresses, plus maybe over tor or by other means. It would be conceptually wrong, not to say wasteful, to duplicate the same fingerprint in multiple elements of the domain object.

Better to stay closer to DANE, in my opinion.

[Pagel1928]

My previous post covers both of your issues. ( http://forum.namecoin.info/viewtopic.ph ... t=10#p7549 )

If a fingerprint is present it must be enforced. It is a lot nicer because the authentication is bound directly to the "location" (ipv4/ipv6/onion).

I think we're in agreement that fingerprints should be enforced under normal circumstances. (HTTP is a special case because someone might want to run a non-HTTP service on port 80, while running HTTPS on port 443.)

I think your example syntax uses a lot of storage. Is there a practical, real-world benefit to enforcing different sets of certs for IPv4 and Tor? If either set of certs is compromised, you're screwed, so why not list all of those certs together and just have a "notls" field which accepts a list of resolvers which don't use TLS? Uses way less storage, and is more backward-compatible, for what I think is no practical disadvantage.

With the syntax above it is flexible, you can specify a "sshfp" fingerprint instead of "tls" for your ssh server, on which specific port and address.

Specifically with Tor, you might want to add a "torcert" to authenticate using a full Tor certificate (instead of just the truncated hash of the certificate).

Probably the data should be stored in such a way where duplicate data (such as fingerprints) just points to a reference, to save data. Also changing the format from JSON to a compact binary format), but that is a separate subject and I don't think storage should be a concern while everything else is not attempting to be compact in any way.

Ideally, namecoin would enforce an "authentication" mechanism for all "locations", that way no service accessible via a .bit domain would ever not be end-to-end secure. This also means TELNET/HTTP/FTP wouldn't exist on .bit domains.

I don't think that attaching tls fingerprints directly to the ip elements is a right thing to do. Even if we ignore the "strange" syntax, imagine you have one server that is accessible over several ipv4 and several ipv6 addresses, plus maybe over tor or by other means. It would be conceptually wrong, not to say wasteful, to duplicate the same fingerprint in multiple elements of the domain object.

Better to stay closer to DANE, in my opinion.

Normally you would use a different certificate, there is no benefit to reusing the certificate across servers. At the minimum, if means if one of your servers is compromised, only some of the traffic could be intercepted (specifically data going to the server that was compromised and not the other servers!). Although generally the attacker will compromise all the servers, or a user will eventually cycle onto the compromised server, it is still better to use different certificates.

It also means you don't have to worry so much after you decommission a server, if the certificate is compromised somehow (perhaps disk forensics on a VPS etc).

[biolizard89]

Assuming that we allow different certs on a per-IP basis, we should consider that users will be using the "import" field to get the IP addresses, and we don't want fingerprints to be accidentally imported in the process. So it's probably not workable to have the fingerprints inside the "ip" field.

How about this:

Code: Select all

{
   "ip":["192.168.1.1", "192.168.2.2"],
   "tls":
   {
      "ip": 
      [ 
         {
            "tcp":
            {
               "443":[ [ 1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1 ] ]
            }
         },
         {
            "tcp":
            {
               "443":[ [ 1, "C9EAE0F912B8B54744CB7643D7621B787660008F91C07DCF9058CDD5AD2BAF6C", 1 ] ]
            } 
         }
      ]
   }
}

Each set of certs corresponds to an IP. This leaves interesting issues of what to do if there are more IP's listed than certs... should that be interpreted as no cert for those IP's? An advantage of this method is that it's backward compatible with IP addresses.

[ryanc]

Normally you would use a different certificate, there is no benefit to reusing the certificate across servers. At the minimum, if means if one of your servers is compromised, only some of the traffic could be intercepted (specifically data going to the server that was compromised and not the other servers!)..

Normally, one is using certs signed by a CA identified by name, so stealing any of them allows you to MitM all of the others. Not quite true for cert fingerprints, but I can't beat your own argument against the idea:

generally the attacker will compromise all the servers, or a user will eventually cycle onto the compromised serve

Our default position, unless there is a very compelling reason not to, should be to maintain compatibility with whatever DNS is doing so that when .bit domain data is mapped to DNS data there should be no surprises. Your proposal to specify cert fingerprints per IP results in surprises and is incompatible with DANE.

Your argument seems to be "maybe for some reason the attacker will only steal one private key" - why do you think that's likely enough to warrant specific defenses that only help in that case and otherwise complicate things?

I think allowing multiple certificates is fine, it's just that pinning them to IPs is silly.