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

Eric Rescorla <ekr@rtfm.com> Mon, 21 October 2019 20:56 UTC

Return-Path: <ekr@rtfm.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 7E68912090B for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 13:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 nWw-WiLGdetr for <tls@ietfa.amsl.com>; Mon, 21 Oct 2019 13:56:18 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 8332512001A for <tls@ietf.org>; Mon, 21 Oct 2019 13:56:18 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id 195so11235999lfj.6 for <tls@ietf.org>; Mon, 21 Oct 2019 13:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B4/cg+mfbnsuUYaj15Yvao2b/WYm8txvOTazZVprAXw=; b=B0CeqvPzSd4O0UjztxQhlcnG/5e5UMvMs/Fjcky8CnDyaHLd7roZszT4SpKZ5+mBeV 8eusoWFXESP6WXb3LTYs3APqHDVptqJ+ab5cCbLa5QVh4PyYGsqAU1wGbM4Y0yJpaOgq qBs57AEbiVnw1n/aKPg3hVz7WtMEFVWGGDr5UQ6CVTGaQx5WWrFthnSNIX5iJlMTSdhZ HErcsNqHbKgBSwIgRkv9TY3TBhWpspc1rmtXoexac1S2xR9Nn2ofaEUgfx7hcyO4dAaQ R/44kxY4+kI/ItUKUZC6TEVS25mMyJOIz+yYYhbguxOK7i2rPnOIYLPbEEcocpFMsMna Hoyw==
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=B4/cg+mfbnsuUYaj15Yvao2b/WYm8txvOTazZVprAXw=; b=M4YCGdR3DoZKA4rtrzhWRWEeWM04RFfDVP49Pcn28YnXUn5W8YH35PGwsYQPt3nLul EspErqnb0QfDbUbehJX4L1znfjUzILbM96LJ2BKnGFqvMbJOXbkyNItjmauD6fw0zv6s e7mIYRVqE6+BoXuYA4zPeIHw0OU6WwcGH+xfQNk32nEt0aK8MpLjqSyQN+3wz7OyU+y7 n/LdfeZMENLKEI3FVJPvYo/wR+Se20Rm6Xq6w/lsD8sC6KqDWYoOoCeXsqlZsmU2F6Go u0/C5a72I+FBlcf26ww99hoAQEZfmDno0Tos7w2e6R+hlIRZvG5MJp6qMqvcJzcvt9rf FLPQ==
X-Gm-Message-State: APjAAAU86H89+vV5ps6X1atcs4w2Rf2El3iNdDwowUbsxJ1CFiIlMAyu xaI63vwA+Dy5NvulK1HiLe87+nHf5lMLEj5KupriHA==
X-Google-Smtp-Source: APXvYqzeRbozvpVPryaYt28pz0oO4kSs0Vrq+gnOsi6nwQdQiM00gy8LAp59xe1XFiXA0gZ1QdY22qADXMdH+DEl5Hc=
X-Received: by 2002:a19:8196:: with SMTP id c144mr5183114lfd.129.1571691376591; Mon, 21 Oct 2019 13:56:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6Sw3f7du3JYxfcWSZje1zjDzsRBQyDjob-AvzjWeZzKW7g@mail.gmail.com> <CABcZeBPbw_KOo_ieSqkksYPeLtb9DufBz628oFPYc_Ue4S9iww@mail.gmail.com> <CAChr6SwB+7Jt2TLJSQh3q=Roizdt2=9jCBa9nq8KRxRo=86uZQ@mail.gmail.com> <CABcZeBNBtDK7q175tseEUiCVds=khj4xXYJZRf7GU9VGNDJ_Tg@mail.gmail.com> <CAChr6Sz6xHtFWjOKrLp3sp9MpC-SoU9Sx=vk22ditjShA7B=Kg@mail.gmail.com> <CABcZeBOnE+gyNu7GarAfO0bptoPfzQQ=VKeWLdpJBDM=E4yhzg@mail.gmail.com> <CAChr6SxWE66jPRbnBRtwNSn3L+uNFkoFBbYNOBAkKDN05qotoA@mail.gmail.com> <CABcZeBOy8ogJrmFajxX1pqjqgnE61gE=c3CWz+pp34NWHmGKbw@mail.gmail.com> <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <CABcZeBMquubsGvt8UssiyFU_ZuQK67rHN_KBXY+iKSNayJFZew@mail.gmail.com> <d9402fe2-2ab3-f60f-c478-dc1df5bd4402@cs.tcd.ie> <CABcZeBNC9YBGMs0b84DFDB-FU7fKXpzX+HP1H5KRcjYJ7kXr3w@mail.gmail.com> <c7ada021-1ccf-1dc5-d7e3-a5f893f116ee@cs.tcd.ie>
In-Reply-To: <c7ada021-1ccf-1dc5-d7e3-a5f893f116ee@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 21 Oct 2019 13:55:40 -0700
Message-ID: <CABcZeBO09MKms7tG40NDy-wRz26eXzKvyJqSYK1K5fEJBzcE3Q@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Rob Sayre <sayrer@gmail.com>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000032d9a6059571ea00"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TrBnUq5RL3Z3d5elMdBLwBKxhQg>
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: Mon, 21 Oct 2019 20:56:21 -0000

On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

>
> Hiya,
>
> On 21/10/2019 21:02, Eric Rescorla wrote:
> >> Sure, but the point holds though. If ESNIKeys are changed every
> >> N seconds, and any new certificate is loaded during that time,
> >> then the server operator can't tell the lengths that the CAs
> >> might produce in future. So with the current design 260-always is
> >> the only thing a server-operator (or really an ESNIKeys generator
> >> who may be a slightly different entity) can rely on in general.
> >>
> > I don't believe that this claim is correct in general. Remember that
> these
> > records are stored in the DNS under the name that becomes the SNI, so,
> > absent wildcards, ths eet of names is in fact known, regardless of what
> > happens to be in the certificate.
>
> Depends which "in general" is more general I guess.
>
> Wildcards do exist in the DNS, though TBH I'm not really
> familiar with how they're implemented in authoritatives.
>
> But even ignoring those, deployment models where the
> ESNIKeys are generated by the TLS server operator, but
> DNS records are published by a different entity (say the
> owner of the name or registrar) ought not be precluded
> I think. Supporting such a model I think more or less
> requires setting padding_length to 260 or else risking
> a failure nobody will notice (if browsers fall back to
> cleartext SNI) or know how to diagnose if they do.
>
> And even in the case of a monolithic service that does it
> all for every name, I think it'd still likely pick 260
> in order to avoid having to exercise/write the code to
> detect and react to a need to increase the padding_length.
>

Fortunately, we have a number of such operators on this list. Alessandro?
McManus? Nygren, What say you?

-Ekr



("Holy crap - you mean I need to re-publish everyone's
> ESNIKeys just because this bozo has a really long name?
> Who made that up?")
>
> I really can't see what'd motivate anyone to publish
> ESNIKeys with a padding_length < 260 tbh (well, other
> than not having thought it through;-). Anything <260
> just seems to be asking for later problems.
>
> S.
>
>
>