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

Eric Rescorla <> Mon, 21 September 2020 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE3383A0407 for <>; Mon, 21 Sep 2020 08:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 Wzw7IRdbz0qk for <>; Mon, 21 Sep 2020 08:00:40 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1399B3A0417 for <>; Mon, 21 Sep 2020 08:00:40 -0700 (PDT)
Received: by with SMTP id x69so14377683lff.3 for <>; Mon, 21 Sep 2020 08:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hmh8ywl7ichljmG3b0fTNRSw6rr0AAmR+FLddrOcYJM=; b=R0pVDOVo4OPPigyijO9n5Qe8jPRSJEB2fGOrRYq9/AWcmC5M286bzKGQRlJeVrLSTM K4AXDIdhUQn6PfYczzOpDXs5LAeft8817uDd5Ypma+WxKd5167MdgX0SBBcqs/pzA4pO mUeGSKl5ANKuCHVijdrNZ+s9uNwubqrMhiXaEp8dXpJToageHyL0YAn9JjeK+TsVZj0q v5tQl+i+3IGEcRQki1GMb96CBzvvS5tQKkTr6kir7CRfvBHftpV68YpPSqt7OclbGnyR CpcnxtOXVr3/W66uXvDfoFWDg98LOeDppMSD2e0szoMHqSB0hKjzfdJeohWOpL1g5h6M rZtQ==
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=Hmh8ywl7ichljmG3b0fTNRSw6rr0AAmR+FLddrOcYJM=; b=l2Zdp/TLXNpZUuvVfbu4uLR5xjYmALdCgERjdJug1BKjVl5c2IU24XzefAm4V31VLy b5AHdOYye/NnG1u6/Y8CkbTZ6XhKWu39TG+8GCyT/NZPjFazXnXG3ptkKvV5j2D/uixt 8LM08CAk1afMKMr6RAZncIo3huBozKHjmVQ8eIXdO1+i5kG+Dn4Y58WQretm+ewHRlY0 h0wyRrbbVyDxM+F5c7ZrrHj3+b8tjHGZhYr+NcjIS3Dzkv0e+tS+Q5bHf8d5Vbah8SIv 4A2NL/gVDmC8Li9CPFdzIiBR9F+QcvT+DCt5FWlbixzUor48QGXAuDr0gmlwPZ09l5it 6wrA==
X-Gm-Message-State: AOAM531BJWor1fchGEVmveU7zMO6bkpQzb5w++NUmQzM1u0WhUTxlKAJ 665PNapkni3YIks9iToZ9lQ1En+crc3XBNV2cnjWvQ==
X-Google-Smtp-Source: ABdhPJxAa81C8Uj7rkfeo7l0CyMFcf5VlD26GPjT4tsC0PHY2pnJGUgjOPrG+s/1c9wAepzfW9oxaWfN11Nbs0Cr6Wo=
X-Received: by 2002:a19:dd5:: with SMTP id 204mr105223lfn.579.1600700438193; Mon, 21 Sep 2020 08:00:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 21 Sep 2020 08:00:01 -0700
Message-ID: <>
To: Christopher Patton <>
Cc: Karthik Bhargavan <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000002bedd05afd41d5c"
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: Mon, 21 Sep 2020 15:00:42 -0000

On Sat, Sep 12, 2020 at 11:41 AM Christopher Patton <cpatton=> wrote:

> I agree with Christian. The reason to use the ServerHello.random trick is
> to make real ECH connections look like connections in which the client
> sends a dummy ECH extension to a non-ECH server. In particular, this design
> pattern is needed for property (1).

> Property (2) is achievable if the ECH configuration is secret, i.e., if
> the server is deployed in such a way that it does not reveal it speaks ECH
> unless the client offers the right configuration. In particular, the server
> need not publish the ECH config, either via DNS or the ECH retry logic.
> This won't be feasible for the vast majority of deployments.

I think this is the key point:
1. If the ECH Config is public, it's trivial to tell whether the client is
trying to do ECH
2. If the ECH Config is public, it's also trivial to tell whether the
server does ECH
3. It's reasonable to expect that if the client is trying to do ECH and the
server does ECH, you will get ECH.

That limits the degree to which it is useful to conceal whether a given
connection is using ECH. From my perspective, the purpose of this piece of
the design is to discourage middleboxes from blindly suppressing ECH, but
at the point where you are willing to actively intercept each connection,
the ECH Config attack seems much easier.  Note that if the deployment
environment changes so that it would be desirable to fold the handshake key
into this value, this can be done later with an ECH Config extension and
will not need to appear on the wire.