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

[Pagel1928]

I think we should follow the DANE spec a little more closely when it comes to TLS support for namecoin. The DANE RFC can be found here: http://tools.ietf.org/html/rfc6698

Currently the namecoin TLS spec is as follows:

Code: Select all

tls (http://dot-bit.org/Namespace:Domain_names_v2.0#TLS_support)
Specifies one or more certificate fingerprints and allow to enforce secured connections (see HSTS)
Allowed values :
- sha1 : upper or lower case, with or without ':'
- enforce : "self" (current FQDN) or "*" (all subdomains)

"tls": {
"sha1": ["15:91:52:97:10:88:CD:44:9C:F7:23:81:78:C3:50:3B:09:20:56:2A", "630884E279CB1107F1FB8A6B11A64D1B14763F8E"],
"enforce": "*"
}

The main differences are:

* We are supporting the use of sha1, DANE rfc supports (entire certificate, sha256 and sha512)
* We do not specify the port of the connection, so we are unable to specify the hash/certificate for difference services
* We do not distinguish between protocol
* We are allowing the hash format to contain the ":" character

The two main things in the DANE spec that we probably shouldn't include/or do not need to are the usage and selector options.

We always do end entity certificate only matching, and we only check/hash the full certificate. I think this is the right way to do it.

So this is my proposal for changing the TLS spec:

Format:

Code: Select all

"tls": {
    "protocol": {
        port: [[matchtype, "matchvalue", includeSubdomains],[matchtype, "matchvalue", includeSubdomains]]
    } {
        port: [[matchtype, "matchvalue", includeSubdomains]]
    }
}

Value Definitions:

Port:

Code: Select all

Decimal representation of the port number on which a TLS-based service is assumed to exist. The number has no leading zeros.

Protocol:

Code: Select all

Lower or uppercase string: tcp, udp, sctp

matchtype:

Code: Select all

0: Exact match (the entire certificate)
1: SHA-256
2: SHA-512

matchvalue:

Code: Select all

The hash or certificate in hex without any delimiters, as a string in hex digits.

includeSubdomains:

Code: Select all

0: do not enforce this rule for subdomains
1: enforce this rule for subdomains
The includeSubdomains rule cannot be revoked by a subdomains that turn it off.

Example:

Code: Select all

"tls": {
    "tcp": {
        443: [[1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1]]
    } {
        25: [[1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1]]
    }
}

Using this it also makes it easy to implement TLSA/DANE lookups for _443._tcp.whatever.bit , pulling this data out of namecoin and returning it as a TLSA record.

Additionally we should make it implied that http traffic is encrypted. Tools such as the namecoin convergence plugin will assume that https traffic to .bit domains has a tls fingerprint, and if it does not, serves a error message to the user about the problem with the connection, with the possibility to bypass it.

[moa]

Excellent idea. Following the DANE spec will also allow easy comparison between DNSSEC and NMCSEC wherever it gets implemented in other external applications (e.g. gnutls, etc)
... and obviously no need to re-invent the wheel.

Good work.

[biolizard89]

I agree on most points.

Allowing multiple hashes for a service is useful for rotating certificates, as well as load-balanced services where different physical servers might have different certificates. So I think we should continue to allow multiple hashes for a service. This is not theoretical; Moxie's Convergence plugin fails on some websites because it doesn't support multiple hashes; Convergence for Namecoin doesn't have that issue. Changing this behavior would be a regression.

I also think it is useful to continue to allow the "enforce TLS" field to be set. Allowing a service provider to explicitly declare that they exclusively want HTTPS (or FTPS etc.) connections is useful, even if we go forward with the plan to show a security warning prior to loading non-TLS .bit websites. I think the behavior for a website with the Enforce TLS field enabled should be different than a website with it disabled. If Enforce TLS is enabled for an HTTP service, then the browser should automatically change the "http" to "https" in the URL prior to making a connection, without warning the user. If it is disabled, the browser should show a security warning, and allow the user to either proceed to the non-TLS site, or the user can change the URL to "https". The reason for this is that some servers serve different content over HTTP and HTTPS, and silently switching HTTP to HTTPS will break some sites which don't expect it. Obviously, sites should ideally expect it, but if they're expecting it, they should say so in their Namecoin blockchain data. Sites that don't expect it should generate a scary warning (so the user has a clue what's wrong) rather than silently do undefined weird crap (which will confuse the crap out of the user).

In the spirit of attaching the data to particular services, it would be useful to attach the Enforce TLS field to a particular service, so that e.g. HTTP has TLS enforced but FTP doesn't. Suggestions on exactly how this would be implemented are welcome.

All other changes you suggest, I think I approve of. Does anyone else have feedback here?

[Pagel1928]

I agree on most points.

Allowing multiple hashes for a service is useful for rotating certificates, as well as load-balanced services where different physical servers might have different certificates. So I think we should continue to allow multiple hashes for a service. This is not theoretical; Moxie's Convergence plugin fails on some websites because it doesn't support multiple hashes; Convergence for Namecoin doesn't have that issue. Changing this behavior would be a regression.

I also think it is useful to continue to allow the "enforce TLS" field to be set. Allowing a service provider to explicitly declare that they exclusively want HTTPS (or FTPS etc.) connections is useful, even if we go forward with the plan to show a security warning prior to loading non-TLS .bit websites. I think the behavior for a website with the Enforce TLS field enabled should be different than a website with it disabled. If Enforce TLS is enabled for an HTTP service, then the browser should automatically change the "http" to "https" in the URL prior to making a connection, without warning the user. If it is disabled, the browser should show a security warning, and allow the user to either proceed to the non-TLS site, or the user can change the URL to "https". The reason for this is that some servers serve different content over HTTP and HTTPS, and silently switching HTTP to HTTPS will break some sites which don't expect it. Obviously, sites should ideally expect it, but if they're expecting it, they should say so in their Namecoin blockchain data. Sites that don't expect it should generate a scary warning (so the user has a clue what's wrong) rather than silently do undefined weird crap (which will confuse the crap out of the user).

In the spirit of attaching the data to particular services, it would be useful to attach the Enforce TLS field to a particular service, so that e.g. HTTP has TLS enforced but FTP doesn't. Suggestions on exactly how this would be implemented are welcome.

All other changes you suggest, I think I approve of. Does anyone else have feedback here?

I agree with the fact we should add the ability to have multiple certificates, so this would look like this:

Code: Select all

"tls": {
    "tcp": {
        443: [[1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1],[1, "123123123123123123123112312312312312312312312312312312312312312317", 1]]
    } {
        25: [1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1]
    }
}

I had overlooked that the DANE spec actually says:

Code: Select all

A DNS query can return multiple certificate associations, such as in
   the case of a server that is changing from one certificate to another

I think if there is a TLS fingerprint record, it implied that it should be enforced for that particular service. You don't need an additional flag to say it is enforced. For example, what would you do if there was a TLS fingerprint but without the enforce flag? Disregard the fingerprint entirely?

If Enforce TLS is enabled for an HTTP service, then the browser should automatically change the "http" to "https" in the URL prior to making a connection, without warning the user. If it is disabled, the browser should show a security warning, and allow the user to either proceed to the non-TLS site, or the user can change the URL to "https". The reason for this is that some servers serve different content over HTTP and HTTPS, and silently switching HTTP to HTTPS will break some sites which don't expect it.

If we simply build into the plugins forcing all .bit to load straight away as https, then there is really no problem. Websites will never serve different content over http as there will be no users who browse http .bit websites.

We shouldn't concern ourselves with servers that are setup incorrectly. Anyone setting up a .bit domain would quickly notice what they need to fix, when they cant access their own site using the most popular configuration.

It might even be possible to convince some browser vendors to add a rule .bit -> https, so if you type example.bit, it will default to https because it is a .bit tld.

[biolizard89]

I agree with the fact we should add the ability to have multiple certificates, so this would look like this:

Code: Select all

"tls": {
    "tcp": {
        443: [[1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1],[1, "123123123123123123123112312312312312312312312312312312312312312317", 1]]
    } {
        25: [1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1]
    }
}

This looks mostly okay; I think it would make implementation easier for the certs to always be an array.

I.e.

Code: Select all

25: [[1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1]]

What do you think?

I think if there is a TLS fingerprint record, it implied that it should be enforced for that particular service. You don't need an additional flag to say it is enforced. For example, what would you do if there was a TLS fingerprint but without the enforce flag? Disregard the fingerprint entirely?

Maybe there's a misunderstanding of my terminology. The "enforce" flag I'm talking about serves the same role as HSTS (or whatever DNS extension exists to simulate it) rather than DANE. Specifying a fingerprint for TCP port 443 will enforce that TLS is used on TCP port 443, but it will not by itself specify that TCP port 80 clients who happen to be using the HTTP protocol will switch to TCP port 443 and switch protocols from HTTP to HTTPS. The "enforce" flag tells TCP port 80 clients who are using HTTP that they should instead switch to port 443 and switch the protocol to HTTPS. In practice the main goal of this is to prevent sslstrip attacks. I think this is sufficiently different a statement that it deserves its own flag. That said, you may be right that it doesn't need to be service-specific, since sslstrip only seems to be a serious issue for HTTP port 80/443. What do you think?

If Enforce TLS is enabled for an HTTP service, then the browser should automatically change the "http" to "https" in the URL prior to making a connection, without warning the user. If it is disabled, the browser should show a security warning, and allow the user to either proceed to the non-TLS site, or the user can change the URL to "https". The reason for this is that some servers serve different content over HTTP and HTTPS, and silently switching HTTP to HTTPS will break some sites which don't expect it.

If we simply build into the plugins forcing all .bit to load straight away as https, then there is really no problem. Websites will never serve different content over http as there will be no users who browse http .bit websites.

We shouldn't concern ourselves with servers that are setup incorrectly. Anyone setting up a .bit domain would quickly notice what they need to fix, when they cant access their own site using the most popular configuration.

It might even be possible to convince some browser vendors to add a rule .bit -> https, so if you type example.bit, it will default to https because it is a .bit tld.

There is some debate in the IRC about the implications of this, particularly for .bit implementations which can't handle self-signed certs. Unfortunately this debate got cut off when I had to suddenly leave (sorry indo, wasn't trying to disappear), so no conclusion was reached. I guess we need to figure this out?

[Pagel1928]

This looks mostly okay; I think it would make implementation easier for the certs to always be an array.

I.e.

Code: Select all

25: [[1, "660008F91C07DCF9058CDD5AD2BAF6CC9EAE0F912B8B54744CB7643D7621B787", 1]]

What do you think?

I agree, I just forgot to add it in my example!

I think if there is a TLS fingerprint record, it implied that it should be enforced for that particular service. You don't need an additional flag to say it is enforced. For example, what would you do if there was a TLS fingerprint but without the enforce flag? Disregard the fingerprint entirely?

Maybe there's a misunderstanding of my terminology. The "enforce" flag I'm talking about serves the same role as HSTS (or whatever DNS extension exists to simulate it) rather than DANE. Specifying a fingerprint for TCP port 443 will enforce that TLS is used on TCP port 443, but it will not by itself specify that TCP port 80 clients who happen to be using the HTTP protocol will switch to TCP port 443 and switch protocols from HTTP to HTTPS. The "enforce" flag tells TCP port 80 clients who are using HTTP that they should instead switch to port 443 and switch the protocol to HTTPS. In practice the main goal of this is to prevent sslstrip attacks. I think this is sufficiently different a statement that it deserves its own flag. That said, you may be right that it doesn't need to be service-specific, since sslstrip only seems to be a serious issue for HTTP port 80/443. What do you think?

Hmm, I was thinking, you would just check for the existence of a TLS record for port 443 and switch to it (if we were not enforcing HTTPS for all .bit).

Alternatively we can have a flag in the 443 record that says "doNotUpgrade". But I feel pretty strongly about enforcing TLS for all HTTP traffic on the .bit TLD.

If Enforce TLS is enabled for an HTTP service, then the browser should automatically change the "http" to "https" in the URL prior to making a connection, without warning the user. If it is disabled, the browser should show a security warning, and allow the user to either proceed to the non-TLS site, or the user can change the URL to "https". The reason for this is that some servers serve different content over HTTP and HTTPS, and silently switching HTTP to HTTPS will break some sites which don't expect it.

If we simply build into the plugins forcing all .bit to load straight away as https, then there is really no problem. Websites will never serve different content over http as there will be no users who browse http .bit websites.

We shouldn't concern ourselves with servers that are setup incorrectly. Anyone setting up a .bit domain would quickly notice what they need to fix, when they cant access their own site using the most popular configuration.

It might even be possible to convince some browser vendors to add a rule .bit -> https, so if you type example.bit, it will default to https because it is a .bit tld.

There is some debate in the IRC about the implications of this, particularly for .bit implementations which can't handle self-signed certs. Unfortunately this debate got cut off when I had to suddenly leave (sorry indo, wasn't trying to disappear), so no conclusion was reached. I guess we need to figure this out?

