On Fri, Sep 20, 2013 at 04:39:42PM +0200, Stefan Foerster wrote:
> > 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.
>
> To be honest, that's not what I read from section 4 of
> draft-fanf-dane-mua-00:
I'll take a look at that. It is still a draft, if necessary, we'll
work to revise it.
> | A mail server that is the target of an [RFC6186] SRV record MUST have
> | a TLS certificate that authenticates the SRV owner domain (i.e. the
> | user's mail domain). This is necessary for clients that cannot
> | perform DNSSEC validation. This certificate MUST be the default that
> | is presented if the client does not use the TLS Server Name Indication
> | extension (TLS SNI) [RFC6066].
>
> | In order to support this specification, the mail server MUST also have
> | a certificate that authenticates the SRV target domain (the mail
> | server hostname). This can be done using a multi-name certificate or
> | by using the client's TLS SNI to select the appropriate certificate.
> | The mail server's TLSA record MUST correspond to this certificate.
>
> Or were you referring to draft-dukhovni-smtp-opportunistic-tls-01?
The latter naturally. My take is that clients using SRV RRs that
can't do DNSSEC get no security so there's no point in specifying
required certificates for these. Especially with many domains
hosted by third parties it is impractical to require pervasive
trans-organizational SNI. So the above requirement is a mistake
that needs to be corrected.
> P.S: I feel that we might be stretching what's considered on-topic on
> this mailing list - perhaps we should take this off-list, or to a more
> appropriate (read: DANE related) list?
If you want to pursue the MUA issues further, or have additional
questions/comments about DANE for MTAs, feel free to join the
DANE WG mailing list:
d...@ietf.org
Your timing is good, Tony has just returned to the list after a
long break, and this is a good opportunity to start resolving
any conflicts between his prior work and my more recent drafts.
--
Viktor.
