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

[Viktor Dukhovni <[e-mail]>]

On Wed, Jan 07, 2015 at 12:25:05PM -0500, Sean Turner wrote:

> I read the DANE-SRV record, had some nits (Victor also caught
> 'em), and support progressing the draft.

I think you're saying that the associated revisions can be made as
part of moving into IETF LC, and don't need further WG review? Is
that right?  But being new around here, I am not quite sure.

> Still working on the SMTP draft it's a big denser.

Yeah, sorry about that.  The SMTP draft is a lot more detailed,
because it is applies DANE to a concrete protocol, and so can and
I think should be more specific in its prescriptions.

With RFC 7435 out the door, at least part of the basic premise need
no longer be debated.  We'll need to remember to update the references
from draft-dukhovni-opportunistic-security to RFC7435 at some
convenient point in time.

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.

P.S.

As for deployment stats, my curated list now has 794 domains, but
not all of that is recent growth, some is due to an additional data
source that contributed 241 domains.  The domain count for my
original sources grew from 463 to 553 over the last month.

The count of domains for which TLSA lookups break stands at 2561,
with 2352 of them attributable to 3 .nl and 1 .cz hosted DNS
providers:

    910 transip.nl
    852 forpsi.cz
    453 hostnet.nl	
    137 ns0.nl

I'm told that the above registrars, which account for the bulk of
the deployment barriers, are working on it, and I am still optimistic
that this will be addressed over the next few months.

Anyone reading this who is operating PowerDNS older than 3.3.1,
should upgrade, as older versions generally exhibit interoperability
issues (incorrect denial of existence).