Re: [TLS] ESNIKeys.public_name vs. cleartext SNI

Ben Schwartz <bemasc@google.com> Mon, 29 July 2019 13:35 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 670A7120124 for <tls@ietfa.amsl.com>; Mon, 29 Jul 2019 06:35:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 UpYIsFoqSZ4i for <tls@ietfa.amsl.com>; Mon, 29 Jul 2019 06:35:34 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 6F8271200F8 for <tls@ietf.org>; Mon, 29 Jul 2019 06:35:34 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id s7so119858019iob.11 for <tls@ietf.org>; Mon, 29 Jul 2019 06:35:34 -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=wwE2c/cEMP1Q1TnWW5bUERC/+sk5tol7F6ZeIhJr2ro=; b=WngTa0TLnXk3CbOEPKlZzwl6pvfBPJFqkNR6f+svwvDRXynik0AuSOzKuVBndteflQ vPctNCZwf2kSQQ9p6nYdf+4yVG04ynuhYyx7gwMLqQd9s6PhteyRygTqrcAcWS2lULdn gTbHNx2U9A4hj3AJGy3HIHmzHMzJWuIFBbv8rDS+WgwV+9GUJKFVe6ORM8V3hu6HW8u3 1C4NR77m9mw90ZzO0q8B7OQSgJ8M3vXHBx4hF6fR0zt3Sqk3X+ZOAA2ZcgcdgSFZiGjk ++lTsOTJ25OYkzXI+dyKlfa+urbD4jJccxuMUZ82qwGTVVFLZJKeInU6i+v7osUnD7Il RR6A==
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=wwE2c/cEMP1Q1TnWW5bUERC/+sk5tol7F6ZeIhJr2ro=; b=KvEWq+eodnKCJF2BfpcsP9xLzAiu0plugYcLzI5O11kW9IPSYWt9tD351/Hw5Ls06p 7MDjjAudFlQ1rLRF5/NlsH1DItgOeY/J7kzaKJqOQmDIQ3DIKc7T1opXwMiKFsXaNG4f hyO2RzmSgRo1FKQBR8AgzGlzM+9cVpELR2emNMyPMiO1uNveKYzHucO2eOAg4FrQTIa3 0tUpyAajuXUouCN8W1I7Sq1tOBAm41AvfXzgh8a0s7zvwB0YPcWuzv5q5LeurAfW7x3H d+DeypNmH96+Oa+Nxh5wp9J9qyB7pch4X0QwyKwsC+OaC/x/rgMDE+uL1o616N9CaT0u 6VQQ==
X-Gm-Message-State: APjAAAW0/ZSExezaLdUJQxqCyckzACjZwWLPXkrdJ4qtJfpf8WcyLUZh BtsUt9+I3Ke50gXJCpObKGnVcmsI1pTxj5HdFVoeE973Ctg=
X-Google-Smtp-Source: APXvYqzmo/6QKDx96gU3W5xgcDM6ruB0f3UDEN/OeLM3P2z8X8F+Ryq4y88GHfOn52pD6XMKG9+Jyn8v7CugQsNL4KU=
X-Received: by 2002:a6b:ed09:: with SMTP id n9mr30430395iog.153.1564407333327; Mon, 29 Jul 2019 06:35:33 -0700 (PDT)
MIME-Version: 1.0
References: <84f41a5a-b543-2fdb-8af0-b923dccd7693@cs.tcd.ie> <05501e58-6d97-c2b6-6e76-bc4c3b2f4579@huitema.net> <2997ba60-6d01-5440-cd3d-66651443253d@cs.tcd.ie>
In-Reply-To: <2997ba60-6d01-5440-cd3d-66651443253d@cs.tcd.ie>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 29 Jul 2019 09:35:21 -0400
Message-ID: <CAHbrMsBjfTccPAD7knZ_cUXd8Qr=oB-X7H90qA3J+rgvy1xjnA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Christian Huitema <huitema@huitema.net>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000006d7350058ed1f798"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JXmJ0p0_zUj_LhXwnRpL_AqagHA>
Subject: Re: [TLS] ESNIKeys.public_name vs. cleartext SNI
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, 29 Jul 2019 13:35:36 -0000

