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

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 25 October 2019 15:54 UTC

Return-Path: <ilariliusvaara@welho.com>
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 9555F120219 for <tls@ietfa.amsl.com>; Fri, 25 Oct 2019 08:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 yqvHZHCY9Mjk for <tls@ietfa.amsl.com>; Fri, 25 Oct 2019 08:54:12 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDED120105 for <tls@ietf.org>; Fri, 25 Oct 2019 08:54:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 88F3445BEF; Fri, 25 Oct 2019 18:54:10 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id JWeTGMPpa-6q; Fri, 25 Oct 2019 18:54:10 +0300 (EEST)
Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A59107A; Fri, 25 Oct 2019 18:54:06 +0300 (EEST)
Date: Fri, 25 Oct 2019 18:54:06 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, TLS List <tls@ietf.org>
Message-ID: <20191025155406.GA526068@LK-Perkele-VII>
References: <CAChr6SwM0cAH4ShJdw6WpV3rwLUPoaqB+imvv61XohLaLiS7jA@mail.gmail.com> <r480Ps-10146i-D05F1D3FC7BC4B899AE60F28D44FDF74@Williams-MacBook-Pro.local> <CACsn0cmhJ5yhZ7h7skgJLdbH9ykcOw6_9D+h7hx8Y8YE69nMaA@mail.gmail.com> <CAHbrMsAFh6g+hAMcjmDqQ=JEv+PDQQaygTfBnHgwepaNJkZtSA@mail.gmail.com> <20191023171113.GA472177@LK-Perkele-VII> <CAHbrMsAYckzTV19vY2qG+zoLDT-xr_YMN=bDB8NnT4UPQBbH=A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAHbrMsAYckzTV19vY2qG+zoLDT-xr_YMN=bDB8NnT4UPQBbH=A@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tcqHLw1H4_xptVFoIWBu8sqStMc>
Subject: Re: [TLS] draft-ietf-tls-esni feedback
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: Fri, 25 Oct 2019 15:54:15 -0000

On Wed, Oct 23, 2019 at 04:52:57PM -0400, Ben Schwartz wrote:
> On Wed, Oct 23, 2019 at 1:11 PM Ilari Liusvaara
> >
> > Perhaps a simpler way would be to have a flag that causes the first
> > label to be overwritten with '*'. That would be set on nodes covered
> > by a wildcard certificate.
> 
> This is a reasonable simplification.  It would also work nicely
> without the hashing, for servers that only have reasonably-sized names
> but can't make promises about wildcards.  However, it does still
> suffer from the configuration brittleness described by David Benjamin
> in #186.

I think all mechanisms that transmit only a single hash need to know
if some node is covered by exact name or a wildcard.

And wildcard expansion is at worst 63 bytes, due to DNS limitations,
so transmitting full first label and 32 octet hash of rest would take
96 octets (if one can assume host character set, that could be fit into
80 octets with some encoding).

Then if one had two hashes, one could fit those to 64 bytes (or 48 if
one truncated the hashes to 192 bits, as scope of uniqueness is just a
single server). This would not depend on knowing if node is wildcard or
not.


-Ilari