[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
- [dns-privacy] Opportunistic encryption between re… Paul Hoffman
- Re: [dns-privacy] Opportunistic encryption betwee… Paul Wouters
- Re: [dns-privacy] [Ext] Opportunistic encryption … Paul Hoffman
- Re: [dns-privacy] [Ext] Opportunistic encryption … Paul Wouters
- [dns-privacy] Fwd: Opportunistic encryption betwe… James
- Re: [dns-privacy] [Ext] Fwd: Opportunistic encryp… Paul Hoffman
- Re: [dns-privacy] [Ext] Opportunistic encryption … Geoff Huston
- Re: [dns-privacy] [Ext] Fwd: Opportunistic encryp… Eric Rescorla
- Re: [dns-privacy] [Ext] Opportunistic encryption … Brian Hartvigsen (bhartvig)