Dear colleagues please take a few minutes to review this document if you have not done so yet. This is a critical document from the working group and the chairs rather want the WG to find any issues then in IETF last call.
We plan to start a WGLC on the related OPS document RSN and will live with cross references between the documents as they will all be published at the same time Olafur > On Feb 20, 2015, at 5:09 PM, Viktor Dukhovni <[email protected]> wrote: > > 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. > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
