I have read the documents, and do not see any glaring problems. I support publishing them.
Brian On Fri, Feb 20, 2015 at 2:13 PM, Olafur Gudmundsson <[email protected]> wrote: > 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 >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
