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

Post Reply
biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

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

Post by 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?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: "tls"/"fingerprint" and "alias" fields

Post by virtual_master »

I am not sure if I understood correctly what do you mean.
biolizard89 wrote: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.
biolizard89 wrote: 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 ?
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: "tls"/"fingerprint" and "alias" fields

Post by 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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

pmc
Posts: 73
Joined: Thu Oct 03, 2013 8:50 pm
Location: Germany
Contact:

Re: "tls"/"fingerprint" and "alias" fields

Post by 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
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: "tls"/"fingerprint" and "alias" fields

Post by biolizard89 »

pmc wrote: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).
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: "tls"/"fingerprint" and "alias" fields

Post by 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.
DNS is much more than a key->value datastore.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: "tls"/"fingerprint" and "alias" fields

Post by biolizard89 »

indolering wrote: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.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

indolering
Posts: 800
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: "tls"/"fingerprint" and "alias" fields

Post by indolering »

biolizard89 wrote: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.
DNS is much more than a key->value datastore.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: "tls"/"fingerprint" and "alias" fields

Post by biolizard89 »

indolering wrote:
biolizard89 wrote: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."
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply