Physics#

The totalitarian principle is a concept in physics that states

Everything not forbidden is compulsory.

In order words, any observable outcome not forbidden by a physical law will occur. The many-worlds interpretation of quantum mechanics suggests an even stronger statement that for every such outcome, there is some alternate world in which it does occur.

Programming language design#

While

Everything not forbidden is compulsory.

may sound absurd, its contrapositive

Anything not mandatory is forbidden.

sounds more like a rule you would expect in a computer system, although it may not always be desirable. While it does not fully apply, programming languages and command lines are infamously picky about their inputs:

If you forget a comma in your English essay, your teacher doesn’t hand it back and say, I can’t understand any of this.

In contrast, HTML parsers have historically been quite flexible in what they accept. There's reason to believe this lack of strictness was a strength: less technical users could create their web pages using incorrect HTML that would still work. Somewhat related, browser vendors were also able to add their own extensions and explore what could be added to HTML. On the other hand, the result was large amounts of invalid HTML to the point that HTML5 had to add explicit rules for parsing invalid HTML.

Law and security#

Alternatively, the weaker statement,

Everything which is not forbidden is allowed.

enshrines the principle of law that citizens are free to do whatever they will except when explicitly forbidden by a law.

On the other hand, the same principle applied to computer security is called enumerating badness and is widely held to be a bad idea: put simply, while you as the user of your computer want the freedom to do whatever you want on it, you probably don't want arbitrary code which may have been written by malicious actors to have those same freedoms and it's unfeasible to list all the bad programs as much as you may try.

Instead, many modern systems support the reverse,

Everything which is not allowed is forbidden.

or enumerating goodness, in the form of software repositories and app stores. Although some of these implementations unfortunately go against user freedom.

.NET#

While it seems like we have exhausted the variants of this phrasing, as the title of this post suggests, some software systems follow yet another one:

Some things not allowed are compulsory.

Yes, you read that right.

Using the Windows Azure .NET SDK v2.3, in a web role, the web.config file contained the following automatically generated XML:

  <system.diagnostics>
    <trace>
      <listeners>
        <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
          <filter type="" />
        </add>
      </listeners>
    </trace>
  </system.diagnostics>

I was cleaning up warnings in this project hoping narrow down an unrelated issue and saw this warning on the <filter type="" /> tag:

The 'type' attribute is not allowed.

Naturally, I removed the type="" attribute which didn't seem to be doing anything since the warning said it wasn't even allowed. To my surprise, when I ran the code, it failed to run due to the initialization code throwing an exception with the following message:

Required attribute 'type' not found.

Hence, the type attribute is apparently both not allowed and compulsory.

As the message telling me it is not allowed was merely a warning and not an exception, I put it back and decided not to worry too much about it. Removing the <filter /> tag entirely also seemed to work and eliminate the warning as well.

DANE isn't a solution#

Yesterday, I described how to setup DANE in order to verify HTTPS keys through DNSSEC. I also noted a very important caveat: no one supports it and both Mozilla and Google are unlikely to ever support it. So we can't expect any security gain from implementing DANE in the real world.

Let's be fair: DNSSEC is no panacea. Browser vendors aren't ignoring it out of spite. They are choosing to not implement it for solid technical and social reasons.

Wait, what's the problem, again?#

Let's take a step back and look at why we wanted to use DANE in the first place. The problem is that the HTTPS security model is based on certificate authorities. Your browser has a list of certificate authorities that it trusts and to run a HTTPS site, you ask one (or more) of them to sign your server's public key asserting that your server really is the right one for your domain(s). The catch is that any certificate authority can make assertions about any domain and there's a lot of certificate authorities, many of which are suspected to be under the influence of various governments. This means that you are not just relying on the security of the certificate authority that you choose: you are relying on the security of every single certificate authority in the world. In short, the HTTPS security model is broken.

DNS is the system that provides information on hostnames like the IP address of aweirdimagination.net so your browser can connect to this website. DNSSEC is an extension which uses cryptographic signatures in order to verify that information is actually correct, preventing certain classes of attacks which could cause you to believe you are connecting to one server while actually connecting to a computer under the attacker's control. Additionally, since DNSSEC verifies information obtained through DNS has not been tampered with, it allows for DNS to be used for certificates, so servers can be authenticated for encrypted protocols without the need for relying on certificate authorities.

The problem#

Unfortunately, DNSSEC support is not widespread in clients or servers. Particularly, I did not want to run my own DNS server and have to worry about keeping it updated and being aware of any security vulnerabilities. I wanted to be able to, for a reasonable price, have a domain with full DNSSEC support and use it for securely advertising the https certificate for this website and the ssh server key for the web server. (Admittedly, I am trusting the DNS host more than strictly necessary, but realistically, they are also my registrar so they could simply publish their own keys for my domain if they wanted to take it over.)

The solution#

I settled on using easyDNS, since they were the only DNS hosting provider I could find that offered what I wanted; specifically, they very recently added support for TLSA and SSHFP records (for https and ssh keys, respectively). I later found mentions of RAGE4, which also looks like it should work.