IETF Logo Mail Archive

Re: [TLS] Encrypted SNI

Paul Wouters <paul@nohats.ca> Wed, 04 July 2018 03:31 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 A18FC130934 for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 20:31:38 -0700 (PDT)
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 3y3Pft2gyGMG for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 20:31:36 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 D2879130E69 for <tls@ietf.org>; Tue, 3 Jul 2018 20:31:35 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41L63R4pvJz1km for <tls@ietf.org>; Wed, 4 Jul 2018 05:31:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530675091; bh=PXPFtcadBv2zaaig/kZRFG09JjIUChSNe0ksjA4njLs=; h=Date:From:To:Subject:In-Reply-To:References; b=ZlyLXWmTmz2TXwE8rbJjCG23tQy1pqndr3Am57ETzIVjqH6Avi0TU6v/65/obr9Tz zPSaUynAKyRgmu8zuVYEmAPmsCFU9SIZ6BIeszG8QsmYuFl/H+kPPATV6L5gWsfDWn YaFbOjBDksJgX7nsifvaSL5zTexR+97aZ2wzyf7Y=
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 6c4mAdkrPRsP for <tls@ietf.org>; Wed, 4 Jul 2018 05:31:30 +0200 (CEST)
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>; Wed, 4 Jul 2018 05:31:29 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6896B62E80D; Tue, 3 Jul 2018 23:31:28 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6896B62E80D
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6101D457B314 for <tls@ietf.org>; Tue, 3 Jul 2018 23:31:28 -0400 (EDT)
Date: Tue, 03 Jul 2018 23:31:28 -0400
From: Paul Wouters <paul@nohats.ca>
To: tls@ietf.org
In-Reply-To: <CABcZeBPee4dVZBdgcTvT-vuzudnXcx_fW6aDdLTV_J5Z+HYX0w@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1807032324330.30506@bofh.nohats.ca>
References: <F4966CAA-454B-4152-A9E5-EA9714978CEA@gmail.com> <CABcZeBPee4dVZBdgcTvT-vuzudnXcx_fW6aDdLTV_J5Z+HYX0w@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/nAb2-BbIzWj9VKTUdspNGos5zUs>
Subject: Re: [TLS] Encrypted SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 03:31:39 -0000

On Tue, 3 Jul 2018, Eric Rescorla wrote:

> but in this particular case, can't enterprise just strip ESNI records from DNS?

Not if endnodes within the enterprise also use DNSSEC. Unless you want
the enterprise to run authoritative fake DNSSEC for the entire world.

It also requires installing internal trust anchors, which is something
you pushed back hard on with draft-ietf-ipsecme-split-dns

One way this could be done is if draft-ietf-dnsop-dns-rpz finally goes
RFC, so IETF gains change control of a bis document, where we define the
filtering to move the filtered record from the additional to the authority
section, so the filtering can be detected yet DNSSEC verified.  But it
seems draft-ietf-dnsop-dns-rpz is being kept in draft state forever,
which basically prevents us from fixing this.

Paul
ps. also note stripping a ESNI RRTYPE is easier than stripping _some_
TXT records :)

v2.27.8 | Report a Bug | By Email | System Status