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

[Olafur Gudmundsson <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane