Pagel1928 wrote:biolizard89 wrote: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.
I guess what you are referring to is if someone uses the import field, and wants to use SNI on the server they are using (different certificate per name on the same server)?
I actually think you want to minimize the likelihood of the location being separated from the fingerprint. In your example you would have to use import twice to add the IP and the fingerprint, which would be the much more common use case.
And if you decided to "fail open" (aka not enforce secure communication for all .bit), you are increasing the likelihood that a user would import just the location and not the fingerprint, introducing a vulnerability.
That's actually not what I'm talking about. It's considered a good practice to store IP addresses in separate names from the security information (such as TLS), so that if the IP address name's keys are compromised (e.g. if a hotwallet used for dynamic DNS is stolen), the TLS as well as name ownership won't be compromised. For example, you have d/example, which imports dd/example-ip. We don't want TLS data to be imported into d/example when we import dd/example-ip. For that reason, TLS data shouldn't be part of the "ip" field.
I haven't carefully thought about this, but I *think* this could be dealt with like this:
Code: Select all
{"ip":[{"addr":"1.2.3.4", "tls":{ FINGERPRINTS GO HERE } } ] }
So we would import the "addr" field from a hot wallet, which wouldn't risk affecting the "tls" field.
I would like to enforce TLS by default, which would reduce the risk of a misconfiguration causing security issues. How about a "notls" field in the root of the name, which takes an array of services? If a service is not specified in the notls array, then TLS would be enforced. This would have to be implemented gradually so that legacy websites have time to upgrade, and for some intermediate period the TLS enforcement should be overridable by the end user. It's also worth noting that all of this breaks backward compatibility with DNS-based .bit resolvers to some extent, since they can't entorce TLS at all. I'm totally fine with this, but I suspect some people won't be.
Actually, maybe one possible way to fake compatibility with DANE here is to have the DNS server randomly pick a single IP address and its associated DANE fingerprint, and return those to the end user. I guess this might work for most cases. @Ryan, what problems would that introduce (if any)?
Pagel1928 wrote:biolizard89 wrote: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.
If there were less certificates than IP addresses, I would flag the entire thing as invalid and refuse to resolve anything.
ryanc wrote:
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.
I think having a strong relationship between a service and how to authenticate it, is not silly at all, and actually is far more straightforward than when the relationship between authentication is weak or varies.
You can use the same fingerprint for different IP addresses if you want, you just have to do it explicitly.
You seem to agree that in a few cases it actually is advantageous security wise, so I'm unsure why you are arguing so hard for a weaker system.
In the worst case scenario for converting from regular DNS, is the developers of tools to convert a zone to a namecoin zone, has to add one or two extra lines of code. ^_^
I think Ryan's objection relates to the inverse: converting from Namecoin to DNS. See my suggestion above.
According to a quick search through StackExchange (I don't have the link handy), lots of large websites use different certs for different datacenters. If we assume that the datacenters are geographically optimized, then it's quite plausible that a user wouldn't cycle onto a compromised server if the server isn't physically near him. (I guess if he's using Tor he's still screwed though, since the exit node will eventually be near the compromised datacenter.)
EDIT: Given that there is not yet consensus on the spec, I won't be implementing it in FreeSpeechMe yet. The absolute worst possible course of action would be to implement something, and then realize that it needs to be changed after deployment.