Ignore all TLSA fields from untrusted sources

As a follow-up to https://github.com/hlandau/ncdocs/issues/11 , I propose the following:

All security-critical DNS records (e.g. TLSA and SSHFP) MUST be ignored if any of the following is true:

The record is retrieved from a nameserver (delegated via NS) that does not have a corresponding DS record.
The record is retrieved via a CNAME.
The record is retrieved via a DNAME.

The following workarounds are RECOMMENDED:

Have example.bit CNAME to ip.example.bit, have ip.example.bit NS to the untrusted nameserver, and have a TLSA record in the blockchain for _port._protocol.example.bit.
Only CNAME example.bit, but do not CNAME _port._protocol.example.bit.
Use multiple CNAMEs instead of DNAME, since DNAME is inherently insecure.

The wallet GUI's SHOULD automatically warn the user when an insecure configuration exists, and SHOULD offer to apply one of these workarounds.

Non-security-critical DNS records (e.g. A and AAAA) MUST be unaffected by these rules, since the worst that can happen as a result of a successful attack is a DoS rather than a MITM.

Open questions:

A trusted nameserver has its own untrusted delegation. How easy is it to detect this case reliably?
How does untrusted delegation via SRV or similar things get handled? I assume we have to ignore all the TLSA records associated with those delegations? How easy is it to detect this case reliably?

AFAIK CNAME can't work as a naked domain and CNAME flattening requires a special server to handle. We need translate/DNAME to work as expected since it's a MAJOR use case.

@indolering Specifically what use case requires DNAME? A DNAME is just an automatic generator of CNAME behavior for all subdomains; as far as I can tell that is not required for any major use cases.

Also, what is "work as expected"? Some people (including me) would argue that "work as expected" in the context of Namecoin (which advertises that names cannot easily be hijacked) means that TLSA lookups are secure.

This is out of scope for Namecoin. Obviously, a validating DNSSEC stub resolver can only set AD=1 if all replies incorporated in the response it delivers are authenticated.

Refusing to trust .bit domains which are partially delivered by DNSSEC-secured ICANN DNS is a policy decision which can be made by the domain operator.