I think if an implementation can't handle the self-signed certs, than it is not validating the TLS fingerprint in the namecoin record? If security is one of the primary objectives of namecoin, we probably don't want to support such software.

[biolizard89]

I think if an implementation can't handle the self-signed certs, than it is not validating the TLS fingerprint in the namecoin record? If security is one of the primary objectives of namecoin, we probably don't want to support such software.

Well, I wrote a long reply, but it got wiped when the forum logged me out. Go me.

Anyways...

I think I agree with you. Indo's implementation is designed for censorship resistance exclusively, he's not including security as a design goal. I pointed out some security issues to him, and he didn't seem interested in addressing their merits. Instead he sarcastically compared my concerns to Linus inserting a backdoor in the kernel. I told him that his implementation allowed a malicious server to compromise everything and his audits wouldn't detect it; his reply was that the same thing happens to banks, so it's not worth fixing. On IRC he used an unspecified case of FBI harassment against him to conclude that the FBI is impossible to defeat anyway, so supposedly we shouldn't worry about security. After this I kind of gave up on debating the security of his project; he clearly has no interest in the subject.

(None of the above should be construed as a personal attack.)

Most users use default settings. PGP didn't fail because it didn't work at encrypting e-mail, it failed because it wasn't the default. If we make HTTPS the default for .bit, we will encourage its adoption and gain a selling point too.

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.

[domob]

However, we should get feedback from phelix / moa / snailbrain / domob. And Indo should be able to respond.

For my part: I think it would be great to at least encourage the use of TLS as far as we can, and when I finally come to reconfiguring my .bit domains to point to my new VPS, I will also configure TLS for them. (It is already enabled for all the sites I host with conventional domains, but not enforced (except for nameid.org) because the certificates are signed by CAcert for the other sites. But you can go to https://www.domob.eu/ if you like and know about CAcert.)

But I think it should be possible to "allow" non-TLS name resolution, too, for fallback cases and when TLS is not an issue. (For instance, it should be possible to configure my system to do system-wide .bit resolution (not just within the browser) and then "ssh daniel@domob.bit", right? In this case, TLS obviously is not wanted.)

[biolizard89]

However, we should get feedback from phelix / moa / snailbrain / domob. And Indo should be able to respond.

For my part: I think it would be great to at least encourage the use of TLS as far as we can, and when I finally come to reconfiguring my .bit domains to point to my new VPS, I will also configure TLS for them. (It is already enabled for all the sites I host with conventional domains, but not enforced (except for nameid.org) because the certificates are signed by CAcert for the other sites. But you can go to https://www.domob.eu/ if you like and know about CAcert.)

But I think it should be possible to "allow" non-TLS name resolution, too, for fallback cases and when TLS is not an issue. (For instance, it should be possible to configure my system to do system-wide .bit resolution (not just within the browser) and then "ssh daniel@domob.bit", right? In this case, TLS obviously is not wanted.)

The proposed "enforcement" feature would only apply to HTTP; other services would only enforce a particular TLS cert if that port is specified in the Namecoin data. So you could choose to not specify a hash for the SSH port and then it wouldn't be enforced. HTTP is a special case due to sslstrip, which isn't really an issue for other protocols.

[biolizard89]

So, here's a possible counterpoint.

Right now, the .bit spec degrades gracefully when the only .bit-aware user client is a DNS server. For example, Tor/I2P/Freenet domains don't resolve. Enabling HTTPS enforcement by default would mess this up. If the user only has a .bit DNS server (and therefore can't do enforcement), he/she will get a different result from a user with a proxy or browser extension (which can enforce HTTPS). Of course, this is also the case for HSTS.

There is discussion among the DANE people of adding a way to enforce HTTPS... but they explicitly say that the presence of a TLSA record for TCP port 443 does not imply HTTPS enforcement.

I'm still not sure what I think about this, just wanted to put this out there. I think I'm still okay with assuming that if TCP port 443 has a fingerprint then HTTP should be enforced to HTTPS, and I think I'm also okay with having a doNotUpgrade flag in the spec for the rare cases where this will break something. We're operating in a different situation from DANE's authors.

@Indo, it would be awesome if you could post here with info about how this affects your use cases. (I apologize if anything in my above post offended you; that's a reflection on the fact that I wrote it in the middle of the night between homework assignments, I wasn't trying to be overly critical. We'd really like to get some input from you on this.)