Re: [dane] WGLC: DANE-SRV & DANE-SMTP

[Viktor Dukhovni <[e-mail]>]

On Tue, Feb 17, 2015 at 05:41:12PM -0500, Olafur Gudmundsson wrote:

> The SRV document got number of good reviews and editors have updated the
> document to reflect the comments received, version -11 should be final WG
> version and we plan to advance it to the IESG.

Great, thanks!

> SMTP document did not get as many reviews, only 3 that I can see Paul
> Hoffman (no comments), Dan York (not a thorough review) and Sean Turner,
> who had number of comments.

Perhaps some folks [hint, hint] can return the favour and review
the SMTP draft in full. :-)

> The github repository contains a version of the document that addresses
> all the comments received.  Editors please post ASAP.

A -14 version has been pushed.  I've not yet received any feedback on
the possibility of extending the operational considerations section
based on the last few months of operational experience.  Please
advise...

On Thu, Jan 08, 2015 at 01:15:29AM +0000, Viktor Dukhovni wrote:

> [...]
>
> I did ask a question during LC:
> 
>     http://www.ietf.org/mail-archive/web/dane/current/msg07159.html
> 
>     ...
> 
>     One deployment pitfall discovered in recent interoperability tests
>     is that some domains have cleartext-only anti-spam proxies in front
>     of their MTA, with the proxies only allowing connections to the
>     real MTA once the SMTP client passes a grey-listing check (this
>     was observed with "spamd" as the proxy, but any "selective access"
>     to TLS can be similarly problematic).
> 
>     If the receiving domain publishes TLSA records, this creates a
>     catch-22 with DANE-aware client MTAs.  The DANE client never begins
>     the first mail transaction, because the proxy does not offer
>     STARTTLS, (the proxy is a receiving system deployed downgrade to
>     cleartext MiTM in front of the real MTA).
> 
>     The short-term solution for such domains is to NOT publish TLSA
>     RRs for port 25.  Longer-term the anti-spam proxy should be upgraded
>     to support STARTTLS.  For example, the Postfix "postscreen" service,
>     which has functionality similar to "spamd", supports STARTTLS so that
>     grey-listing does not amount to a similar downgrade attack.
> 
>     I'd like to add some language about avoiding this problem in the
>     operational considerations section of the smtp-with-dane draft.
>     Any objections?  
> 
>     Additional operational considerations might include not forgetting
>     to update TLSA RRs for *all* the names under which a server might
>     be known when doing key rotation.  This is a problem particularly
>     when a single wild-card certificate is deployed on all the MX hosts,
>     and replaced concurrently on them all, creating an immediate outage
>     for any domains that use variant MX host names (for flexibility of
>     later hosting some domains separately).  With DANE one should
>     strongly consider per-server certificates to avoid synchronized
>     multi-MTA outages.
> 
>     And lastly, by far the most common problems are with DNSSEC.  A
>     mixture of failure to perform timely re-signing and at present lots
>     of domains with nameservers that have non-working Denial of Existence.
>     I don't have a comprehensive list of software that is deficient in
>     this manner, but it seems that some older versions of PowerDNS
>     botch DoE in at least some configurations.  Similar issues reportedly
>     with djbdns DNSSEC patches.  A few domains have firewalls that
>     block TLSA queries, one blocked these only for IPv4 clients, with
>     IPv6 clients not filtered, that can create difficult to diagnose
>     problems.
> 
>     So I am looking for guidance on how much *current* operational
>     experience to include in the draft that may ultimately become
>     irrelevant as the infrastructure improves, but may be very useful
>     to get us past the initial deployment hurdles.  If we don't get
>     early adopters past the initial problems, the long-term obsolescence
>     of the issues might remain forever in the future.
> 
> Any feedback on that would be appreciated, plus guidance on *when* to
> make any such changes.

-- 
	Viktor.