Re: More haste, less speed.

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 06 March 2017 20:12 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18EF1299E6 for <ietf@ietfa.amsl.com>; Mon, 6 Mar 2017 12:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level:
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 srV8C7rs2L3q for <ietf@ietfa.amsl.com>; Mon, 6 Mar 2017 12:12:17 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 309DF1299DC for <ietf@ietf.org>; Mon, 6 Mar 2017 12:12:17 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id v198so44579071ywc.2 for <ietf@ietf.org>; Mon, 06 Mar 2017 12:12:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=/mBKUZ3/HeIpPxA4pqT+/VOdhZUfXegmenxiOm9udeg=; b=a6Rwj3k18gcuuCmtUvdZ3ZiuCaI7hMFOwOfX8biaI68CLu+wssL2kkkmdpXzrtEwu7 2PGg3wWMxR0dHetAM9BTnQLnBiijotaPnyCuahD9paqD3MwtRW30MN9LN1BqGLRFNkTk xFq8zbxWw7x0C54h1w1OR87GZuU+DyNPuVz1I5bKF8DnRJiGsJ0TXBBvHb+0C1Br0GX7 EfPo6Rd+OMdMSIoIIYsaiiWrQoeBs/ZRZ4zqhaOr6fnvVSvJG2WxQRWPp5dypmeqmNNq ZKXFYT2FwyXJnyoZ8/JEcZ6ifzJ1PREOxJorn4WAluPUjof7MZTdXg9M8RQerEZPCHjS ih/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=/mBKUZ3/HeIpPxA4pqT+/VOdhZUfXegmenxiOm9udeg=; b=Rjmt8XvWnH5TMwX2F/YXb/IrAdBGKeToUq2AaRIUkpAdtqSnAj/1Ogy6YcWPpeCgRN crQuuCde0BVdCSeMKWlFQo4atbW59Yq4u5LvQH1r+BExpUfzwRH2VtBuB07FujjQtXeK QxS3tVYdBY4bOqc34gmA6bEekv+EUVUekj6DoWl9EJoc9qtnKcuPkQUQC598C8KlW8pj idOPg9T0E4Q53P/qEJaoqxr9sZEQUd0HmNalEFeQyKNfz1YEG+JBksdFS7z+LiiA+lcf 0/+7hGi3MZOTqx2b9tUG8L0vYaS2Aelu9aov0i10N7ed7Vz5r8+ts2IaKWcQRqk0M8Lo DsJg==
X-Gm-Message-State: AMke39nwRmJicxeHX0sXGYlehIibyh4Zx+65L5eMmghPn/DrvAwKSbrwj2Oyt7mXG9vn1tYYdAxJUTlfxOlJsw==
X-Received: by 10.37.43.135 with SMTP id r129mr12889361ybr.126.1488831136137; Mon, 06 Mar 2017 12:12:16 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.83.19.20 with HTTP; Mon, 6 Mar 2017 12:12:15 -0800 (PST)
In-Reply-To: <DF91F5B4-D8A0-4569-9011-3C3E38C71F07@dukhovni.org>
References: <CAMm+Lwg1dvzMSKbWwoF0V6ZM5Q5_WVYxvpV=4_u=T0OTjCPxPQ@mail.gmail.com> <DF91F5B4-D8A0-4569-9011-3C3E38C71F07@dukhovni.org>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 06 Mar 2017 15:12:15 -0500
X-Google-Sender-Auth: bS0dW6RTPSXG88h73OW5zgWG37o
Message-ID: <CAMm+LwjWqXg_EA7_0aT5DagZv4YirreUv1wKGAtBir01WwMT5Q@mail.gmail.com>
Subject: Re: More haste, less speed.
To: IETF general list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c13587c004bc5054a1583d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/w2cFPcwwG2cswtaT3JOSW_9Zm2g>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2017 20:12:19 -0000

On Mon, Mar 6, 2017 at 1:11 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

>
> > On Mar 6, 2017, at 11:27 AM, Phillip Hallam-Baker <phill@hallambaker.com>
> wrote:
> >
> > DANE conflates publication of security policy with public key validation
> and distribution.
>
> Well, by far the main obstacle to DANE deployment is not this, but
> comparatively low
> (~0.6%) DNSSEC adoption.  Of approximately 1.5 million domains with DNSSEC
> for both
> the domain and one of the primary MX hosts, 110 thousand (and steadily
> growing) have
> DANE TLSA records (7% of those who can deploy, given DNSSEC constraints,
> have deployed).
>
> The conflation of security policy and key distribution is a late addition
> to DANE in
> RFC 7672.  The base specification in RFC 6698 is rather policy neutral.
> So perhaps
> tying the two together is in good part my fault.  And yet, despite that,
> there is
> considerably more deployment of RFC 7672 (in SMTP) than of RFC 6698 (in
> HTTP, which
> was its unstated primary focus).
>
> If you feel strongly that publishing TLSA records should not imply
> security policy,
> it is not too late to introduce a new policy specification protocol (that
> would
> still require DNSSEC) to decouple existence of DANE TLSA records from the
> desired
> security policy.  We could then retrofit MTAs to use the policy records
> when
> present.  This would then require two DNS lookups where one suffices, but
> might
> provide useful flexibility.
>
> Do you have use-cases in which publication of DANE-EE(3) or DANE-TA(2) TLSA
> records should not imply a request that sending domains use said records?
>
> My impression is that the adoption obstacle remains operational
> difficulties
> around DNSSEC and not missing policy hooks.
>

​Again, you are mistaken.​

​Security Policy can benefit from DNSSEC but it absolutely does not require
DNSSEC to provide value. Since the current Internet security policy is to
require no security, any policy publication mechanism adds value over the
baseline.

The reason DANE cannot progress is precisely that it is tied to DNSSEC in
such a way that instead of DANE getting itself widely deployed and becoming
a ​reason to deploy DNSSEC infrastructure, it is instead dependent on prior
deployment of DNSSEC so that it cannot succeed until after DNSSEC has been
deployed.

These arguments are not new, they have been rehearsed repeatedly and are
one of the main reasons for not tying policy to key validation. The other
being that the DNS registrars critical to deployment of DNSSEC sell DNS at
a loss and make their profit on the item DANE tries to make free of charge.
Its called a channel conflict and yes, they are show stoppers.