Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative

Puneet Sood <> Sat, 08 August 2020 01:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 906C33A0044 for <>; Fri, 7 Aug 2020 18:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Z-eW5Lnq34Tj for <>; Fri, 7 Aug 2020 18:18:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C6A13A0039 for <>; Fri, 7 Aug 2020 18:18:28 -0700 (PDT)
Received: by with SMTP id r63so912716uar.9 for <>; Fri, 07 Aug 2020 18:18:28 -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:content-transfer-encoding; bh=X6BxIwFSm6YHfu1+jeM57HHSvglbIz0rZAt1kOTyowI=; b=ANp77lFeKoL228KYHGVvm9TkKVWxf0ZxFGYWpVf/TL5chL47H7QjJISJuYbvjIVcOw 4FudIQm0N/HuvhRoE8/LS1npOAsxjh+NqvtIjpsWVPdUp4qpTaq0jw5FyG+KyP+7ngzL BYUYe5hv1b9+wkkZAughJbJnvSPkp4Mbs1cbUO8cWumEMSZghThZlDoXmF/wOuamedAR efFoPAA/huYg7Dd/UxNBmlK/ON92OoFCsgvojbBVtAcHltcN+LpL4qwdFEJ5WNkUgLgG 7sdfls1elTPP5soiAE4VJZrVnpF6Gwhtj+MPiM7PT8FTXlO86vwDTC54ZQXkWdYbmx1p xwsw==
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:content-transfer-encoding; bh=X6BxIwFSm6YHfu1+jeM57HHSvglbIz0rZAt1kOTyowI=; b=k87HhIQyNOW7r0eLVvtcZ712H6FqHlMMoqlBJ/LkLyGsFo/akUuXGUWF/Id/mhvAqg ku/VxltJAHQhteoJhfU90J89uCV4RW2SDrvJq4n4zHEY8XZ3z5jQuQ1Y8kB0/z6sXctW 29MooohGQe3Y0nf8bCmd2fOrtO1p52y19izXfTEsk3HNBSCZbzcyGqwun/L8MlcCUD7C Tb4f0WcDB2r2ItBYsNRE/lXCOSMfzsEiXApD9qfgLBMjq9H71T4OvaDztIB2b69M+4EJ xd1cKaKopIl4lVUqg17ylsgTqjPT7XtyIDM5dfCvVp9/oBv2DHmVLuy2Hbt1bPF/J+va miiA==
X-Gm-Message-State: AOAM531bGruwIwe0/ZiF99yy29vcs38fYc3fmhsqqO/qUEe9gIjPI3Uo Go+lOF1G+66Z43wX5Ca0NIluw1RbicdYyc3Ogfh98A==
X-Google-Smtp-Source: ABdhPJxmbzDgWNcziNa+1ot4MWV5ZzdoLZqSAtXsi50GI5IqyND03+qJHuZBoCKXm3CFYUZVtCZzYJeTPC8KfHvuiro=
X-Received: by 2002:a9f:3e9b:: with SMTP id x27mr12903928uai.24.1596849507660; Fri, 07 Aug 2020 18:18:27 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Puneet Sood <>
Date: Fri, 07 Aug 2020 21:18:16 -0400
Message-ID: <>
To: Paul Hoffman <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Aug 2020 01:18:31 -0000

I think this is worth doing.


On Thu, Aug 6, 2020 at 10:59 AM Paul Hoffman <> wrote:
> Greetings again. The following is a short text-based version of my slides from last week's WG meeting. I'd like to find out if this is one of the use cases that the WG would be interested in dealing with.
> Use case: Opportunistic encryption for recursive to authoritative
> In this use case, a resolver operator says “I’m happy to use encryption with the authoritative servers if it doesn’t slow down getting answers by much”, and an authoritative server says “I’m happy to use encryption with the recursive resolvers if it doesn’t cost me much”.
> Opportunistic encryption is defined in RFC 7535. From the abstract: "Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet."
> The assumptions behind the use case are:
> • More encryption is good for the Internet
> • Resolver vendors are smart and motivated
> • Most resolvers don’t validate with DNSSEC and may never want to
> • Authoritative operators don’t care much about encryption, but some would turn it on because more encryption is good for the Internet
> • Other use cases for authentication stronger than opportunistic may appear and would co-exist with this one
> The other slides had thoughts about possible solutions that implement this use case, but before we go there, I wanted to find out if more than a handful of people here are interested in this use case. If so, I could turn the above into a draft with some possible solutions for us to bang on.
> --Paul Hoffman
> _______________________________________________
> dns-privacy mailing list