Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt

Ben Schwartz <> Tue, 02 June 2020 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AC413A1025 for <>; Tue, 2 Jun 2020 14:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pYwpklSD4juA for <>; Tue, 2 Jun 2020 14:26:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D80EF3A101F for <>; Tue, 2 Jun 2020 14:26:25 -0700 (PDT)
Received: by with SMTP id q11so152210wrp.3 for <>; Tue, 02 Jun 2020 14:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DuZrMRZAM+bwBGq9sIBpwoiFn6lWSQsISu3zcC6So/Q=; b=K+XHF/zKBwYTZD7TQSjxwhmTCvyvWgEpuztrAR47CTI/YUAfhAssldTq7vOqMgMB2Z PS7QTDNFHW9RtVfW44ANx4S3V/cP1NC77adNlf3HAdJVZuGRgFu2Mx0J1yVck5nUsn7o hJItxPdIUWlUk8Y4o8IP9pGXF8KJsH6AR3hDMi4OmyRvgMX/eHg6Zfq6Yf6InpQXdn+A yRaQUuyc85Nk9ax6pAbQkTuanKljiX1ZT6pQB0YMZJYrasiCAdG0HWNio83ZvF5rxPX4 hDRdjs3MK32D0eUGZhO2eB9yYVI2kIX1PbluIe8PcrrqHAB0+9IWCumqu20WZlPPFrSa auAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DuZrMRZAM+bwBGq9sIBpwoiFn6lWSQsISu3zcC6So/Q=; b=Bwu12sydWxpR8bk8Z0BhhxLth8Al8XZO/nHJV/57gRbnHDvllHkxaG4AQH8ZQRl1Rc x1yehgr7t89N8Mys+6BOpeKWL6OOrbmBYK+fY8+N759yGU3tIIfad0Wc4X6xzBUn5aio 9ExtmfHKFk5NEZK3hiRQ2NhxoOL5NLMomHN5rOoQS2TR5HD2Cu/Z6IBWpz6waFpoeqKh MwhhIYGbiiF8vnN7yUr45gdxOWQPEg8mMmGk4pA89muPzwyKH0PREmQadzl0S5BAEfN7 BNfd0/JlbE8KMxLhsf31mhlPfSSdWezrIMqKi6VqpMjEu88Ve9YJBj587NM5G8pHJnvY 9EFA==
X-Gm-Message-State: AOAM5333HKK/cN9C5iz2fcn738HcvHSI8RVs0H8Ukvz1RtNPQuOy+XrC cNFTj5vECqwje9chykYK7kj4CzN2vZQbMEh69Rv6sQ==
X-Google-Smtp-Source: ABdhPJz6XfMnN53fIsSiQ1hN9Rrm6hYKo94o+mhJY/HCovID9zfWQmIKQDHH4mPYY4kVmDi4HfPF0MbxHqJM+xf9wXc=
X-Received: by 2002:a5d:4cc4:: with SMTP id c4mr27429216wrt.159.1591133173822; Tue, 02 Jun 2020 14:26:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 02 Jun 2020 17:26:02 -0400
Message-ID: <>
To: Christian Huitema <>
Cc: "Salz, Rich" <>, Stephen Farrell <>, Christopher Wood <>, "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000a675be05a7208f8d"
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt
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: Tue, 02 Jun 2020 21:26:33 -0000

On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema <>

> On 6/2/2020 11:44 AM, Salz, Rich wrote:
> > Trial description scares me.  Perhaps that's not a rationale fear -- one
> of the points of CDN support is a large anonymity set -- but I worry about
> the DoS possibilities. Especially if QUIC picks this up (now trivial to
> fake "client IP") and if some large mobile manufacturers move to use this
> as the default as I've heard they are considering.
> I am looking at a very specific use case: mobile servers.

Presumably, connecting to a mobile server requires a rendezvous (a.k.a.
"signalling") channel, in order to learn its current IP address.

> Suppose that
> you use TLS to connect from a mobile client to a mobile server using an
> untrusted network, such as a Wi-Fi network in an airport. Neither the
> client not the server want to reveal their identity when using the
> network. When using TLS, they will use ECH to hide finger-printable data
> such as SNI, ALPN, or QUIC initial parameters. But the record digest in
> the ECH blob is also an unique identifier of the server.

For your use case, if the server's IP address is dynamic, and discovered
through a rendezvous channel, can its ECH blob also be dynamic, and
discovered through the same channel?