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

Eric Rescorla <> Thu, 10 September 2020 19:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63EB13A003F for <>; Thu, 10 Sep 2020 12:58:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 79_LBJ3JnVHS for <>; Thu, 10 Sep 2020 12:58:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AD623A0045 for <>; Thu, 10 Sep 2020 12:58:13 -0700 (PDT)
Received: by with SMTP id u4so9760610ljd.10 for <>; Thu, 10 Sep 2020 12:58:13 -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=NOGjwP6U4vlzsvIl7jK0IYLxOblR1/MlCq1mlXeTz40=; b=zocTKujsL2Eko+BTXnEC+vCAvejZvcbXcN7FxJuj7AGonPWpEEdaPXnOsTZzYahTxq I1zN8olxfyp8F72A8EuunWDa+8NVJDVT13Jlx3TxuWzySk8y/IGiVCKV6YqxOqYCbWCK ypiNVGsFp6jX4HsG1h7w7gLhJs98my0gv++q/jmipwAmM71SlcXZ0hhjfZvviSg8UI3O jzDl66bvA745LbGJmRbhxgS9TLlXolUvIp//yU1DBd2rb/AgPvZSMlp47NSC9J/07/65 0pW6elv6X8mLimzgvAAoghNY7gqnocMfui6fvweXIeeGX5klOgLHXB+lC0GDG9PGweiw L4XQ==
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=NOGjwP6U4vlzsvIl7jK0IYLxOblR1/MlCq1mlXeTz40=; b=G5s2xBAZzkbPOgtckFzIbee3e6qWKrjCnnBURxMICR2Mdk8x3te8Dy7Rmn12w6o+0S q1sYWEIW4pfmWAhWBZIUEwugUJIEdZEBx4hUR5nCsLo+CpS/xc8ScyToB3w2Y7Wr7jvf L1kgDXaaG74DvGn29Oz85GqQqglUCbyIfF0dYbCEq3Zq0pVr8xqPnOJHgiQ0vJkQKxwN s6ioWK9/1K2JfHx3AYEiAIepKfUgTEv6VrVbHvq2Wbl4cxXZZ98NPc/wl84Ig5DMdXkJ Od+VckvSEXVZRduAUm3JF+jxQtKZsXZDREMQvQb+PWDqKe22r2h+H3kk0zZv/oh/T090 O5Bw==
X-Gm-Message-State: AOAM532K0l8SpSZbCau+p+EUSN5VUJ41wEQ4jJVjcrlxbLzl1TJSSzA5 B8Mcww7MB8rajO5pbj0s6Enc9lKZ7lMX6NzJN2Qt7A==
X-Google-Smtp-Source: ABdhPJyd2CGcHLPZ/9exEhkRW9ZQpPMLhJnZAKOeR9eKbE7Pmg78rDACijYAkiMk8I3vfOZbwfP4PdFp03gxP88Yq0g=
X-Received: by 2002:a2e:8114:: with SMTP id d20mr5047428ljg.409.1599767891438; Thu, 10 Sep 2020 12:58:11 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 10 Sep 2020 12:57:35 -0700
Message-ID: <>
To: Mike Bishop <>
Cc: Christopher Patton <>, Christian Huitema <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000e484ce05aefafc54"
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: Thu, 10 Sep 2020 19:58:16 -0000

On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop <> wrote:

> This is primarily an active attack, but not purely so.  Clearly the MITM
> is an active attacker, but there are situations in QUIC (and DTLS, I
> presume) where a ClientHello gets retransmitted.  Depending on server
> infrastructure, the client might get two different responses.

This doesn't sound correct. In this circumstance, the client and the server
might have mismatched SH values and the handshake will fail. To the best of
my knowledge, the server is required to behave consistently in this case,
even if it consists of multiple machines.


> So I think we need to decide whether it’s a goal that, given that
> relatively narrow situation, the observer shouldn’t be able to identify ECH
> acceptance by comparing two ServerHellos that both respond to the same
> ClientHello.
> *From:* TLS <> *On Behalf Of *Christopher Patton
> *Sent:* Tuesday, September 8, 2020 2:23 PM
> *To:* Christian Huitema <>
> *Cc:*
> *Subject:* Re: [TLS] TLS ECH, how much can the hint stick out?
> Hi Christian, Hi list,
> The "don't stick out" property is a steganographic security goal: we want
> the "real" protocol, i.e. TLS with ECH acceptance, to be indistinguishable
> from the "cover" protocol, i.e., the handshake pattern in which the client
> sends a "dummy" ECH extension that is ignored or rejected by the server.
> This is a property that TLS was never designed to have, but it seems that
> we need some degree of it in order to deploy ECH. The fundamental question
> that Christian raises is what is the right threat model for this property.
> The "status quo" threat model considers a distinguisher that is strictly
> passive---it does not interfere with a handshake or probe the server---and
> that does not know the ECH configuration. This seems (to me, at least)
> sufficient to account for middleboxes that might ossify on the ECH
> extension. It also seems achievable, both by the ECH as it is and for the
> proposed change.
> The distinguishing attacks described by Christian are much stronger, in
> the sense that they involve an active attacker. I don't believe there is
> any way of implementing ECH---either as it is or with the proposed
> change---that defeats active attacks in general. In particular---and as
> Christian points out---an active attacker can probe the server to learn the
> ECH configuration (via the ECH retry logic), which it can use to easily
> distinguish the real protocol from the cover protocol. This works
> regardless of whether the change is adopted.
> In my view, achieving don't-stick-out-security against active attackers
> requires us to revisit the design of ECH altogether. The main difficulty is
> that client-facing servers publish the ECH configuration in a way that's
> easily accessible to an active attacker. Keeping the configuration secret
> may provide a way to achieve security, and some deployments might opt to do
> this; but the vast majority won't. We might consider adding support for
> this deployment scenario, but this can (and should, I think) wait for a
> later draft.
> That said, it is worth considering mitigations against known attacks, in
> particualr (1). I think the suggestion for mitigating (2) adds too much
> complexity, and if it doesn't fully address the intended threat model (I
> don't think it does), then we'll likely need to replace it in the future. I
> think it's better to keep things simple until we fully address the intended
> threat model.
> Best,
> Chris P.
> _______________________________________________
> TLS mailing list