Re: [TLS] DNS-based Encrypted SNI

Paul Wouters <paul@nohats.ca> Tue, 03 July 2018 03:53 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 CF870130F03 for <tls@ietfa.amsl.com>; Mon, 2 Jul 2018 20:53:30 -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 iBa3gkw_pCO7 for <tls@ietfa.amsl.com>; Mon, 2 Jul 2018 20:53:28 -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 D8BA9130EED for <tls@ietf.org>; Mon, 2 Jul 2018 20:53:27 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41KVb943Lgz1yF for <tls@ietf.org>; Tue, 3 Jul 2018 05:53:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530590005; bh=O/giRBZ4+PcS2O2sYR0Q9iaRRILhJ51ago+63eL1flU=; h=Date:From:To:Subject:In-Reply-To:References; b=YD8yNbUjI/AefG6u3ndNdXlarVK//50F8cioLJpqluiNrzkM3eqBfGejxAvBykxVX dE/OhuqepG4xwtfE7FQS20lntWXnUG3YVB4Vcw5Gui6KNSZOMK3nYOIXsGWh+dPnfc aW+XI11MhgLFMEATCAiI/it5Ff28J9e20bq0KFOs=
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 p7MsXklBal2W for <tls@ietf.org>; Tue, 3 Jul 2018 05:53:21 +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>; Tue, 3 Jul 2018 05:53:20 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7EAB562A2EF; Mon, 2 Jul 2018 23:53:19 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7EAB562A2EF
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 74B8445755C2 for <tls@ietf.org>; Mon, 2 Jul 2018 23:53:19 -0400 (EDT)
Date: Mon, 2 Jul 2018 23:53:19 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: tls@ietf.org
In-Reply-To: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1807022343380.3445@bofh.nohats.ca>
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/b0DQpCStJ4RSlp7uVXSobS-ssjA>
Subject: Re: [TLS] DNS-based 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: Tue, 03 Jul 2018 03:53:31 -0000

On Mon, 2 Jul 2018, Eric Rescorla wrote:

>   https://tools.ietf.org/html/draft-rescorla-tls-esni-00

> This is at a pretty early stage, so comments, questions, defect
> reports welcome.


 	This structure is placed in the RRData section of a TXT record as a
 	base64-encoded string.  If this encoding exceeds the 255 octet limit
 	of TXT strings, it must be split across multiple concatenated strings
 	as per Section 3.1.3 of [RFC4408].

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.

I need to think more about the document to see if there is really not
something simpler or better possible.

Paul