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