Re: [TLS] DNS-based Encrypted SNI

Paul Wouters <> Tue, 03 July 2018 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E72FD130FB7 for <>; Tue, 3 Jul 2018 08:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ogsZmKo55qbp for <>; Tue, 3 Jul 2018 08:41:03 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7583F130F75 for <>; Tue, 3 Jul 2018 08:41:03 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 41KpHd3wrlzCqj; Tue, 3 Jul 2018 17:41:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1530632461; bh=1gZwU97IHQ/lb5a953PrCGgSYlnOeTnQ/a9dAcWcN0E=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gjNH9oGycnEDf6HlV7zOXuo+5KA7kauoBBR3aYGl4moEVP9pCXYf+4EdlLXTQZ9rJ o6ubJ6n/vpB1mFjbNdtqRZV5DamfJrSm/sRFZt9mljB3iJ4MnIoNTWsn1uLmflq2e3 ueMfczlAJsruEVhaDvczJhrCpaH29Nm3WdnGh/RE=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LVNEQ4y-MBm2; Tue, 3 Jul 2018 17:41:00 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Tue, 3 Jul 2018 17:40:59 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 7EE2A3A3EC1; Tue, 3 Jul 2018 11:40:58 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 7EE2A3A3EC1
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7686645755C2; Tue, 3 Jul 2018 11:40:58 -0400 (EDT)
Date: Tue, 03 Jul 2018 11:40:58 -0400
From: Paul Wouters <>
To: Eric Rescorla <>
cc: "<>" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
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: <>
Subject: Re: [TLS] DNS-based Encrypted SNI
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jul 2018 15:41:13 -0000

On Mon, 2 Jul 2018, Eric Rescorla wrote:

>       It is strongly recommended not to use TXT records. Why not use a new
>       RRTYPE? Everything these days knows how to serve unknown record types
>       (see RFC 3597). The only possibly exception is provisioning tools of
>       small players, but this document starts of saying you basically need
>       to be on a bulk hosting provider anyway. They can properly provision.
> See:

[Can we keep the discussion within the IETF and the Note Well please. We
  also don't know what happens in 10 years with these links.]

quoting from that link:

 	These facts lead to the conclusion that if we choose RRtype as the
 	method, there would often be cases where the DNS record of the ESNIKey
 	and the TLS server would be required to be operated by different

That seems to have confused two things with each other. I did not say
anything about the location of the DNS record, only of the RRTYPE.
Clearly, with the same location, it would be under control of the same
entity, so I don't understand why you bring this up as a reason against
using a dedicated RRTYPE.

Here is another argument against it, besides the generic IETF policy of
trying to not overload things or create kitchen sinks. If you used, or
were forced to use, a DNS under control of someone who can block things,
they might be instructed to block anything related to encrypted SNI,
and they might decide to just block all TXT records, even unrelated
ones, resulting in collateral damage.