Re: [TLS] draft-ietf-tls-esni feedback

Bill Frantz <> Wed, 23 October 2019 14:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B31612081C for <>; Wed, 23 Oct 2019 07:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U50H85B0pHE2 for <>; Wed, 23 Oct 2019 07:34:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA19C1200E6 for <>; Wed, 23 Oct 2019 07:34:58 -0700 (PDT)
Received: from [] (helo=Williams-MacBook-Pro.local) by with esmtpa (Exim 4) (envelope-from <>) id 1iNHiz-000AHf-AE for; Wed, 23 Oct 2019 10:34:57 -0400
Date: Wed, 23 Oct 2019 10:34:57 -0400
From: Bill Frantz <>
X-Priority: 3
In-Reply-To: <>
Message-ID: <r480Ps-10146i-D05F1D3FC7BC4B899AE60F28D44FDF74@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.4.3 (480)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79d624e5df46477f8e56db7733a77c628c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-esni feedback
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Oct 2019 14:35:00 -0000

A perhaps radical suggestion:

Make the server name field fixed length e.g. 256 bytes. Longer 
server names are not supported and clients MUST NOT send them. 
(Both client and server can't use them because they won't fit in 
the fixed length field.)

Putting a limitation like this one into a protocol certainly can 
create problems, but we can look to the file system name 
situation for some insight. In the dark ages, file names were 
limited to a small number of characters -- 4, 5, or 6. I 
remember when the file system I used increased the limit to 8 
characters, seeming like infinity for a few days. Finally some 
file systems raised the limit to 256 characters and I stopped 
hearing complaints that the length limit was a problem.

With the suggestion, DNS lookups are padded to allow all 255 
byte names to be represented in what is, in effect, a fixed 
length lookup string.

Now people with more information about the problem can describe 
the problems this suggestion would cause.

Cheers - Bill

Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 
Englewood Ave | buffer overruns.             | Los Gatos, 
CA 95032