Re: [DNSOP] New draft on delegation revalidation

Shumon Huque <> Fri, 24 April 2020 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 783743A0A38 for <>; Fri, 24 Apr 2020 07:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2f5I-hQb5CzT for <>; Fri, 24 Apr 2020 07:50:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75D683A0ABF for <>; Fri, 24 Apr 2020 07:50:09 -0700 (PDT)
Received: by with SMTP id nv1so7740722ejb.0 for <>; Fri, 24 Apr 2020 07:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8NZ0r7URT3SYewOI7E0e5hJGBshh12pdqplFQ2JjEjc=; b=NJ1QQ2gLQT09cvqZ6ZRmXvrccNOPD/DjA4VAW9iDLVp0nDeeRI7+YmS9u8EPC+iVnA fL31vDEUwCeWGnI4uKVeOdiXcb6zCUh09WrbW4svfV+wQC6JhPk3rsmzcn3Ycv7XrmH6 P8AdHzpcVzEkNVTCv9bAtcugr46biyYpYUWnLgnrnrnPrnGXJC+B0z3aEOaUsa2Qrypt juT/W1pVneOvA0KFh3LApkUxbTQ1ihrDGUHXb4O8QizZwO0Fg7XI5YPbzMLrZwLkeBqn GtcacuYru87kA1lelGeUM4JXsZ+Khx89R6471rcppZ8XxMPLOxRkCCj92f6p3uqXMNYN 2Wkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8NZ0r7URT3SYewOI7E0e5hJGBshh12pdqplFQ2JjEjc=; b=DGsc81eAcotx3to8On958gqFRahYurprclT8+qAj+NE3jlYqYrvqdNU4LTw4RPh7+h gzbMLR0B+PVY5dbDNwJ+lTG4Nr9CIRWTDxDq8z1nIjko7BK2lbJCJ8fCzaxET5i/y7Bo Ga6tsU+7+XRhvgjlT671GGMVjU1ebWMqmaXz3+sFaeoPrYhKgqiptstmhIH5bA2CzD2+ 50PSzAnQm/RKFRaVFtNzaK+El0jOUr120jkJwmcbt1IZKEyCetJx04ZNe1rv5vdHD1hb mX7zpJ08S0mX2G/5P3WQIzjVh2TYh9ZzJDHbTTIw/TeOtxyqeDtH4kHQTgtj+4QeusQw /M6w==
X-Gm-Message-State: AGi0PuYqxnNToEF66/Q/Lk2bsd1gQ88fDT54iF7FiopG/h7i0X5O7lLw 5AIwsb0ppMZvrQS3XQxUkgjIr88Lxv06A5WvLcLe7/kZ
X-Google-Smtp-Source: APiQypIzb2UtC66CdrcJ8Adcc38ye2a8+lnsLeOBGJXFI8UlrgbR8N6HLTX+FgH8qz5DrxTi380HZd3R+nNulN6qV44=
X-Received: by 2002:a17:906:9718:: with SMTP id k24mr7450017ejx.229.1587739807813; Fri, 24 Apr 2020 07:50:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Shumon Huque <>
Date: Fri, 24 Apr 2020 10:49:56 -0400
Message-ID: <>
To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="0000000000003d94f105a40a7b46"
Archived-At: <>
Subject: Re: [DNSOP] New draft on delegation revalidation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Apr 2020 14:50:20 -0000

On Thu, Apr 23, 2020 at 7:09 AM Vladimír Čunát <>

> On 4/22/20 9:32 PM, Shumon Huque wrote:
> > Since delegation records and glue address records are unsigned, they
> > can be spoofed, and DNSSEC should really allow us to detect such
> > spoofing once a resolver sees referral data.
> I wouldn't put much energy into improving this part in *this* draft.

No worries! As I said at the DNSOP interim meeting yesterday, we
are *not* planning to take that problem on in this draft at all. That was
more of a side conversation because the topic has come up. You can
also argue that this is not technically a security issue, since the
is detected later on. So this is an issue of efficiency and early detection,
that arguably is not critical.

Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy,
> so I'd rather kill this problem by proper encrypted protocol towards
> authoritatives (in current dprive charter).

DNSSEC of course does not address privacy, that much is clear.
But I don't think I agree that encrypted transport addresses the
data authentication issue here.

In the general case, the DNSSEC security model does not rely on the
security of the authoritative servers themselves, but on the entities
that perform the signing. Encrypted and authenticated transport can
verify that you are obtaining the DNS response unmolested from the
correct authority server, but it doesn't protect you against compromise
of the server itself. DNSSEC protects you against this, if the signing
system is separately secured, as is the case with the DNS root, many
of the TLDs, and many enterprise deployments that use hidden and
inaccessible signing masters.

This is of course not true for the various online signing deployments. In
those cases, transport security is a more complete solution (because
the  signing keys are already exposed at the edges of the authority
server network).

Shumon Huque