On 30 Oct 2017, at 19:30, Keith Moore wrote:
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.
I think what RFC 7817 says about certificate validation is fine, so I
don't want to repeat or contradict what it says.
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.
I don't know if this is done for mail, but SNI routing appears to be in
use:
http://proxy.dockerflow.com/sni-routing/
Luckily domain names are cheap, so example.com SRV can point to an
example.com.mailhosting.example.net domain name or something like that
so there's no ambiguity and RFC 7817 cert validation will work fine on
that domain name.
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.
It's becoming less likely over time that two connections to a particular
domain name will be handled by the same physical hardware. Luckily
certificates don't restrict this.
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.
Agreed.
- Chris
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
