On Sat 28/Nov/2015 17:06:45 +0100 Viktor Dukhovni wrote: > On Sat, Nov 28, 2015 at 03:32:22PM +0000, Alexey Melnikov wrote: > >>> Some guidance on how to check/configure vanity domains may be >>> appropriate, IMHO. >> >> If you can suggest some specific text, that would be great? > > Well, from vanity domains are not different from non-vanity domains. > The choices are the same, vanity or not. > > From the MUA's perspective, the domain to validate is typically > the domainname of the explicitly configured servers (I've not seen > much adoption of RFC6186, but perhaps I've not looked hard enough). (Perhaps offering an automated way to discover login locations is being felt as a possible weakness? Hm...) > In which case it is up to the domain owner and service operator to > agree on suitable names for the IMAP/POP/SUBMISSION servers, and > ensure that corresponding certificates are in place. Assigning IPs and certificates seems to be an order of magnitude harder than just adding a bunch of DNS records, even assuming SNI is globally available. > In the brave new world of RFC6186, the new primary reference > identifier is the appropriate SRV-ID based on the domainpart of > the user's email address, with the DNS-ID for interoperability with > current practice. > > The target servername from insecure DNS lookups is not automatically > an acceptable reference identifier. RFC6186 suggests user > confirmation, and we all know how well that typically works (yes, > with a particularly attentive and knowledgeable user it can shorten > the process of MUA account setup). MUAs seem to want users to type just their email addresses. > For clients that support DNSSEC and perhaps DANE, using the target > server name from RFC6186 SRV records becomes an option that may > not require user confirmation. Once one trusts DNS for the reference > ID, one may as well trust it for the certificate validity, at which > point we're looking at essentially 7672 with s/MX/SRV/g. Good point. > In any case, I don't see how "vanity" domains are particularly > different. At present, in most cases the user will configure explit > submission and imap (or POP) server names, and connections to these > will employ PKI in the usual way. Of course, a vanity domain which goes all the way with DNS, IPs, certificates, and servers is not distinguishable from a regular (virtual?) domain. The point with configuring a vanity domain is to do the least effort required in order to have its name show up as a regular domain to third parties. > Some domain owners want the submission server name to stay in their > own domain, so they can switch providers without having users update > MUA settings. These are the most complex configurations, where > RFC6186 might have helped, if only it were actually supported by > MUAs and DNSSEC were more widely deployed. Instead we're left with > the complexity of TLS virtual hosting with providers needing to > field some sort of certificate (DNS-ID or SRV-ID) associated with > each such domain. I don't know how workable that's turning out to > be. Agreed. Given that complexity increases the chances to overlook some details, especially while switching providers or servers, trying to meet domain-part verification for each vanity domain may actually result in less security than otherwise. Since owners of vanity addresses are perfectly aware of what kind of address they use, they can as well manually confirm server names. That is, validation based on the domain part of an email address may be unfeasible for vanity domains --it may work via DNSSEC SRV recs. > The last bit complexity is in the vanity domain's SPF and DKIM > records, so that the hosting provider's submission servers can > originate mail for the vanity domain. Agreed, but OT. Ale