Security error in GMail's TLS setup

RFC 6186 specifies how to use SRV records to auto-configure an MUA given an email address. There is an error with the setup of GMail's RFC 6185 SRV records which means that a correctly implemented client will fail to connect, reporting a certificate mismatch / security failure.

The SRV records are:

  _submission._tcp.gmail.com. 84664 IN  SRV   5 0 587 smtp.gmail.com.
  _imaps._tcp.gmail.com.      84628 IN  SRV   5 0 993 imap.gmail.com.
  _pop3s._tcp.gmail.com.      86400 IN  SRV  20 0 995 pop.gmail.com.

These servers all present certificates that only authenticate the corresponding SRV target host name - they do not contain any SubjectAltName fields for gmail.com. They also do not support Server Name Indication to vary their certificate according to the name expected by the client. The gmail.com zone is not signed with DNSSEC.

RFC 6186 says that certificate verification follows the procedure set out in RFC 6125. The relevant part is RFC 6125 section 6.2.1. In particular,

Each reference identifier in the list SHOULD be based on the source domain and SHOULD NOT be based on a derived domain (e.g., a host name or domain name discovered through DNS resolution of the source domain).

That is, the only acceptable reference identifier for an RFC 6128 client that has been given a gmail.com address is gmail.com. This does not match the identifiers in any of the certificates.

This error is not a security vulnerability in itself, though it can lead to vulnerabilities when combined with human factors, such as:

Users of RFC 6186 clients might turn off certificate verification for gmail.com in order to make connections work.
Authors of RFC 6186 clients might copy the same mistake for interop purposes and write code match certificates against insecurely derived identifiers (SRV target hostnames in non-DNSSEC zones).