Re: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

[Keith Moore <[e-mail]>]

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 [e-mail] 
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 [e-mail] 
> 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 
> [e-mail] 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
>
>