@hlandau That is a good point. Can we at least specify that for the purpose of setting AD=1, the ICANN root is not considered a trust anchor when it shows up in the process of resolving .bit (even if .bit delegates to an ICANN domain)? (I'm not sure how technically workable that is.)

I would strongly support the above specified behavior as a default for NMControl (and other software that we endorse).

As I said, whether to trust ICANN DNS is a policy decision to be made by the domain operator. If they're happy to endorse ICANN DNS as representing the contents of a .bit domain, so be it. The site is only as trustworthy as the operator anyway, and not every operator needs the same things from Namecoin.

Moreover, setting AD=0 because ICANN DNS is involved is completely inconsistent with DNSSEC as it stands. Obviously DNSSEC as intended sets AD=1 if the response is DNSSEC-secured. So this is a deviation from the standard, which I don't think is adequately justified.

I don't think that's entirely fair. It is relatively common for client software to refuse to access, or warn the user, when a website has made an insecure design decision. For example, using weak keys, weak signatures, weak ciphersuites, weak SSL/TLS versions, or mixed HTTPS/HTTP content. These decisions are typically not left entirely to the domain owner, even though if they're malicious they can cause harm anyway.

I also don't think your characterization of the AD bit is accurate. AD=1 does mean that the DNSSEC signatures validate, but it doesn't inherently mean that the root key must be the ICANN-owned root key. As far as I know, it's perfectly valid for a DNSSEC resolver to not trust the ICANN root, and instead trust some other root. That resolver won't interoperate with the rest of the ecosystem in practice, but that doesn't mean it's unacceptable by the DNSSEC standard. I'm suggesting that we should not trust the ICANN root when deciding whether the DNSSEC signatures validate -- that doesn't mean that we're violating the spec as far as I know. An end user who resolves a .bit domain has an expectation (quite reasonably) that it's backed by the blockchain, not by ICANN. While it's perfectly okay for a website to not honor that expectation, the user should be informed by setting AD=0, indicating that the user's security expectations were not met, so that the end user can make an informed decision about whether to proceed.

@indolering Specifically what use case requires DNAME? A DNAME is just an automatic generator of CNAME behavior for all subdomains; as far as I can tell that is not required for any major use cases.

indolering reads the DNAME spec Well argle-fucking-bargle.

I largely agree with hl: if someone wants the full security offered by a .bit site, then they shouldn't be using another TLD. I see this primarily being used by small blogs and other sites that don't need the full protections offered by .bit and I think a warning is good enough. It's similar to a site operator deciding to use JS or other assets hosted on a regular domain. Ultimately, the security for the site comes down to the site operator, not the user.

I would support a non-standard record that enables an operator to specify a valid TLSA record but (if I understand this AD setting correctly) any option to not trust the TLD root should be turned off by default and hidden away behind something akin to about:config.

I'm also worried that simply refusing to support DNAME will cause us trouble down the road if we try to get this adopted by a bigger standards body.

Comment added after chatting with Jeremy on IRC.

If you are using another TLD, then you are buying into their security model and site operators should be allowed to do so. There is an element of user expectations, but this logic would lead us to blocking all scripts loaded from CDNs that use a traditional TLD.

Warnings in the DNS config screen and proper documentation will be good enough because very few sites need to fear an attacker capable of obtaining the signing keys for a TLD or a DNS service provider. I can see admins for Clipperz wanting to offer a .bit site for safer access, but I think that a warning in the documentation and in the config screen will be sufficient to alert them to these other options.

For small sites that don't have major security concerns, being able to just add an apex record and a DNAME is a quick and dirty way of mirroring their primary website on a .bit domain. If you are using IP's for your subdomains (instead of virtual hosts), then the default config will automatically support the .bit site without having to add support directly (as I'm doing with my Dreamhost shared hosting).

Even if we assume that all hosting providers will eventually adopt DANE and that we can query for their records during the configuration process, everything will break if the service provider alters their keys. Monitoring this and working with a DNS service provider to figure out their management system is something that can be reasonably expected of an experience system admin, but not for someone maintaining a personal blog.

Okay, first off -- I will allow the authors of DNSSEC (RFC 4033) to speak here.

A security-aware resolver normally constructs this authentication chain from the root of the DNS hierarchy down to the leaf zones based on configured knowledge of the public key for the root. Local policy, however, may also allow a security-aware resolver to use one or more configured public keys (or hashes of public keys) other than the root public key, may not provide configured knowledge of the root public key, or may prevent the resolver from using particular public keys for arbitrary reasons, even if those public keys are properly signed with verifiable signatures. DNSSEC provides mechanisms by which a security-aware resolver can determine whether an RRset's signature is "valid" within the meaning of DNSSEC. In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set. See Section 5 for further discussion.

In other words, we would be completely consistent with the standard to RECOMMEND that the ICANN root key is not a trust anchor for .bit. (I would lean toward REQUIRED, but I can live with RECOMMENDED.) There is no REQUIREMENT or RECOMMENDATION that the ICANN root key be a trust anchor for DNSSEC-compliant implementations.

Also relevant, from the same RFC:

A validating resolver may have a local policy to mark parts of the domain space as insecure.

Again, totally consistent with what I've been saying. The DNSSEC spec explicitly allows resolvers to not consider the ICANN root, and to mark parts of the domain space as insecure, based on local policy.

This directly contradicts what @indolering is claiming. According to the DNSSEC RFC itself, local policy determines these decisions, not what the domain owner decides is safe.

I note that @indolering did not ever address my point about how client software makes decisions like this all the time; see quote from me:

It is relatively common for client software to refuse to access, or warn the user, when a website has made an insecure design decision. For example, using weak keys, weak signatures, weak ciphersuites, weak SSL/TLS versions, or mixed HTTPS/HTTP content. These decisions are typically not left entirely to the domain owner, even though if they're malicious they can cause harm anyway.

Instead @indolering made a point about cross-domain script requests. Unfortunately this actually proves my point, because some web browsers actually do block cross-domain scripts (TorBrowser has this capability). This is not something that domain owners have any say in; this is something decided by the client.

@indolering also said:

if someone wants the full security offered by a .bit site, then they shouldn't be using another TLD.

This is a completely unnecessary and false recommendation. You can get the full security offered by .bit while storing some of your records in an ICANN TLD, as long as you keep .bit as the trust root. You won't have quite as much censorship resistance by doing this, but using things like SRV records would substantially (though not entirely) mitigate the censorship issue too. This is kind of funny, because @indolering claimed on IRC that censorship resistance was more important than security for his argument, which actually would be an argument against delegating to ICANN under any circumstances.

@indolering also claimed:

I see this primarily being used by small blogs and other sites that don't need the full protections offered by .bit and I think a warning is good enough.

I look forward to @indolering 's spec for using 100% accurate detection algorithms for the client to figure out whether it is accessing a small blog or a bank. (And before you ask, many many banks have broken security configurations; don't try to argue that clients shouldn't notice this.)

@indolering also suggested:

I would support a non-standard record that enables an operator to specify a valid TLSA record

There's the minor problem that this wouldn't be nonstandard, and I actually proposed this exact solution (using CNAME to delegate an IP address while not delegating the TLSA record). I'm not sure why @indolering is then arguing against the exact solution that he suggested.

@indolering also claimed:

I'm also worried that simply refusing to support DNAME will cause us trouble down the road if we try to get this adopted by a bigger standards body.

I never said we should refuse to support DNAME. I do not appreciate the straw man. I said that records delegated from .bit to ICANN domains by DNAME should not be considered "secure" under the DNSSEC definition of that term. I have explained above how this is completely consistent with existing standards.

@indolering also argued:

Even if we assume that all hosting providers will eventually adopt DANE and that we can query for their records during the configuration process

I don't know what you mean by "even if we assume", because if we assume that the hosting provider didn't adopt DNSSEC, then the response wouldn't be secure (under the DNSSEC spec) anyway, regardless of what trust root is applied.

@indolering appears to be basing his argument on this:

everything will break if the service provider alters their keys. Monitoring this and working with a DNS service provider to figure out their management system is something that can be reasonably expected of an experience system admin, but not for someone maintaining a personal blog.

Except that a quick Startpage would have revealed this to be completely unfounded in fact. See https://serverfault.com/questions/385478/do-i-need-to-renew-the-keys-which-i-deposited-at-my-domain-provider (read the full answer, not just my quotes; emphasis in original):

You are not required to renew the keys. Unlike RRSIG records, DNSSEC keys and corresponding DS signatures have no expiration date.

And:

a reasonable effectivity period for KSKs that have corresponding DS records in the parent zone is of the order of 2 decades or longer.

Jeez, that took me roughly half an hour to write... please read the whole thing before replying.

@JeremyRand

In other words, we would be completely consistent with the standard to RECOMMEND that the ICANN root key is not a trust anchor for .bit. (I would lean toward REQUIRED, but I can live with RECOMMENDED.) There is no REQUIREMENT or RECOMMENDATION that the ICANN root key be a trust anchor for DNSSEC-compliant implementations.

You're confusing the term "trust anchor" here. The ability to delegate from .abc via CNAME or DNAME to .xyz does not mean that .xyz (or its ancestor) needs to be a trust anchor for .bit. The ICANN trust anchor can apply to everything but .bit. But a .bit domain can certainly delegate to a domain under ICANN. Moreover, just because a standard says something can be done, doesn't mean it's sane to do so. In that regard, standards are almost irrelevant, as 'MUST' has no actual force anyway.

Again, totally consistent with what I've been saying. The DNSSEC spec explicitly allows resolvers to not consider the ICANN root, and to mark parts of the domain space as insecure, based on local policy.

So? Everyone can have their own local policy for all sorts of things. This does not make that policy sane, or more importantly, something you can expect domain operators to accommodate. I can break my configuration in all sorts of ways. Moreover, your proposed change is essentially a question of deliberately giving .bit domain operators a hard time because you don't like their security and trust decisions.

Besides, we're not talking about local policy here - we're talking about recommending or requiring certain behaviour as per the standard. So you're essentially arguing that the fact that the DNSSEC standard says you can do what you want lets you do what you want, namely telling other people they can't do what they want. (Saying that AD=0 for domains DNAME'd to ICANN is in reality means that you aren't allowed to use DANE in those circumstances.)

Instead @indolering made a point about cross-domain script requests. Unfortunately this actually proves my point, because some web browsers actually do block cross-domain scripts (TorBrowser has this capability). This is not something that domain owners have any say in; this is something decided by the client.

And if you disable cross-domain scripts on the web, tons of sites will break. Once again, I can impose whatever local policy I want, it doesn't mean the world is going to change to accomodate it.

This is a completely unnecessary and false recommendation. You can get the full security offered by .bit while storing some of your records in an ICANN TLD, as long as you keep .bit as the trust root. You won't have quite as much censorship resistance by doing this, but using things like SRV records would substantially (though not entirely) mitigate the censorship issue too. This is kind of funny, because @indolering claimed on IRC that censorship resistance was more important than security for his argument, which actually would be an argument against delegating to ICANN under any circumstances.

I have no idea how this is supposed to work. If you CNAME to an ICANN domain, you get the ICANN TLD RRSIGs for that domain. Domain owners don't publish their own RRSIGs for a domain. There's nothing in the Domain Names specification that would enable this. And even if it were to be proposed (I suppose by somehow allowing DS records to be attached to a CNAME/DNAME record), it would almost certainly require invasive modifications to Unbound, since you're changing its internal trust computation algorithms.

The Domain Names specification has been sitting around for too long to introduce this radical change at this late stage, and I'd argue that it shouldn't be considered for inclusion until an actual implementation is available.

I look forward to @indolering 's spec for using 100% accurate detection algorithms for the client to figure out whether it is accessing a small blog or a bank. (And before you ask, many many banks have broken security configurations; don't try to argue that clients shouldn't notice this.)

Precisely - which is why the decision needs to be left to the site operator, and not enforced by a misguidedly dogmatic client machine.

I never said we should refuse to support DNAME. I do not appreciate the straw man. I said that records delegated from .bit to ICANN domains by DNAME should not be considered "secure" under the DNSSEC definition of that term. I have explained above how this is completely consistent with existing standards.

It's certainly not consistent with the existing practice. The reality of the matter is, for even the most rigorously specified standards, there are going to be ways you can implement it complying with every requirement of the standard and yielding an utterly useless or non-interoperable implementation, if you are sufficiently obtuse about it. So I don't think "the standard says you can do this" is a good or compelling argument. What you are proposing will surprise, and indeed annoy, a substantial section of domain operators, essentially out of a paternalistic presumption that you know better. It's not something that domain operators are going to appreciate, and I don't see how it is going to win the Namecoin project any sites.

In other words, we would be completely consistent with the standard to RECOMMEND that the ICANN root key is not a trust anchor for .bit. (I would lean toward REQUIRED, but I can live with RECOMMENDED.) There is no REQUIREMENT or RECOMMENDATION that the ICANN root key be a trust anchor for DNSSEC-compliant implementations.

So are you saying that implementations would be free to choose whether they ignore these TLSA records?

I'm against anything that would prevent users from adopting the security of the TLD which hosts the site they are trying to mirror. I'm not sure about how this should be handled in the configuration interface.

This is kind of funny, because @indolering claimed on IRC that censorship resistance was more important than security for his argument, which actually would be an argument against delegating to ICANN under any circumstances.

You're twisting my words and migrating into asshole territory. I see my role as trying to figure out how low-level decisions like the one under discussion here impacts users. Unfortunately, that means I have to bring myself up to speed on a large number of areas to which I am unfamiliar. This limits me to a fairly high-level understanding and it often takes a while before I can for a cogent argument.

I try to make the more general argument in my next response.

@indolering also claimed: I see this primarily being used by small blogs and other sites that don't need the full protections offered by .bit and I think a warning is good enough.

I look forward to @indolering 's spec for using 100% accurate detection algorithms for the client to figure out whether it is accessing a small blog or a bank. (And before you ask, many many banks have broken security configurations; don't try to argue that clients shouldn't notice this.)

The VAST majority of people using this functionality will be mirroring a fully functioning website operating on a traditional TLD. And, until .bit achieves universal resolution, the vast majority of .bit sites will simply mirror a site on a traditional TLD. If their threat models allows them to run a site on a traditional TLD, then I don't see why we shouldn't allow their .bit sites to adopt that model as well.

I would like to reiterate that we are talking about an attacker which is capable of compromising a TLD or your DNS provider (which is also often the hosting provider). There are VERY few sites for which it is easier for an attacker to compromise a TLD or a DNS service provider. I believe that warnings in the client configuration screen and in the documentation will be sufficient to notify sys-admins of such caliber.

@indolering also said: if someone wants the full security offered by a .bit site, then they shouldn't be using another TLD.

This is a completely unnecessary and false recommendation.

I'm not saying that we shouldn't support this capability, I'm against disallowing sites to (implicitly) trust the default TLD root. It's a perfectly sane security model for most websites.

You can get the full security offered by .bit while storing some of your records in an ICANN TLD, as long as you keep .bit as the trust root.

Given the threat model that your proposal addresses I would assume that sites fearing an attacker capable of cracking a TLD or a DNS service provider would want to be as independent of the traditional domain name system as possible.

I'm not speaking for Ryan, but he was generally supportive of this logic when I ran it past him on IRC.

@indolering also suggested: I would support a non-standard record that enables an operator to specify a valid TLSA record

There's the minor problem that this wouldn't be nonstandard, and I actually proposed this exact solution (using CNAME to delegate an IP address while not delegating the TLSA record). I'm not sure why @indolering is then arguing against the exact solution that he suggested.

I'm arguing against preventing others to simply adopt the security model of the site they are mirroring.

a reasonable effectivity period for KSKs that have corresponding DS records in the parent zone is of the order of 2 decades or longer.

Until .bit achieves ubiquitous resolution, the vast majority of .bit sites will simply be mirroring sites on a traditional TLD. We should make it as easy as possible for operators to mirror an external .bit site: they should be able to "set-and-forget". Your proposal would result in sites breaking when the DNS or hosting provider changed their keys or if the site switched service providers. Since the site on the traditional TLD would continue operating as normal, many (most?) wouldn't even know that their .bit site had broken. Try to remember that the average website owner doesn't understand the finer points of DNS configuration and wouldn't even know how to debug the problem.

Outside of certificate authorities, cold storage key management is fairly novel for most organizations (which is part of the reason CA's are capable of selling other types of certificates). Management solutions for cold storage are still in their infancy (see Armory's business) and sites using HTTPS key-pinning have run into this issue. This is a real problem – one that has happened to me! I think the next 5-10 years will be especially problematic as DNS service providers and web hosts begin rolling out DNSSEC.

Long lasting signing keys are not a cure-all as the cold storage system can fail. Indeed, one of the reasons organizations rotate keys regularly is to ensure that the system is functioning properly.

Furthermore, many provers are using 1Kb keys and there is going to be a transition to ECC crypto. After that, I expect we'll see a migration to curve25519. A fews years later, we'll see a migration to post-quantum crypto signature schemes.

I never said we should refuse to support DNAME. I do not appreciate the straw man. I said that records delegated from .bit to ICANN domains by DNAME should not be considered "secure" under the DNSSEC definition of that term. I have explained above how this is completely consistent with existing standards.

But if you can't declare your cert using a DNAME, wouldn't the browser show a "this shit is unsafe" warning? See the above for why I don't think declaring TLSA within the .bit record or pinning is a viable alternative.

Instead @indolering made a point about cross-domain script requests. Unfortunately this actually proves my point, because some web browsers actually do block cross-domain scripts (TorBrowser has this capability). This is not something that domain owners have any say in; this is something decided by the client.

I specifically brought this argument up because of a previous discussion I had with you about certificate management in which you were fine with sites linking to external scripts. Again, I don't want to speak for Ryan but when I ran this past him he thought that this was a valid point.

Even if we assume that all hosting providers will eventually adopt DANE and that we can query for their records during the configuration process

I don't know what you mean by "even if we assume", because if we assume that the hosting provider didn't adopt DNSSEC, then the response wouldn't be secure (under the DNSSEC spec) anyway, regardless of what trust root is applied.

That's from a conversation I had with you on IRC about allowing the client software to retrieve the DNSSEC keys for the domain during configuration.

Jeez, that took me roughly half an hour to write... please read the whole thing before replying.

2 people appear to be opposed to this resolution and I my basic position remains the same: the threat model doesn't justify introducing non-standard behavior.

Jeremy has agreed to drop this issue as it has come to our attention that implementing this would require invasive changes to any software which serves Namecoin domains (e.g. Unbound, PowerDNS), making its imposition impractical.

hlandau / ncdocs

Ignore all TLSA fields from untrusted sources #12