On Mon, Jul 29, 2019 at 7:12 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> Hiya,
>
> On 29/07/2019 01:32, Christian Huitema wrote:
> >
> > On 7/28/2019 5:25 AM, Stephen Farrell wrote:
> >> For example, my openssl build allows this for s_client. I've
> >> a colleague who's got a first build of curl using that that
> >> also allows such a local over-ride. I think other command-line
> >> clients might be likely to also support that kind of thing, if
> >> for no other reason than the existence of the draft-02 version
> >> that's deployed and has no public_name. But I guess being able
> >> to do a local over-ride may also be generally useful, while
> >> not being so useful for web browsers. For example, if a given
> >> public_name value is being censored, clients might at that
> >> point want to use something else.
> >
> > I see the intent, but I am not sure it is practical.
>
> In which case I must've explained it badly, because it's
> entirely practical:-) Let me try again...
>
> What I'm asking is that we not insist that the cleartext
> SNI is the ESNIKeys.public_name even though those will be
> the same value in almost all cases.
>
> I don't think there's any major security benefit to insisting
> that they be the same and there are cases where e.g. a command
> line tool like curl or wget can easily supply a different
> cleartext SNI value as an override, should that ever be needed
> or useful.
>

It sounds like you are arguing for replacing a MUST with a SHOULD.

I think our best option is probably to clarify who is supposed to do what,
and why.  For example, we could say that a compliant client MUST set sni =
public_name so that fallback can work on servers with multiple public
names, but the server MAY accept connections with missing or unrecognized
SNI to enable connections from non-compliant clients that prefer not to
include the public_name.

> A lot of the HTTP
> > connection establishment is automated. Given a server name, the client
> > will do a lookup for the ESNI record or a cached value. If there is one,
> > the simple solution is to put the public name in the SNI extension and
> > the actual name in the ESNI extension.
>
> Sure, I know that and am fine with it being the default.
>
> > If the public name is censored,
> > the solution is probably to look for a different ESNI record for the
> > server, one that would mention a different public name.
>
> If the public_name is censored, then there may be >1 solution
> needed, so allowing for more than one seems better than assuming
> there is one and only one solution in that circumstance.
>
> >
> > By the way, I think that the current ESNI record is maybe a little too
> > complicated. The ESNI key is really a property of the public server, yet
> > the ESNI record is defined as a property of the hidden server. If the
> > public server rolls a new key, all the ESNI records of all the hidden
> > servers that mentioned the old key need to be updated. I think it would
> > be simpler to have the ESNI record as a property of the public server,
> > and to just have a pointer to the public server in the context of the
> > hidden server. May an SRV record. The chain would be something like:
> >
> > 1) Look up whether the SRV record for _esni._tcp.hidden.example.com
> >
> > 2) If there are such records, select the appropriate public server, say
> > public.example.net
> >
> > 3) Look up ESNI, A, AAAA for public.example.net
> >
> > In that architecture, there is no need to encode the public server name
> > in the ESNI record. I think there will be several advantages. The ESNI
> > record's TTL can be set to the lifetime of the key. The SRV record's TTL
> > can be set to the expected lifetime of the relation between 'hidden" and
> > "public". If the SRV lifetime is long enough, the value can be
> > efficiently cached by the client. If multiple clients share the same
> > hidden server, the ESNI record is fetched only once, and can be cached.
> > At connection time, the client would only need to query the A/AAAA
> > records of the public server, i.e. exactly the same DNS transaction as
> > an access to the public server.
>
> That seems a bit like the HTTPSSRV proposal and maybe better in
> a different thread?
>
> S.
>
>
> >
> > -- Christian Huitema
> >
> >
> >
> >
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>