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

"John R. Levine" <johnl@iecc.com> Thu, 06 August 2020 19:45 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C670D3A0E45 for <dns-privacy@ietfa.amsl.com>; Thu, 6 Aug 2020 12:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com
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 Kt_6NDvI1D00 for <dns-privacy@ietfa.amsl.com>; Thu, 6 Aug 2020 12:45:02 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 ABC633A0E44 for <dprive@ietf.org>; Thu, 6 Aug 2020 12:45:01 -0700 (PDT)
Received: (qmail 19668 invoked from network); 6 Aug 2020 19:44:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=4cd1.5f2c5dbb.k2008; i=johnl-iecc.com@submit.iecc.com; bh=Ee1tAaHZpaxo7IMw9Al9ohXYcU66js7bInGZ2Ef7hRQ=; b=uxjKHuxpxAMqrzko3fvrRFUxIC1csKVoJ+HX6YJuM7fZxtj7p7SpvfN4yl+K3Vo/cRLSBfekPAhsm7z2QMX/bcQY7A+gbxOJW9HOJn/Fg01y44O/MtiIolLLdOuhDlCg1DIB5dByKpf/VC7MBfEL1+/13HQt575jiMxbnvKzH7h6yAmNMk1ESaRm9pYXGsy1Vym5NWaoXkLrIddxJbPUIgu9n+Mh6iEo8LHpNSFuzUuJCQA119q5WS+Sgjg1146hn6wkuYv0ZaPAzFyWu3LAvlLocV1C0fQc/2v598obGTFNZcYv+Hrye4Ro8c6lTc+FLiUynfw/NZ7qlpfFK9QCEw==
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 06 Aug 2020 19:44:59 -0000
Date: Thu, 06 Aug 2020 15:44:58 -0400
Message-ID: <8d295fe-f183-e13d-d619-2b847e4e2293@iecc.com>
From: "John R. Levine" <johnl@iecc.com>
To: Paul Hoffman <paul.hoffman@icann.org>, "dprive@ietf.org" <dprive@ietf.org>
In-Reply-To: <3BA75997-3DE4-4DF5-B1F5-C57DBC423288@icann.org>
References: <3BA75997-3DE4-4DF5-B1F5-C57DBC423288@icann.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1599479388-1596743099=:22026"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/FLDHiDGSqRxEfeSIC5jSPFv4s9o>
Subject: Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2020 19:45:04 -0000

Yes, this is worth doing.  Agree with comments that it has to be 
compatible with non-opportunistic encryption.

R's,
John

PS: RFC 7435.

> 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
>
>

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly