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

Ben Schwartz <bemasc@google.com> Wed, 23 October 2019 20:53 UTC

Return-Path: <bemasc@google.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 2FCDC120103 for <tls@ietfa.amsl.com>; Wed, 23 Oct 2019 13:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 OHpC5H1mySgn for <tls@ietfa.amsl.com>; Wed, 23 Oct 2019 13:53:10 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF10A1200EC for <tls@ietf.org>; Wed, 23 Oct 2019 13:53:10 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id c6so26647986ioo.13 for <tls@ietf.org>; Wed, 23 Oct 2019 13:53:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/HYljioP/BKxBa0qgmnZnTfkYuT/Cyql1GQHIv9/wU0=; b=FiCZgEvSO6cvO8nDLLlR2pB4YDYbxU4M1QmyTEp10htWtkZ2A+lAj1naDSx/haT94a i+QUx9H4Xa7LgV46RLrnR121IiWeixgKrrhFGlPQBq2CP3ZAUcQONCZeG1S/hHWVubyZ /+CP8bQTalPse7sAIBQb7kFUx2/O8LvHXuG6HuHQC5Sf1hto5GZWIMd3QM0HNYdOGY/H 8SgWvJW8cPQTa/1wX6SsSFsLpk4j8DC/JEZcWZ2ccnxaQlKLByMxy8TZiJ2v+7p/SV8F 3NKhHHI3FYsLHrcNg0GYJulJ0bOJDtAGnWEKnW3Y71zRQj8pqOLfzSarb+dQdv/unfws C5Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/HYljioP/BKxBa0qgmnZnTfkYuT/Cyql1GQHIv9/wU0=; b=UkYF7SPBvXUKFTN4jtsHBexSmEPezTLEd4YRDj4rp0p3jnTu8hgmaMegqIM+KqPapk fdipnQiElFWAcmZKaI7pBAFqRR5mVAKLWH3mtLiRk8ZIn2akeEP5kDzAZN2lJN9YY2hj HV4kSV14SkXjT2JgNBRlCYVXhKdUjPlXR7wbnTH7vP8j+hJixPBsy9usqAbC1ct8hjEJ ueFynSpSt/LiOvBkD8kgDnZpgDivULjnEljR30MbkE5smQx3erJG5tJk3++Aog/oC78o v5z/t+IEqhNC/9R3LIisaOJtzy8ShAywElg/1yprecKBlr28mi5e0MGDS3zY3DITwwVD aPIw==
X-Gm-Message-State: APjAAAVLs+0xv6LCwgS7pnlxnzAN9i49oglyBZJ+7xd8fepeoVz3BdC2 pvNB495Xd85lCs7GlDw3VfJLMpwgiDolmnizDBq0rg==
X-Google-Smtp-Source: APXvYqw0LPipT8xgE20S0qOuL1vmAT/f88LSn8IskP+KZ6mZlANDotXZ1eSwlOGsHPCs+SXgxYWzneVek5jB1ul+x6s=
X-Received: by 2002:a6b:7a4a:: with SMTP id k10mr5437493iop.193.1571863989560; Wed, 23 Oct 2019 13:53:09 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <20191023171113.GA472177@LK-Perkele-VII>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 23 Oct 2019 16:52:57 -0400
Message-ID: <CAHbrMsAYckzTV19vY2qG+zoLDT-xr_YMN=bDB8NnT4UPQBbH=A@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, TLS List <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c62a7905959a1a10"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/v30m-SDs9XJrKtjAwcYKdWH-sIU>
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: Wed, 23 Oct 2019 20:53:13 -0000

On Wed, Oct 23, 2019 at 1:11 PM Ilari Liusvaara
<ilariliusvaara@welho.com>; wrote:
>
> On Wed, Oct 23, 2019 at 12:13:39PM -0400, Ben Schwartz wrote:
> > On the topic of radical suggestions, here's another one:
> > https://github.com/tlswg/draft-ietf-tls-esni/pull/186
> >
> > In brief, this replaces the variable-length name with a fixed-length
> > hash, plus some accommodations to allow *.example.com,
> > *.*.example.com, etc.
> >
> > My hope is that this design would work in the architecture described
> > by Watson, while saving ~220 bytes in each ClientHello.
> >
> > One interesting feature of this design is that it doesn't require each
> > wildcard domain to publish any unique DNS record.  Instead, all
> > third-level wildcard customers can share a configuration, all
> > fourth-level wildcard customers can share a configuration, etc.  This
> > distinction is not visible in the TLS handshake, so the anonymity set
> > is not reduced.
>
> AFAIK, PKIX in practice only allows single full-label wildcard in
> terminal position (the only place * can appear is as first character,
> followed by label separator).
>
>
> And the scheme in #186 does not seem to distinguish between
> "example.org" (the base name) and "*.example.org" (a wildcard).

It does, with num_labels in the ClientESNIInner.

> There also seems to be issue that seemingly nothing constrains the case
> of hashed encoding. And you do not want to deal with arbitrary casings,
> as the number of those quickly blows up.
>
>
> 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.

> Alphabet would be hashed lowercased. Then
> the server could just hash every lowercased name from every known
> certificate and use the hashes as lookup table keys without worrying
> about encoding. And in the structure, the label_limit, num_labels and
> length field for name_digest seem to be superfluous.
>
> This would give that the encrypted_sni is 64 octets with AES-128 or
> Chacha20, and 80 octets with AES-256.
>
> On optimizing stuff, the length fields for record_digest and
> encrypted_sni in client structure are also superfluous, because the
> length of record_digest is impiled by suite (and unknown suites are
> unprocessable anyway) and encrypted_sni runs to end of explicit-length
> record. The length of key share probably can not be removed, as some
> algorithms may have variable-length ciphertexts.
>
> Using the above figures, this would mean that the part after the
> share would be 96 octets for AES-128 and Chacha20 and 128 octets for
> AES-256.
>
>
> -Ilari