Re: [TLS] Alternative ESNI?

Paul Wouters <paul@nohats.ca> Sun, 16 December 2018 19:45 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2041912958B for <tls@ietfa.amsl.com>; Sun, 16 Dec 2018 11:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 hdGEq90P23my for <tls@ietfa.amsl.com>; Sun, 16 Dec 2018 11:45:10 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 9CB9A1292F1 for <tls@ietf.org>; Sun, 16 Dec 2018 11:45:10 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43Hvrb6R01zKDq for <tls@ietf.org>; Sun, 16 Dec 2018 20:45:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1544989503; bh=LbXQ6XxK4MTNcGLyUL+Q1HSa6MZHkJQI0TxYMdWwJ6U=; h=Date:From:To:Subject:In-Reply-To:References; b=ZXGo54U9MZafDGPUkEbnx99qrfQIIlWzcldPELcXCgNZt7ZheVAC9VTlM71hscu+M cy3vbC8m9p2WAD60YkkWm1fJzD704tiaILdf5ie7PUHnogbHj9mNPbaGSoafxPAUBS eppJJjj/0HDLP5ZnvXySZdIcp46ZLxHuXa7itExo=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id A0qkfYr91VC2 for <tls@ietf.org>; Sun, 16 Dec 2018 20:45:02 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <tls@ietf.org>; Sun, 16 Dec 2018 20:45:01 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id C190131940C; Sun, 16 Dec 2018 14:45:00 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C190131940C
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B6AF6418762D for <tls@ietf.org>; Sun, 16 Dec 2018 14:45:00 -0500 (EST)
Date: Sun, 16 Dec 2018 14:45:00 -0500
From: Paul Wouters <paul@nohats.ca>
To: tls@ietf.org
In-Reply-To: <CABcZeBM_7LF-UDH8NR3Kad-8zSJBWwuNsDEJVAagHf1cV4Ow6g@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1812161439170.14874@bofh.nohats.ca>
References: <20181215025346.GJ15561@localhost> <CABcZeBM_7LF-UDH8NR3Kad-8zSJBWwuNsDEJVAagHf1cV4Ow6g@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qFE6cT2C-xLSA5zT8hvw8E_5stc>
Subject: Re: [TLS] Alternative ESNI?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Dec 2018 19:45:13 -0000

On Fri, 14 Dec 2018, Eric Rescorla wrote:

> However, in a large number of cases (e.g., an attacker on your local network,
> there are non-DNSSEC ways of obtaining this property, such as using DoH.

Data origin authenticity is not the same as transport security.

DoH offers no guarantee that the non-dnssec protected information you
received is not modified.

Unfortunately, I keep needing to say this on various IETF lists. The
move towards "blindly trusting DNS over HTTPS/TLS" servers is misguided
and just moving the goal post. It is very concerning now that we see
browser vendors to start moving DNS from the endpoint to trusted
servers elsewhere on the internet under the control of very few, mostly
US based, for profit entities.

Paul