HSTS Preload List: State of the Union 2016

1) I don't understand how an attacker would manage to "register" a sub-domain within a domain I control. AFAIK this would require a DNS MITM.

2) How can the attacker's HTTP server present a TLS certificate? Presumably the author missed a step in there; a redirect?

3) Why is an intermediate HTTP request even necessary in this scenario? If a browser is pointed at the false sub-domain via https and the user clicks through the TLS cert, won't it give up the domain cookie regardless?

4) Given #3, the only benefit I see includeSubdomains providing is that it changes the TLS cert warning into an error. Is this a correct analysis?

A much more realistic scenario would be that an attacker MITMs an existing HTTP-only subdomain and upgrades it to HTTPS with a false cert. Or that an attacker MITMs DNS to serve a false HTTPS subdomain. (I think the author conflated these two scenarios.) In these cases I see the safety includeSubdomains would provide, albeit one that DNSSEC would also provide.

If you're worried about the attacker getting DNS (e.g. by spoofing DNS) and running a webserver at subdomain.victim.com, the user has to click through a certificate warning. I can see why the HSTS preload list would want to worry about making it hard for user error to compromise security, but I don't think it's a very sensible part of a threat model for HSTS as a whole..

(For those cases where you explicitly permit people to register websites at a subdomain of their choosing, e.g. stuff like username.github.io, you need to register github.io in the Public Suffix List. This prohibits github.io from having any cookies set on it.)