Re: DNSSEC architecture vs reality (was: Re: Quic: the elephant in the room)

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 12 April 2021 04:53 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 6171E3A2E4F for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 21:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ImiFppdMSm9q for <ietf@ietfa.amsl.com>; Sun, 11 Apr 2021 21:53:26 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246873A2E4C for <ietf@ietf.org>; Sun, 11 Apr 2021 21:53:25 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 60AFBB9909; Mon, 12 Apr 2021 00:53:19 -0400 (EDT)
Date: Mon, 12 Apr 2021 00:53:19 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: DNSSEC architecture vs reality (was: Re: Quic: the elephant in the room)
Message-ID: <YHPSP8Kij2K4v7qQ@straasha.imrryr.org>
Reply-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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5e91c054-5935-df07-e8ba-09cc78f6c950@network-heretics.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/JbCoMQGuTmRjpfZAmIPyrButbOI>
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 04:53:31 -0000

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.

-- 
    Viktor.