The Need for includeSubDomains in HSTS RFC

Question

I am trying to understand the includeSubDomains directive in the HTTP Strict Transport Security standard. In particular section 14.4 of RFC 6797 confuse me.

Point 2. says

The HTTP request sent to uxdhbpahpdsf.example.com will include the Secure-flagged domain cookie.

This seems to imply that if a domain cookie has been set as secure, it may in fact be transmitted to a server before the certificate of that server has been validated. That would completely defeat the purpose of setting the cookie to be secure in the first place. If that's not the case, then what am I misunderstanding in that paragraph?

Point 3. says

and the user "clicks through" any warning that might be presented

This seems to imply that the threat scenario would only apply in case the user ignores security warnings or a CA signed a forged certificate. But if either of those were the case, the attack could just as well have been targeted at the example.com domain.

What is the connection between includeSubDomains and that paragraph? Point 3. only deals with a scenario, where the communication is passed over HTTPS anyway, which means HSTS wouldn't make any difference.

Answer 1

I think the way to read those three points is as three parts of one vulnerability, and are best read in a different order. HSTS does make a difference on HTTPS connections, and in fact a very significant one: HSTS does not allow users to click through a warning from the browser. All certificate validation errors with HSTS are fatal; the browser will not allow the user to add an exception, which is the biggest issue with relying on certificate warnings alone to prevent MitMs. So, if the attacker registers that subdomain, the issue is (in different order from in the RFC):

1. The attacker's site serves up a TLS certificate. If it's considered a valid certificate by the browser then HSTS doesn't help (because HSTS doesn't include pinning), but it's likely going to be an invalid certificate.
2. The web browser warns of a certificate issue. Because the subdomain doesn't have HSTS set, the user can add an exception or otherwise override the certificate warning to go to the site.
3. The domain cookie is sent to the attacker's server over the TLS connection.

With includeSubDomains, the following happens:

1. The attacker's site serves up a TLS certificate; again, if it's valid, the user is hosed.
2. The browser warns of a certificate issue. Because HSTS is set, this is a fatal error. The connection is terminated before an HTTP request is sent.
3. There is no 3. The connection was terminated in step 2.

(As a side note: certificate validation always occurs during TLS connection establishment; no HTTP requests are sent until after TLS is established. So no cookies are ever sent over HTTPS before certificates are checked.)

Answer 2

I could be wrong here, but I beleive it has to do with certificate pinning in the UA. "They preload a specific set of public key hashes into the HSTS configuration, which limits the valid certificates to only those which indicate the specified public key."

So I suppose in this attack scenario, the subdomain would be blocked by HSTS because it isn't presenting a valid certificate for example.com. Where as without includeSubDomains directive, example.com's cert is never considered, the TLS cert is accepted and the domain cookie is stolen.