IETF Logo Mail Archive

Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH

Stephane Bortzmeyer <bortzmeyer@nic.fr> Tue, 05 November 2019 10:45 UTC

Return-Path: <bortzmeyer@nic.fr>
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 1C34F1208C8 for <dns-privacy@ietfa.amsl.com>; Tue, 5 Nov 2019 02:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 pl7io_PsQk43 for <dns-privacy@ietfa.amsl.com>; Tue, 5 Nov 2019 02:44:58 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 B24061208A9 for <dns-privacy@ietf.org>; Tue, 5 Nov 2019 02:44:58 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D8CF228011C; Tue, 5 Nov 2019 11:44:55 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id D2A4D280612; Tue, 5 Nov 2019 11:44:55 +0100 (CET)
Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id CAA4828011C; Tue, 5 Nov 2019 11:44:55 +0100 (CET)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id C4F80663E720; Tue, 5 Nov 2019 11:44:55 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id B80A543CCB; Tue, 5 Nov 2019 11:44:55 +0100 (CET)
Date: Tue, 05 Nov 2019 11:44:55 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Tommy Pauly <tpauly@apple.com>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, dns-privacy@ietf.org
Message-ID: <20191105104455.GA6501@nic.fr>
References: <F835A0C6-19DA-4728-B0B0-59A4C2F4F5F5@apple.com> <A5D68E26-0281-41BC-8709-2DC229647C1A@apple.com> <20191102115720.GA18365@nic.fr> <F6A0B437-444E-49CB-A894-B6AA88DABBA0@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F6A0B437-444E-49CB-A894-B6AA88DABBA0@apple.com>
X-Operating-System: Debian GNU/Linux 10.1
X-Kernel: Linux 4.19.0-6-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Bogosity: No, tests=bogofilter, spamicity=0.000336, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/EW2dAFHgGTZj1OBkAbHExsiGNt0>
Subject: Re: [dns-privacy] Adaptive DNS Privacy and Oblivious DoH
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: Tue, 05 Nov 2019 10:45:01 -0000

On Mon, Nov 04, 2019 at 08:20:05AM -0800,
 Tommy Pauly <tpauly@apple.com> wrote 
 a message of 45 lines which said:

> However, there are a couple reasons we're interested in having DoH
> servers directly support receiving Oblivious queries:

Ok, but these reasons should be put in the draft (may be in an
appendix), to avoid repeated questions.

> Tor is also meant as a generic connection-level anonymity system,
> and thus seems overly complex for the purpose of proxying a
> request/response protocol such as DNS.

On the other hand, it has been well-examined, well-checked and
well-attacked so we know the trust we can put in it. A new
cryptography protocol is always risky.

There have been exactly the same discussion at the beginning of DPRIVE
about the encryption layer for DNS. The proponents of TLS (which won,
and gave RFC 7858) mentioned the fact that TLS was battle-hardened and
well studied, the adversaries preferred a more DNS-friendly protocol,
such as draft-wijngaards-dnsop-confidentialdns.

v2.23.0 | Report a Bug | By Email