On Fri, Sep 20, 2013 at 11:47:35AM +0200, Stefan Foerster wrote:
> I see. So, for joe.u...@example.com the whole setup would probably be
> something along:
>
> - publish SRV record for _submission._tcp SRV 0 1 587 mail.example.com
Yes. Though it will be some time before most MUAs are zeroconf in
this way. Perhaps the mobile device OSs will lead here, but it is
also possible that each platform will simply assume you're using
their "cloud" email service, and not choose to support RFC 6186.
> - publish TLSA record for mail.example.com - one might think about
> certificate usage 0 or 1 here, right?
No. Whenever there is indirection between the user specified
destination and the name of the ultimate TCP endpoint host, and
especially when TLS support is discovered rather (also requiring
DNSSEC to avoid downgrade attacks) the public CA PKI is inapplicable
without DNSSEC, so the same guidelines apply, usage 2/3 only.
> - make sure the submission server at mail.example.com has certificates
> for mail.example.com as well as example.com, with example.com being
> the certificate that's displayed when the client does't support SNI,
> at least according to draft-fanf-dane-mua-00
No need. One certificate is enough. With certificate usage 2 TLSA
RRs, just point the SRV record at the same name that users who
don't rely on zeroconf via RFC 6186 are told to set as their SMTP
server. With certificate usage 3 TLSA RRs, the name in the
certificate is irrelevant.
> from an ops PoV, the requirement of having two certificates, one for
> the server hostname and one for the mail domain, with the need of
> obtaining both from a CA that has widepread support amongst MUAs, with
> the further need to provide two endpoints, one for old and one for new
> clients, is a real PITA.
There is no such need, the draft RFC allows server operators to use
*either* name (whichever they prefer), and requires clients to support
both. There is NO requirement for server operators to publish both.
> JFTR: The second mentioning of RFC6409 in section 3 of
> draft-dukhovni-smtp-opportunistic-tls-01 might possibly be a typo,
> referring to RFC6186.
Thanks, yes, I'll fix that.
--
Viktor.
