draft-ietf-httpbis-semantics should not recommend checking the CN field in certificates

[davidben]

draft-ietf-httpbis-semantics currently says:

For a host that is a domain name, the client must include that name in the TLS server_name extension (if used) and must verify that the name also appears as either the CN field of the certificate subject or as a dNSName in the subjectAltName field of the certificate (see [RFC6125]).

This doesn't match the RFC6125, running code, or security best practices. RFC6125 leaves CN checking optional and not especially encouraged:

Therefore, if and only if the presented identifiers do not include a
DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
supported by the client, then the client MAY as a last resort check
for a string whose form matches that of a fully qualified DNS domain
name in a Common Name field of the subject field (i.e., a CN-ID).
https://www.rfc-editor.org/rfc/rfc6125.html#section-6.4.4

In terms of running code, neither Firefox nor Chromium check the common name field and the CA/B Forum BRs require that the CN field, if present, be a subset of SANs. And, in terms of security, the CN field's interaction with name constraints is very complex, so clients should not be encouraged towards the deprecated behavior.

The document should either say nothing and cite RFC6125 as-is, or mandate CN-less SAN checking, to align with best practices. (CC @sleevi who is probably better to review the final text than me.)

[davidben]

Looks like 6.4.3.1 also has a CN requirement to be fixed. (Along with several other errors we still need to file.)

[ekr]

ISTM that the right answer here is to cite 6125. To the extent to which 6125 is incorrect we should fix it. If there's some Web-specific behavior that you don't need for (say) IMAP, then maybe that could go here. @davidben are you aware of either of these?

[mnot]

How much of Identifying HTTPS Servers and HTTPS Origins should be replaced with a citation?

[davidben]

I'm not aware of anything web-specific, but @sleevi would know this more than me anyway. And yeah, my inclination is most of those sections should be replaced with a citation. HTTP probably does need some text here to facilitate cross-name pooling, but let's not restate fundamentals and then get it wrong.

Another example of the mismatch is this passage:

Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, an on-path attacker could have replaced the URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations.

That paragraph should probably be deleted altogether. Users should not be expected to carefully examine certificates. Even if they somehow did, it would still only authenticate the response to the URI and not help with the URI itself. Trustworthiness of URIs in general is also somewhat context- and application-dependent. A URI you want to deference in one context, with one set of HTTP state, may not be okay to dereference in another context. (E.g. CORS and the other complexities of web security.)

[martinthomson]

I agree with David here on that paragraph. You could say "a resource is only as authentic as the link that you followed to get there", but asking people to make critical security decisions is an outdated premise. And that assumes that anyone is capable of making a correct decision in this case.

As for the two sections identified, most of the Identifying section can just cite RFC 6125. That is:

If the hostname is available, the client MUST use the hostname as a reference identity as input to the verification processed defined in Section 6 of [RFC6125]. This process requires that a client be configured with a set of trust anchors. Certificate verification is used to prevent server impersonation by an on-path attacker or by an attacker that controls name resolution.

Then keep (and split) this, this, and drop the rest. This is useful, but the last sentence is not connected to the rest of the paragraph and should be split into its own paragraph to avoid that implication (which is more weird than wrong, but still wrong).

The origin stuff seems mostly OK (I reviewed that recently, so I'm unable to see problems that likely exist).