On Fri, Dec 04, 2015 at 03:01:12PM -0500, John C Klensin wrote:
[ Excellent advice on UTF-8, get solid internal plumbing first,
burn that in, then proceed to higher-level features. ]
> p.s. For a variety of reasons, I'm not a big DANE fan and you
> may want to discount the comment that follows on that basis.
Comment noted, not discounted.
> However, my perception from several of the relevant IETF lists
> is that there is still a lot of controversy about details of the
> relationship among DANE, MTA-MTA TLS, and assorted other mail
> system issues. Until those discussions stabilize (again, with
> the understanding that Victor and others may think they are a
> lot more stable than I do), it would perhaps be unwise to
> include anything in a production release that you would be
> uncomfortable making incompatible changes to later.
While there is active ongoing discussion about security models for
MUA connections to SUBMISSION/IMAP/POP services, the role of RFC6186,
etc. I've seen nothing to suggest that MTA to MTA DANE per RFC7672
is controversial other than the key barrier of DNSSEC adoption.
If you're allergic to DNSSEC, then DANE is moot. If DNSSEC is not
a show-stopper, then DANE for SMTP (RFC7672) a natural and
non-controversial adaptation to SMTP of RFC6698 DANE TLSA (as
updated by RFC7671). I've not seen anything to suggest that the
specification is likely to change incompatibly.
Over the past year the number of domains that have deployed DANE
TLSA records has grown roughly 20-fold (from around 500 to around
10000) and the number that are not "vanity domains" of individuals
has grown to 30. In October comcast.net published TLSA records,
and this month they will likely be joined by web.de and gmx.de.
I expect to have DANE TLSA support in an OpenSSL 1.1.0 alpha release
soon (some time in January most likely).
--
Viktor.
