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

["Chris Newman" <[e-mail]>]

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 
>> [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
>>
>>