[dns-privacy] Opportunistic encryption between recursive and authoritative servers

Paul Hoffman <paul.hoffman@icann.org> Fri, 11 September 2020 20:38 UTC

Return-Path: <paul.hoffman@icann.org>
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 0CD183A09A8 for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 13:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 CRzJOULQY09Y for <dns-privacy@ietfa.amsl.com>; Fri, 11 Sep 2020 13:38:38 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 E53783A09EC for <dprive@ietf.org>; Fri, 11 Sep 2020 13:38:37 -0700 (PDT)
Received: from MBX112-W2-CO-2.pexch112.icann.org (out.mail.icann.org [64.78.33.6]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 08BKcb6L015311 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dprive@ietf.org>; Fri, 11 Sep 2020 20:38:37 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.659.4; Fri, 11 Sep 2020 13:38:36 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0659.006; Fri, 11 Sep 2020 13:38:36 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: "dprive@ietf.org" <dprive@ietf.org>
Thread-Topic: Opportunistic encryption between recursive and authoritative servers
Thread-Index: AQHWiHuF7ZKjnZh370eSgPYkwg25PA==
Date: Fri, 11 Sep 2020 20:38:36 +0000
Message-ID: <BBA7E731-34C9-47C8-B584-7781DD7F4A59@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_6F4AE847-84FE-47C0-B501-76A248FCE5BE"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-11_10:2020-09-10, 2020-09-11 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/RuFGY_YSZ3gLitHCyzAqJyHyk4U>
Subject: [dns-privacy] Opportunistic encryption between recursive and authoritative servers
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: Fri, 11 Sep 2020 20:38:47 -0000

Greetings. The discussion of encrypting the recursive to authoritative traffic keeps getting bogged down due to lack of use cases. Puneet and I would like to propose a specific use case (the desire to encrypt much more traffic, even if there could be an active attacker in the middle). With that in mind, we wrote up <https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic>. The abstract says:
  This document describes a method for a DNS recursive resolver to use
  opportunistic encryption when communicating with authoritative
  servers.  The method here is optional for both the recursive resolver
  and the authoritative server.  A motivating use case for this method
  is that more encryption on the Internet is better, and opportunistic
  encryption is better than no encryption at all.  Nothing in this
  method prevents use cases that require better encryption.

We would like DPRIVE to adopt this, and we are open to suggestions on how to improve the protocol.

--Paul Hoffman