Re: DNSSEC architecture vs reality

Michael Thomas <mike@mtcc.com> Mon, 12 April 2021 22:43 UTC

Return-Path: <mike@fresheez.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 D500B3A12EA for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 15:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level:
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc.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 jnmuK2lg9nom for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 15:43:34 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 9FC1E3A12ED for <ietf@ietf.org>; Mon, 12 Apr 2021 15:43:34 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id e8-20020a17090a7288b029014e51f5a6baso2653802pjg.2 for <ietf@ietf.org>; Mon, 12 Apr 2021 15:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc.com; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=HooIFApg9afik37gjD8HBWQDNYz9A6lvtpit87LgHfk=; b=VJW809HsZkyDp1rG9CrImMfBMHKUWtWHUfmPO1w/SYH6Pj6NhlQIn2D26zvgvMPD3m Cz0RhsDJU7J0xzIQTHZDFUN8VJK6zUFvDPWhNxMqssCu99MwUtRlHZxKb4/D3k1kH6r1 VXQx3jGW++R0vo616Ku6WgG85LyRFOQzDgR8UyAWSQIEO0CRdKc3RMZAS2+4yXitErum vtzoP8hYdhTMFqVti8VvMmtT1lfKFoiXaKB5s3oDRCryF/yta2ipjfR94EsG3+z6+dFT UtDEZdkvJspAIwBtyGsdqnKhzLalVxpAshFmBTqV7koRInrEliZJGS3wa4XzxJ6YYwEW 5QMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=HooIFApg9afik37gjD8HBWQDNYz9A6lvtpit87LgHfk=; b=PFh8LMoP4sEfJyiv/uLEKH3gx/wqySaaIaQxeg4LUWP0wu7tcLVb5XNKqXSDYFH8e5 xU25LLsS/Hv9WLO4OvROb3MzPCHz8/jud8TtpGHVCqCru0mtr+vCOdl0NeYjvSPKvUDV RoRpdaiiBiDCq9veqjRzfdpqRs078TyudTzhzuUh8VGWXZ8wwpnxsV+yWOdC1AH6wThr f0X3Q25C3ApCTx3S6Py0Az8qgv3lQw/IrJSGnQ0gnI0mQb+wqgVnUh//OxpZfQnSTMmq d6wpMqokPIw74Q3p1iHWmLusYLwCNysy0u2Ft1N3yEsxbsXi1+RArVSqcdSsj37xikDO zk3w==
X-Gm-Message-State: AOAM532tvvTERTj1Ak/w/6gHkxZq7icWqUSgzU4/34Xtrj203oGw1wIy FCpQXcJthsvGNDhVt47+ITpKWhfAkBuKXA==
X-Google-Smtp-Source: ABdhPJzw3UFVmq+zJO+wXps2HqgXCjDljf2/YWY+aQIqfhwmx2hNKN8giYdRA3qknbXD5pjCnqExMg==
X-Received: by 2002:a17:902:da91:b029:e5:cd82:b4c3 with SMTP id j17-20020a170902da91b02900e5cd82b4c3mr28102562plx.73.1618267413368; Mon, 12 Apr 2021 15:43:33 -0700 (PDT)
Received: from mike-mac.lan (107-182-38-56.volcanocom.com. [107.182.38.56]) by smtp.gmail.com with ESMTPSA id k13sm387116pji.14.2021.04.12.15.43.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Apr 2021 15:43:32 -0700 (PDT)
Subject: Re: DNSSEC architecture vs reality
To: Nico Williams <nico@cryptonector.com>
Cc: ietf@ietf.org
References: <YHN5ObR0eqea8Mrc@straasha.imrryr.org> <CABrd9SRdw9baHD5-j9nz4Zv5JjfL35TgaTvS787orEyGxZdKzA@mail.gmail.com> <YHOAzeOj1JaGdmsO@straasha.imrryr.org> <5e91c054-5935-df07-e8ba-09cc78f6c950@network-heretics.com> <YHPSP8Kij2K4v7qQ@straasha.imrryr.org> <82c5fcc6-b419-6efb-b682-b5dbb32905e2@network-heretics.com> <585D8590-472B-4CBC-8292-5BE85521DD76@gmail.com> <a6545baf-b15e-3690-d7b5-be33c4078e02@mtcc.com> <20210412221435.GV9612@localhost> <0755b70e-cc8e-3404-73cd-51950b3d7e53@mtcc.com> <20210412222748.GW9612@localhost>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <b0a43f25-c4c2-9f3c-1a42-426a6ef6afa0@mtcc.com>
Date: Mon, 12 Apr 2021 15:43:31 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <20210412222748.GW9612@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Un0j4-kh7seTnEPqr34oqJ6xSFY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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, 12 Apr 2021 22:43:39 -0000

On 4/12/21 3:27 PM, Nico Williams wrote:
> On Mon, Apr 12, 2021 at 03:17:32PM -0700, Michael Thomas wrote:
>>> (1) may have been because of (2), and I believe (2) was because of
>>> internal technical and political issues.  I.e., I would not consider it
>>> dispositive that Google seemed to like DANE then gave up on it, though
>>> that and why they did certainly is germane.
>> Yes, that's what I would assume as well. Build it and they will come has a
>> sterling track record of failure in IETF.
> Building a technical spec is not enough, indeed.  DANE hasn't succeeded
> yet, and neither has DNSSEC.  But DANE is starting to gather steam (in
> no small part due to Viktor's efforts) in the realm of SMTP.  The fact
> that DANE was early for its time doesn't mean that the single root and
> unyielding name constraints aren't appealing or appealing enough to make
> a more serious try now.
>
> As noted, the tooling for DNSSEC has been substantially improved in
> recent years.  Implementations of DANE do exist now.  There are a number
> of missing elements, such as a TLS extension to staple DANE that
> supports authenticated denial of existence.  We're making progress
> though.  It may seem slow, but there may be a preference cascade at some
> point.  It may only take enough user-agent, and registrar / domain
> hosting services to provide this functionality to make it popular.

Of course it wouldn't necessarily take http to eek out some interesting 
stats. But web stuff is extremely bursty so it's pretty much its own 
thing. I made an update to my flow to show that the TLSA record could be 
speculatively fetched at address resolution time which could be done for 
DNSKEY and DS records too, especially if you know from previous 
interaction that they were there before. All of those considerations are 
going to interact with how it performs in reality.

The one thing that bugs me about DANE is its use of a native RR type. 
This is a well trodden argument of doing it proper and doing it in a 
deployable way. We know what happens when you do it the "right way" 
which is usually nothing at all. If it started to get popular, we could 
gin up a TXT record alternative though, I suppose. When we were doing 
DKIM at Cisco, our IT folks were incredibly accommodating, but 
implementing a new RR type in their infrastructure would have probably 
been a bridge too far. Heck, I wouldn't be surprised if Mark at Y! got 
told the same thing :)

Mike, slowly getting up to speed on a bunch of the details of the 
underlying protocols