After a bit more thought on this, I've concluded that using the mail
server's server certificates to verify authenticity of SRV records
probably isn't a good idea - or at least there are more considerations
and pitfalls than can reasonably be thought through in the context of
this document.
One consideration is that TLS "reverse proxies" can (and likely do/will)
use SNI to dispatch to different hosts on the back end, as one way to
implement "virtual hosting" of mail services. So if j...@example.com
needs to be able to authenticate to mailserver.example.net after
presenting "example.com" in SNI, in addition to being able to
authenticate to "mailserver.example.net" after presenting
"mailserver.example.net", that's essentially going to constrain mail
service providers to configure such reverse proxies to map "example.com"
and "mailserver.example.net" to the same internal hosts, or at least
have both of those hosts consult the same servers for authentication.
This would in some cases make such reverse proxies essentially useless
as a means to dispatch different traffic to different servers.
Also, of course, being able to authenticate to two different servers
(even if both present valid certificates for their respective domain
names) is not the same thing as those two servers being the same.
So now I'm inclined to add a simple sentence or two along the lines of
Chris's suggestion. I think that's the best we can do in a short time
without additional review cycles.
Keith
On 10/28/2017 06:45 AM, Keith Moore wrote:
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 j...@example.com
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
j...@example.com 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
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
