Re: DNSSEC architecture vs reality

Keith Moore <moore@network-heretics.com> Mon, 12 April 2021 12:25 UTC

Return-Path: <moore@network-heretics.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 3FEA93A1BA3 for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 05:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 W1a_Ri5vO1xM for <ietf@ietfa.amsl.com>; Mon, 12 Apr 2021 05:25:11 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044CE3A1BA2 for <ietf@ietf.org>; Mon, 12 Apr 2021 05:25:10 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DE36B5C013C for <ietf@ietf.org>; Mon, 12 Apr 2021 08:25:05 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 12 Apr 2021 08:25:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=BONKZIf3YRK7NUHEccN5nCToOyc/IFW5gsLLV1dGm S8=; b=P+rlTCcA3AhLyN8F/BQxOqJQN3iUXPW8ZPLr2W3D0FabSJ8snfl0hTGgD vMKCi3u5HB++O0cQyTrRe6gHNiAcfZ/T4gu+EgC/FA+0U6ts8BF9koYh8gGOY6pq LGwWuaVXz0mvaFSoOoPZ9Vvj5Gvm/WzZKfHul+nqsPtQItJ82IIeT86xRmUTIuwj xIVxTs/adKLZlBbWOXsdR2pKMzsJOcRCY5H2i7qbO8s9QuUdN7dTILfQWvTGqA/G Oo/v1GVDVBip8Mupc78J9IfgFYVpgI0v7ZNK94V8v2D5FHcYUvy1JPJyHoBuQIXh qWN6XhnwARJ9jpj0wbdjQHS8qAsCA==
X-ME-Sender: <xms:ITx0YNt4FxPrL2_hv2RRTUWB306HygorgeMlswIl9Kmu8uoCqihqNA> <xme:ITx0YIeimQeLtj2n6Jjpt101nS-yFVHfEw_aAGc-2qgRzXyzRg37apTf-BB70DAlr 2-zMpcvciO4iw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekjedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepvdefrddu vdegrddutddrudejtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:ITx0YKL-WJP-xySa1Oqb0DsUuXhX8UK3LT32yzSl1XHH6GZKgzlJ3g> <xmx:ITx0YGbsJowozQXxCr81_rzPe3yZtciIZcv5idFzzel5ib6iaIx2WA> <xmx:ITx0YFs4qchvuTOQB1NqUF9i6gBPGeJLVwFApV6R2sSRJRF_X6D97g> <xmx:ITx0YEZTqrpKn6DCQNQzToT2UvIDbY0yhiBXwi2oXU3ll8Ugah9QjA>
Received: from [192.168.1.121] (23-124-10-170.lightspeed.knvltn.sbcglobal.net [23.124.10.170]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B69D108006A for <ietf@ietf.org>; Mon, 12 Apr 2021 08:25:05 -0400 (EDT)
Subject: Re: DNSSEC architecture vs reality
To: ietf@ietf.org
References: <3593a01f-73f4-7d03-a85b-dff64a8b070e@mtcc.com> <CABrd9STZXonBDvWB7Z36H2mD20Juubc01TUmEvpfWkvJggQVOQ@mail.gmail.com> <ab6bcbf0-646c-9f2d-5f98-fdc3e9ba27bf@mtcc.com> <CABrd9STEqvgexYKTUdFqn1zu=U2+h92_aDS6rM=8xcwibNJM3A@mail.gmail.com> <YHMc54xe1Mnx2U2y@straasha.imrryr.org> <CABrd9SShpOnSpshnMZSag4ZVp6ic5tURFoH9RzT0WCXDHyxgkA@mail.gmail.com> <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>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <82c5fcc6-b419-6efb-b682-b5dbb32905e2@network-heretics.com>
Date: Mon, 12 Apr 2021 08:25:03 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <YHPSP8Kij2K4v7qQ@straasha.imrryr.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wEQSYlHC8kBlKjJghvL6hNBVDhY>
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 12:25:16 -0000

Viktor,

Thanks for the update.   It looks as if progress is indeed being made.   
Now I wonder: what is being done to publicize DNSSEC to try to get wider 
adoption?

Keith

On 4/12/21 12:53 AM, Viktor Dukhovni wrote:
> On Sun, Apr 11, 2021 at 07:57:15PM -0400, Keith Moore wrote:
>> On 4/11/21 7:05 PM, Viktor Dukhovni wrote:
>>
>>> There are of course pros/cons for CT and pros/cons for DNSSEC, but my
>>> take is that architecturally DNSSEC is better suited for securing the
>>> typical domain on the public Internet.
>> Architectural arguments are great, but pragmatically speaking there seem
>> to be significant deployment problems with DNSSEC.
> Historically, yes.  But substantial improvements have been made, and it
> is now much easier than it used to be.
>
>>> Adoption has been hampered by difficult KSK enrollment, rollover,
>>> immaturity of tooling and by habitual cynicism from plausibly
>>> authoritative voices.
>> These aren't the problems (except perhaps immaturity of tooling) that
>> most immediately come to mind.
>>
>> Where is the easy to understand guide for how to sign your own RRs or
>> zone(s), and to verify that the signing is properly done?
> With BIND 9.16, just pick one of the stock policies, and BIND does the
> rest, generates keys, keeps the signatures current, periodically rolls
> the ZSK, even rolls the KSK and publishes CDS/CDNSKEY RRs, and I believe
> delays retiring the old KSK until the parent domain actually updates
> the DS RRs (whether via CDS, or manual update).  Try it!
>
>> Which registrars provide tools for signing, or do you have to operate
>> your own master DNS server in order to do that?
> If you're talking about registrars that sign zones for you, there are
> many.  Some of the ones hosting large numbers of signed domains are:
>
>      - one.com
>      - ovh.net
>      - googledomains.com
>      - Amazon Route 53
>      - transip.nl
>      - domeneshop.no
>      - forpsi.cz
>
> Many others, those are just some of the larger ones.
>
>> How long does it take for the typical domain name owner to sign their
>> RRs for the first time?
> With BIND 9.16, just add a policy to the zone definition.  A few
> seconds.
>
>> What's the ongoing commitment in time for a domain owner to maintain
>> DNSSEC for their RRs?
> None, BIND keeps the zone signed.  Of course wether you're signing or
> not, service monitoring is highly recommended, to check signature
> validity I use
>
>      named-compilezone -i local -jD -f raw -o - $zone $zonedb |
>          ldns-verify-zone -e P0Y0M3DT3H23M54S -V1 -S /dev/stdin
>
>> What's the immediate benefit to the signer from signing one's own RRs?
>> (Note: if nothing is verifying signatures, the immediate benefit is zero.)
> Since "nothing is verifying" is simply false, the benefit is that
> verification indeed takes place.  The strongest case is hardening
> of CAA records and TLSA records.  Soon also HTTPS and SVCB records,
> which have security-relevant information, worth hardining IMHO.
>
>> And how do we close these (and doubtless other) gaps?
> My zone has been signed since ~2014, no gaps to report, but for more
> complex environments work is being done to address
>
>      - multi-provider signing (Shumon Huque, et. al. doing great work)
>      - CDS support by registries and registrars, .CZ, .ZA, soon
>        Godaddy...
>
> We're not standing still, lots of good activity to close the gaps both
> new and longstanding.
>
>> I'd love for the Internet to be able to make better use of DNSSEC and to
>> need to rely less on PKI.  But for all that I love about this idea, I
>> don't think this is going to happen until most of these problems are fixed.
> That's why lots of work is happening to address the remaining adoption
> barriers.
>