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

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 21 February 2015 05:32 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 B28211A1B11 for <dane@ietfa.amsl.com>; Fri, 20 Feb 2015 21:32:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 7nBm63ytmP9f for <dane@ietfa.amsl.com>; Fri, 20 Feb 2015 21:32:28 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783BA1A1B0D for <dane@ietf.org>; Fri, 20 Feb 2015 21:32:28 -0800 (PST)
Received: by iecar1 with SMTP id ar1so12854603iec.0 for <dane@ietf.org>; Fri, 20 Feb 2015 21:32:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uzByvynnQgCFa6dRJYzHlgm4oDXWi3URGbKwWD17388=; b=h7YPTkmUYu3ML20dQCXwZygEjPR481kp8bSOFiS6mz+9tjRFi/su3d3fts1c25K3ZN vMt+4jt/qVjioMhotLXkdnzv1PnjZdDC5njSRzexwPo8gkYHC5NuoZoDF8IUn7E/p9jM 9tAqrQBmNStriUYYK9w7zO8iT+4UbTrQwrtwl48IOACqrcxyna7wc2zxjBkG2VkllBy1 URN01l0Vjw+rvvvjZ1lAipZbQ8kvRj8y0oabkKC8LAAwStjKQ59zwEcRJoEqxxR17Woc 6VudY2eQjy2lVbb094YqJJ6QiQwFKQdbpolHrIwA3c+irMEwyzEFJsjq5D6YaksaAE8n Vqnw==
MIME-Version: 1.0
X-Received: by 10.50.32.7 with SMTP id e7mr989266igi.21.1424496747465; Fri, 20 Feb 2015 21:32:27 -0800 (PST)
Received: by 10.64.80.193 with HTTP; Fri, 20 Feb 2015 21:32:27 -0800 (PST)
In-Reply-To: <98BDCF0E-88CD-4392-9194-DABB8AA62532@ogud.com>
References: <20150220220921.GH1260@mournblade.imrryr.org> <98BDCF0E-88CD-4392-9194-DABB8AA62532@ogud.com>
Date: Fri, 20 Feb 2015 21:32:27 -0800
Message-ID: <CAH1iCir8px=vvyCernUSCnh6b8A-oY6SCTGZ81DjFWhJSDt9fw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Olafur Gudmundsson <ogud@ogud.com>
Content-Type: multipart/alternative; boundary="047d7b10cbf19dd5fa050f927e74"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/mT0Z7iSVF-mYXGK884rr4RgZqi4>
Cc: "dane@ietf.org" <dane@ietf.org>
Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Sat, 21 Feb 2015 05:32:31 -0000

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 <ogud@ogud.com> 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 <ietf-dane@dukhovni.org>
> 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
> > dane@ietf.org
> > https://www.ietf.org/mailman/listinfo/dane
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
>