I've taken a stab at writing a non-normative appendix explaining this.
-------------------------
Appendix. Use of Server Name Indication (SNI) in conjunction with SRV
records
This section attempts to explain the considerations involved when using
SNI in conjunction with SRV records, because they do not seem to be
adequately explained elsewhere. This section is not normative.
There are two scenarios:
1. When an MUA contacts a mail server using configuration information
derived from an SRV record.
This case is very similar to the case in which an MUA contacts a mail
server using configuration explicitly supplied by the user. In either
case the server name that the MUA uses to obtain the server's IP
address(es), the server name which is compared with the server
certificate, and the server name presented in the SNI extension, should
all be the server's DNS name - i.e. the target of the SRV record when
SRV is used to discover it.
For a concrete example, assume that a user has address [email protected]
and the mail service for example.com is hosted at
mailserver.example.net. The SRV record that Joe's MUA uses to learn its
configuration information might be
_imaps._tcp.example.com. SRV 0 1 993 mailserver.example.net.
When attempting to access Joe's message store, Joe's MUA would connect
to an IP address associated with mailserver.example.net on port 993, and
begin negotiating TLS, sending an SNI extension with HostName =
mailserver.example.net. Joe's MUA would then expect the certificate
returned to have CN-ID or DNS-ID matching mailserver.example.net. Per
section X.Y of this document, if the server's certificate doesn't match
mailserver.example.net, Joe's MUA must abandon the connection.
2. When a MUA derives, or refreshes, account configuration information
from the user's email address using an SRV record.
When initially configuring Joe's mail account, and perhaps occasionally
thereafter (say when the TTL from the SRV record returned from the
previous query for that information has expired or is nearing
expiration), Joe's MUA may repeat the SRV query for
_imaps._tcp.example.com. One way for Joe's MUA to verify that the SRV
record were authentically issued by example.com would be to verify a
DNSSEC signature on the SRV record; however, DNSSEC is deploying very
slowly and therefore might not be available. An alternate way for
Joe's MUA to verify that the SRV record were authentically issued by
example.com would be for Joe's MUA to contact mailserver.example.net on
port 993, negotiate TLS and include an SNI extension with HostName ==
example.com, and expect a server certificate with either a DNS-ID or an
SRV-ID matching example.com.
If the target of the current SRV record differs from the server name in
the MUA's previous configuration for that account and server, the MUA
must not attempt to authenticate to the server on Joe's behalf as
[email protected] unless the server presents a certificate which contains
an DNS-ID or SRV-ID matching example.com. If, however, the server
certificate returned does match example.com, and the authentication
succeeds, the MUA can then tentatively use the configuration information
for that account and server based on the new SRV record. However, the
MUA should then close the connection (without further interaction with
the server) and reconnect to the server using an IP address associated
with the server's DNS name, send the server's DNS name in SNI, and
expect the certificate to match the server's DNS name. If that is
successful, Joe's MUA can then update its configuration; otherwise, it
should retain its previous configuration settings.[*] (RFC7817
requires MSPs to return certificates with SRV-IDs if the services are
advertised using SRV records, but this is relatively recent, and an MSP
does not necessarily have control over the DNS records advertised by its
customers).
If the server doesn't return a valid, trusted certificate matching the
main domain, it doesn't mean that the new SRV record is inauthentic, but
it does mean that the new SRV record cannot be assumed to be authentic
based on only unsigned DNS records. Per section X.Y of this document,
the MUA must not automatically update its configuration information
based on an unsigned SRV record, but must require confirmation from the
user before updating it. For reasons similar to those listed elsewhere
in this document when an MUA encounters invalid certificates, the MUA
should not permit the user to simply "click through" to change the
configuration. The MUA should probably not even offer to change the
configuration at all unless the new SRV records persist over an extended
period of time.
In the absence of DNSSEC, and assuming that multiple services are
associated with an email address in the MUA's configuration, this
process needs to be repeated independently for each SRV record and
corresponding service that would alter the MUA's configuration for that
account. (In other words, successful validation of one SRV record using
this method does not imply that other SRV records for that mail domain
are also valid.)
This has implications for both MUAs and mail servers.
MUAs supporting SNI should send SNI with the service name when initially
configuring an account, and send SNI with the mail server's name when
accessing the account normally.
Mail servers supporting SNI need to be able to return certificates for
their own DNS names, and should also be configurable to utilize SNI to
return certificates containing SRV-IDs for the mail domains for which
they provide service. In some cases this means that a domain
example.com will need to supply a certificate matching a SRV-ID of
example.com (along with the private key corresponding to the public key
in the certificate) to the company or companies that provide its mail
service. Note that if the certificate only contains a SRV-ID for
example.com, the certificate and corresponding key pair is somewhat less
useful to an imposter as compared to a certificate with a DNS-ID. Of
course, the same key pair should not be used for both a SRV-ID
example.com certificate (where the private key is disclosed to a mail
service provider), and a normal DNS-ID and/or CN-ID certificate for
example.com.
Mail service providers supporting SNI to verify service name
certificates for any particular mail domain, need to do so for all
services associated with that mail domain.
-------------------------
[*] I'm not sure whether this should be included or not. It strikes me
as possible (and perhaps reasonable) that an MSP could provision
different servers for customers using SRV records than for customers not
doing so, so an MUA should not automatically update its configuration
based on a changed SRV record if the configuration was not originally
derived from SRV records. It also strikes me as possible (and perhaps
reasonable) that the server could behave differently when given an SNI
of example.com than when given an SNI of mailserver.example.net, much as
an HTTP server can behave differently when given a Host request header
of example.com than a Host request header of mailserver.example.net.
So my sense is that when actually reading or sending mail, the MUA
should behave consistently each time and always present the server's
name in SNI. (And if I were writing an MUA and the SRV record pointing
to a user's IMAP or POP server changed, I'd want to be sure that the new
server actually had the user's mail before committing the change to the
configuration.)
Anyway, given the length of the above and the difficulty of explaining
it I can see why Chris would like to keep it to one sentence.
Keith
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
