Re: [dane] WGLC: DANE-SRV & DANE-SMTP
Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 08 January 2015 01:15 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE10B1A8846 for <dane@ietfa.amsl.com>; Wed, 7 Jan 2015 17:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKMs3n5hjJ1z for <dane@ietfa.amsl.com>; Wed, 7 Jan 2015 17:15:30 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3671A87D5 for <dane@ietf.org>; Wed, 7 Jan 2015 17:15:30 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8E17A282CC6; Thu, 8 Jan 2015 01:15:29 +0000 (UTC)
Date: Thu, 08 Jan 2015 01:15:29 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20150108011529.GU7322@mournblade.imrryr.org>
References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <113FC996-99E2-4203-BA55-AA901F9C0893@ieca.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/krui534XW6khBnaSgvz6Ba_uOWY
Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 01:15:33 -0000
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).
- [dane] WGLC: DANE-SRV & DANE-SMTP Olafur Gudmundsson
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Stephane Bortzmeyer
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Olafur Gudmundsson
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Peter Saint-Andre - &yet
- [dane] Reminder: WGLC: DANE-SRV & DANE-SMTP Olafur Gudmundsson
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Paul Hoffman
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Dan York
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Viktor Dukhovni
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Shumon Huque
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Olafur Gudmundsson
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP James Cloos
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Peter Saint-Andre - &yet
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Sean Turner
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Viktor Dukhovni
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Sean Turner
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Peter Saint-Andre - &yet
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Viktor Dukhovni
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Peter Saint-Andre - &yet
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Viktor Dukhovni
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Sean Turner
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Viktor Dukhovni
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Viktor Dukhovni
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Warren Kumari
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Sean Turner
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Peter Saint-Andre - &yet
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Viktor Dukhovni
- Re: [dane] WGLC: DANE-SRV & DANE-SMTP Olafur Gudmundsson