"tls"/"fingerprint" and "alias" fields

[biolizard89]

The .bit spec doesn't specify what behavior the "tls" field has when a domain has an "alias" field -- does the TLS fingerprint/enforcement setting from the Namecoin name have priority, or does the linked domain get to specify that (e.g. through DNSSEC if it's not a .bit domain)?

I think the spec should explicitly state that the "tls" field takes priority over whatever the linked "alias" domain specifies, so that domains using "alias" get the same security guarantees for TLS as other .bit domains.

Is there any objection to this?

[virtual_master]

I am not sure if I understood correctly what do you mean.

The .bit spec doesn't specify what behavior the "tls" field has when a domain has an "alias" field -- does the TLS fingerprint/enforcement setting from the Namecoin name have priority, or does the linked domain get to specify that (e.g. through DNSSEC if it's not a .bit domain)?

An alias is a redirection to another domain and has some analogy with a page redirection.
Where I am redirected the rules of the pointed domain should be valid. At least that suggests the logic. But I am not sure how is this implemented when different protocols appear.
plain http, ssl , tls
But i don't see why would be different in this case and why would be different by .bit domains.
So if I am redirected to a plain connection than so should be whatever it was by the alias and if I am redirected to a TLS connection then should be TLS.

They are a lot of possible variations depending on the
protocol - http, ssl, tls
registrar - ICAN, .bit
alias - 3 protocol x 2 registrars = 6 variations
target domain also 6 variations
alias -> domain 36 variations considering only this 2 factors, but some of them could be not interesting for us
24 variations when at least the alias or the domain is .bit
When both have the same protocol then is clear -3 and doesnt need anything to be changed.
So they are 18 cases which could be interesting to be analyzed.

I think the spec should explicitly state that the "tls" field takes priority over whatever the linked "alias" domain specifies, so that domains using "alias" get the same security guarantees for TLS as other .bit domains.

So what exactly do you mean ?
tls .bit alias -> http ICANN domain ?
or
tls .bit alias -> http .bit domain ?
or
http .bit alias -> tls .bit domain ?
....
Which one should be forced for TLS ?

[biolizard89]

The "alias" field is equivalent to a DNS CNAME record, not a redirect. See: https://en.wikipedia.org/wiki/Cname

A CNAME record only says that the IP address from another record is used; it does not indicate a protocol redirect of any kind. Protocols never even see the CNAME; they simply see the IP address that was loaded.

Let's say I own google.com, and that it resolves to 1.2.3.4.

Now let's say I own the Namecoin name d/google, and I set its value to:

{"alias":"google.com."}

This is equivalent to the name having this value:

{"ip":"1.2.3.4"}

With the extra feature that when I update google.com, the google.bit domain also automatically updates without any blockchain operations being necessary. This is a useful feature if you own a non-.bit domain and you want to have a .bit domain point to the same IP without handling any DNS-related operations yourself. People in such situations might also wish to leverage the TLS feature of Namecoin (which is more secure than CA-based TLS) while not setting up any DNS operation.

Which is the point of my post -- the .bit spec is unclear on whether the "tls" field has any effect when the "alias" field is in use. I think the "tls" field should still have its usual effect when "alias" is used, since doing so is the only way to allow strong TLS security when "alias" is in use.

[pmc]

An important detail of CNAME RRs is that when a CNAME is present for a domain then no other RRs can exist for that domain.

So if an alias is equivalent to a CNAME, then the tls must be ignored.

[biolizard89]

An important detail of CNAME RRs is that when a CNAME is present for a domain then no other RRs can exist for that domain.

So if an alias is equivalent to a CNAME, then the tls must be ignored.

This is not correct as far as I can tell, according to https://tools.ietf.org/html/rfc6698 , TLSA records can coexist with CNAME records. In any event, we already deviate from the DNS spec in some ways (e.g. Tor/I2P/Freenet resolution and the proposed static and http fields).

[indolering]

Aliases are CNAMES so you are basically asking if TLS should be wildcard by default? Wildcard domains were created to bilk money from the consumer, let's go with wildcard by default.

I think everyone is confusing aliases for the translate field (which I did at first) and that's basically ICANN domains. I think we should massage the requirement here to accept any TLS that is valid for the endpoint URL in addition to any TLS with a public/private of the original URL. However, I do think we should include a way to signal whether it's okay to drop encryption for the translated URL.

[biolizard89]

Aliases are CNAMES so you are basically asking if TLS should be wildcard by default? Wildcard domains were created to bilk money from the consumer, let's go with wildcard by default.

I think everyone is confusing aliases for the translate field (which I did at first) and that's basically ICANN domains. I think we should massage the requirement here to accept any TLS that is valid for the endpoint URL in addition to any TLS with a public/private of the original URL. However, I do think we should include a way to signal whether it's okay to drop encryption for the translated URL.

As far as I know, both alias/CNAME and translate/DNAME can be targeted at both ICANN and .bit domains. For targeting a .bit domain, there is no real reason to use a different TLS fingerprint, so I don't see any reason to worry about that case. For targeting an ICANN domain, the behavior (IMO) should be that the Namecoin fingerprint should take precedence if there is one (since presumably Namecoin has better security than ICANN TLS). I can't think of any use cases where this is a problem -- if you're worried that the TLS cert will be switched out without your knowledge, then you clearly have no control of your own site and all bets are off regarding TLS's security. As a side note -- you can't do standard CA verification on a .bit alias, since a CA won't issue a cert for a non-ICANN domain such as .bit. Maybe you could hack something together that uses the CNAME-pointed domain as the standard for CA verification... but I don't really see any use case where this is preferable. If you own a .bit domain, why not place the fingerprint in its record and get the security benefits for free? You're welcome to use a CA cert that is also valid for the CNAME-pointed domain... Convergence is fine with such things.

[indolering]

As a side note -- you can't do standard CA verification on a .bit alias, since a CA won't issue a cert for a non-ICANN domain such as .bit.

No, I meant TLS for whatever domain it is pointing to, such that using a CA certified https://www.indolering.com would not bring up a warning if the TLS for https://www.indolering.bit was different, just as long as indolering.com is listed in the .bit alias field.

[biolizard89]

As a side note -- you can't do standard CA verification on a .bit alias, since a CA won't issue a cert for a non-ICANN domain such as .bit.

No, I meant TLS for whatever domain it is pointing to, such that using a CA certified https://www.indolering.com would not bring up a warning if the TLS for https://www.indolering.bit was different, just as long as indolering.com is listed in the .bit alias field.

As I said above:

"Maybe you could hack something together that uses the CNAME-pointed domain as the standard for CA verification... but I don't really see any use case where this is preferable. If you own a .bit domain, why not place the fingerprint in its record and get the security benefits for free? You're welcome to use a CA cert that is also valid for the CNAME-pointed domain... Convergence is fine with such things."