Re: [Add] Relaxed validation and delegated IPv6 prefixes (Was: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt)

tirumal reddy <> Thu, 14 October 2021 11:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8E6D3A138D for <>; Thu, 14 Oct 2021 04:13:33 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NDXGGTaDLQem for <>; Thu, 14 Oct 2021 04:13:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EF633A139C for <>; Thu, 14 Oct 2021 04:13:29 -0700 (PDT)
Received: by with SMTP id n8so25223733lfk.6 for <>; Thu, 14 Oct 2021 04:13:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mn27o4c2uYj/jtmPX2ucGm7Z/h3okPjSvJtB6eWZ+OM=; b=pPxTqvNuBudxQPKTjlEyKUzrpwoC6RzD7lNEkdfxMhX1PimNAX8yfIbNZ4Mc8ML/hV 8r9natUWL/gH6Wyo/Q4P2DAVEKQCuUi7InXMyYD7WX+f63oJ6KhGSaPisTxzgW5QUBYK U1hiFR+Zw7Em1aVZAg4uCja7FxTAQvJhMHEjZoSEr8JF39iQSMGN1f4GyMGk0kTERoMN kzHrI/rv+aqi4BGrJQPFSTbDhMOGj/R2D6HLn16dF2oIDDp28UxyL46UCPIaqbnSsDnt CHS+h1MKIM1rHvA3Q2/YWD5yw7C0MUzILD+N858aMikMf3BBcXVqW78URCD3o8cLJBY9 H0ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mn27o4c2uYj/jtmPX2ucGm7Z/h3okPjSvJtB6eWZ+OM=; b=vpiSjLsACb8re9qfYnf1DJBFUQ/SGFk587yQ6tpfeh7seISlVszVOFJf7EbUPLfdM2 fiDhnT8zw0G1Rl0GcGUCAoe7BLlb2Ihcjxviv0N917FlVAlORmBGin+d9pKY98vzBREy 3+g/I0O89xtZkMsfTDUQj/zGuQU/jtrCfqXE7sz/2pfeAPm7hw27va6vqKuIXAH5qVwg 2zdzFd8svb3BVWVGkgyG00gki+DBjqEEj5GgDuXs7wThoPFMI/Cwnxx2NEYO0/PyxUTj J6ht/NusHjm41ufdvLEl9mK0k1/AQnaPMU5JtEKRGdDM0QPOmXntIkR8Wm2ci2cR1SyA TlGA==
X-Gm-Message-State: AOAM531JTOfrWEFLXAMFKmcOjmq9Umnd+haBNy8no4jhSfMc//GOXy4p XRDpuRlMYapwnZBV2t368R6+Ds6uQbN0k7PRC84=
X-Google-Smtp-Source: ABdhPJxhBwjVE2XVBobwot1eXSCZwRNOStlFGrpkyItAOfsbePlI/rCbi99deAfO0ZFvtfwkk+YrweL2y0oKz7igJCU=
X-Received: by 2002:a2e:b888:: with SMTP id r8mr5208865ljp.147.1634210005764; Thu, 14 Oct 2021 04:13:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: tirumal reddy <>
Date: Thu, 14 Oct 2021 16:43:14 +0530
Message-ID: <>
To: Ben Schwartz <>
Cc: "STARK, BARBARA H" <>, ADD Mailing list <>
Content-Type: multipart/alternative; boundary="000000000000e1d04b05ce4e2a3d"
Archived-At: <>
Subject: Re: [Add] Relaxed validation and delegated IPv6 prefixes (Was: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Oct 2021 11:13:34 -0000

On Mon, 11 Oct 2021 at 07:37, Ben Schwartz <bemasc=> wrote:

>  If the DNS forwarder is identified by a public address (IPv4 or IPv6),
>> then it could get a TLS certificate for that IP address.  A client policy
>> that doesn't require authentication in this case, even though
>> authentication is possible, would be a much bigger departure from baseline
>> DDR.  I would prefer not to describe that behavior in this draft.
>> <bhs> When you say “[the DNS forwarder] could get a TLS certificate for
>> that IP address”, are you saying it would be possible for a gateway to get
>> a PKI CA-signed certificate every time it gets delegated an IPv6 prefix
>> (and subsequent renewal)?
> I misspoke.  Let me try again:
> In DDR, the Encrypted Resolver must hold a certificate that covers the IP
> address of the Unencrypted Resolver unless the resolvers have the same IP.
> Thus, if the gateway uses a public IP address, and is actually a forwarder,
> then the upstream resolver must return a certificate that covers the
> gateway's IP address.

The challenge is the certificate of upstream resolver will have to cover
the IP addresses of several legacy gateways. I meant the unupgradable
gateway could be tens of thousands and it is not feasible to cover all the
legacy gateway IP addresses in the certificate.


> This is not the same as placing a PKI certificate on the gateway.  (I
> don't know if it's easier or harder.)
> ...
>> So if a client is provided a private IPv4 DNS server address and a public
>> (GUA) IPv6 DNS server address (and, BTW, both reply with identical
>> info), will the relaxed-validation client prefer IPv6 and
>> not upgrade because the IPv6 address is a GUA? Or will the
>> relaxed-validation client try the private IPv4 address (also?) and do the
>> DoH upgrade?
> I think it will do the upgrade, via the IPv4 server.
>> I’m ok not worrying about people with static public IPv4 address
>> assignments (assuming the same argument that a certificate isn’t
>> realistic). That’s a small population. But is it really not possible to
>> explore allowing “same IPv4 subnet” or “on-link IPv6 prefix”?
> Let's consider two clients, one implementing "baseline DDR" and one that
> relaxes validation as you've described.  They are on a v6-only network
> whose DNS server has a public IP and is "on-link" according to some
> criterion.  A DDR query tells the client to use a "far away" designated
> resolver.
> If the local DNS server is actually a forwarder, then it is arguably safe
> to upgrade without certificate validation.  However, the client doesn't
> know whether this server is a forwarder.  It might actually be a full
> resolver.
> Suppose there is an active attacker close to the "far away" designated
> resolver.  The "baseline DDR" client enforces certificate validation, so it
> detects this attacker and continues to use the local (full) resolver.  As a
> result, the attacker (who is far away) cannot see or modify most/any of the
> user's queries.  The "relaxed" client sends all their queries straight to
> the attacker.
> This seems like a much larger departure from the baseline DDR security
> model than anything contemplated in this draft, so I would prefer not to
> combine it.  However, this situation is important, and should be mentioned
> in the draft.  I've added the following paragraph in the pull request [1]:
> > IPv6-only networks whose default DNS server has a Global Unicast Address
> are out of scope, even if this server is actually a simple forwarder.  If
> the DNS server does not use a private IP address, it is not a "legacy DNS
> forwarder" under this draft's definition.
> [1]
> --
> Add mailing list