ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt> (Updated TLS Server Identity Check Procedure for Email Related Protocols) to Proposed Standard

2015-11-28 10:07:06
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).
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.

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).

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.

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.

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.

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.

-- 
        Viktor.

<Prev in Thread] Current Thread [Next in Thread>