Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted

Eric Rescorla <> Fri, 24 April 2020 18:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B19BD3A078F for <>; Fri, 24 Apr 2020 11:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 b-esx70RbBHC for <>; Fri, 24 Apr 2020 11:54:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC1EE3A077F for <>; Fri, 24 Apr 2020 11:54:31 -0700 (PDT)
Received: by with SMTP id y4so11053136ljn.7 for <>; Fri, 24 Apr 2020 11:54:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wcOA2bLRxv9rlimobMq0xVI4sTKfoWUat8Qtw+usTTY=; b=TL8a52J76fUrs752BDcQGufivT2iuiHlcDSfBrs754M3sP3T6/ZXyCVpAEnnt7x9oV fyT+pQGun+uC4XyNDraVe5u2Kc6yEYvakl577Lrf/0zfGpFoZFH6AZODEz0plnHcmgHC KNdR08jvJRzhMaUNB2kSTZbhV3cyZwyMCdTEqBQyLIN6ObAe2hDQqWLUA8T39BCemv1Z xQI/YfHhFhRWGnJ3qR3gYAMMCSLjWK7oViyAT8jJhA9O5/8UwXPw48n7o2Msf/GlG2EP 4WEdinsSKy8N0Cq091t/OymqGzlsmtzVdWW/uYi0Hl3rESLA3cm8vv3iWAtaUcl+7LXA G0hw==
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=wcOA2bLRxv9rlimobMq0xVI4sTKfoWUat8Qtw+usTTY=; b=XPPGU0ijo536IX7u17wLwRJopow24euCs61d+6ZX6GF4h9FSLxBpn61mZL9bs9d2wi FCUDayy+TVKDXVV2NFUpF2EhfWrmK87ck7b00AfIWwdjMVA1/vrBFhFfoSYM4+M775V9 RIXfoAJ+i/OOdDWUjWYiw7omds9W7AhVXPlXlumi6U/1ChUipOZ8aZB5Z1kUhhOUjBX3 Ln614d/E2q5RjtrwXKURPrZxEGsClsT3VAlgrmEawQnZ9mA5wsJXmduMLpqnNLIDES7u jvYC6NdYvM77rJq0c/GowvDyUDg48b1G9f+yVtGGxVbFLTcZVFVzpn85e5uHEXWCsH9p cMPA==
X-Gm-Message-State: AGi0PuYLXs1I+MqQmgJuuuDrpl8Lfyz72J0ve/bXpfeEfdYJ/P+kkKQ4 10Xr85S0YETtAohd2Xv6y8SBM/fvP2MJWSFKb0+k7Gp4Kxk=
X-Google-Smtp-Source: APiQypI0Q7UdXs8fETPFRROJaS/xk5bwyHvoWYf5CtamOVuf6LGrn9XWW5kBQXRmEVgVMdS2pdNTZqZVQedeQKGsdR8=
X-Received: by 2002:a2e:87d3:: with SMTP id v19mr6423814ljj.176.1587754470039; Fri, 24 Apr 2020 11:54:30 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Fri, 24 Apr 2020 11:53:53 -0700
Message-ID: <>
To: Paul Hoffman <>
Cc: Ben Schwartz <>, ADD Mailing list <>
Content-Type: multipart/alternative; boundary="0000000000002d812e05a40de56f"
Archived-At: <>
Subject: Re: [Add] [Ext] Drafts on upgrading stub-to-resolver communication to encrypted
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: Fri, 24 Apr 2020 18:54:36 -0000

On Fri, Apr 24, 2020 at 11:40 AM Paul Hoffman <>

> On Apr 24, 2020, at 11:09 AM, Ben Schwartz <bemasc=
>> wrote:
> >
> > Thanks for the updated drafts.  I think RESINFO is the most promising
> path for resolver upgrade, and I'd like to see it implemented.
> >
> > The one major change I suggest is to remove the entire HTTPS mechanism
> from the RESINFO draft.  This mechanism creates a great deal of complexity,
> doesn't follow good practices for HTTPS, and doesn't obviously enable any
> additional use cases.  Having multiple competing mechanisms also makes
> interoperability less likely.
> The additional use case that was brought up in earlier work is that a stub
> that wants to do DoH.
> - It does not need to know how to make requests for a new DNS RRtype
> - It can use HTTPS as it knows it
> - It can get a response that can be authenticated
> I understand the desire not to allow unauthenticated HTTPS because of best
> practices. We can remove that from the draft, but then implementers will
> likely go ahead and implement it anyway but without guidance about the
> results. Note that we are only talking about unauthenticated HTTPS *for
> this one use*, not in general.
> > If "in-band" RESINFO proves insufficient, an HTTPS-based mechanism could
> always be added in a later draft.
> Some people said it was insufficient because of inability to authenticate.

But the HTTPS mechanism is unauthenticated as well. And even if people do
use IP certs, then they mechanism by which they get the IP is largely

I agree with Ben; this  mechanism should be removed.


> --Paul Hoffman--
> Add mailing list