Re: [TLS] TLS ECH, how much can the hint stick out?

Christopher Patton <> Fri, 11 September 2020 01:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F4513A0A1E for <>; Thu, 10 Sep 2020 18:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id usNJYHO1mBEX for <>; Thu, 10 Sep 2020 18:54:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00A9C3A0A0C for <>; Thu, 10 Sep 2020 18:54:24 -0700 (PDT)
Received: by with SMTP id db4so4441135qvb.4 for <>; Thu, 10 Sep 2020 18:54:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iJmENZ/kGw60j9i7FjkAjgb+XqxVk9hMNp68B6k4c3I=; b=jIwsa8h1UP8hdJDGxZ1DTcEBlKnNRNXgKrdjyOwGakAy3KOvrZxSSLnDPTBT2COgUn iLLsJO1SqQjXvEljoB6N4x9NY7CnncK4I2aj/ym3lWFTfNWjs8SaJeagzo2psWC6gKZp L4LtbKjpLd92KhrB6V+htZldvO2G/8exAxSys=
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=iJmENZ/kGw60j9i7FjkAjgb+XqxVk9hMNp68B6k4c3I=; b=c00aXYOOdisCUFC0kfoWF3b2oyp23z6m8htvc7fKRFAJjA44uNBKOz/Q7+Tl7jGywS z8GO+2OekTNbf45dH4eh3uAJut93jN7PS8+kEVBupOVGx5f2Gt0khwBA/4a3vKywMs5b Rj+vFVsvRRRbxfVSPFc/+9Xzvs6oxU5IU2Ymmq5460gf14ow4I54rXgRYkIHKCcBw25l 37D2dPgc5FLYuzt/zaMq/8XJ0dx8vRH6TbgwepPucquxyPcOhdqXmZ6HFPd1nUmrmyjz A7fCLF5i749iSGWeuAiByi4pfWKq5BzJ9SD42dLOlLY1Z+JPyDKexNetBtexkxp9mLpg niSQ==
X-Gm-Message-State: AOAM530E+iVGx2ihN9w8GWIur7pPl4t2TYo2tCQelAoLvkedJJp9rB5n yM/l2eaMZrFrMcx8UWKiqA//S3L+AavAYd/3IB7wRaPvPq0FXA==
X-Google-Smtp-Source: ABdhPJzRR/uFKnvG7ivl+zf4/crzQi15NXRtTIcBymcFXZmAhy3ZIEFJ7Tz07KggWKijBeE2u64NcCb4xDR2Zq7nQFA=
X-Received: by 2002:a05:6214:d6b:: with SMTP id 11mr24679qvs.30.1599789263964; Thu, 10 Sep 2020 18:54:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Christopher Patton <>
Date: Thu, 10 Sep 2020 18:54:13 -0700
Message-ID: <>
To: Christian Huitema <>
Cc: Mike Bishop <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000cb720c05aefff627"
Archived-At: <>
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?
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: Fri, 11 Sep 2020 01:54:28 -0000

Hi Christian,

No, I don't think the server can detect ECH usage by doing that. The
> client will complete the exchange as if connected to the server. The
> client's response would pretty much the same as if the server's response
> had not been modified, and the MITM will not be able to test whether
> this is ECH or not. If it could, ECH would be seriously broken.

I think we should be careful with the word "broken" ... here we're talking
about "don't stick out", which is a deployment consideration only. The main
security goal is confidentiality of the ClientHelloInner.

> But there may be some attack plausible by playing with the ciphersuite,
> or maybe the TLS version extension. I don't think so, but I can't prove
> it either way. One solution would be to incorporate more elements in the
> hash. Another would be to serialize the whole server hello, with a
> proforma random, and add to the hint hash the server hello bytes that
> follow the "random" part.

The latter seems to be the lowest cost in terms of implementation
complexity. Nevertheless, I continue to believe that its cost outweighs the
benefit of this mechanism. To summarize my reasons:

   1. The class of active attacks it addresses is quite narrow, and we have
   no reason to believe that it poses a deployment risk to ECH. (It certainly
   doesn't invalidate the main security goal.)
   2. We know of much simpler active attacks for distinguishing real ECH
   from cover ECH, which means the intended threat model isn't fully addressed.
   3. Any future mechanism that rigorously addresses the intended threat
   model will replace what we specify today. It seems like good hygiene to
   keep the thing we'll be replacing as simple as possible.

The current proposal (
doesn't stick out much to passive attackers, and it even mitigates
(accidental) replay attacks. This ought to be enough to begin experimenting
with deployment. We won't know what the real-world deployment risks are
until we do.

Chris P.