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

Christopher Patton <> Thu, 10 September 2020 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 106943A1039 for <>; Thu, 10 Sep 2020 12:43:31 -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 ZxzKaCmFjvW2 for <>; Thu, 10 Sep 2020 12:43:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 608223A1037 for <>; Thu, 10 Sep 2020 12:43:29 -0700 (PDT)
Received: by with SMTP id n133so7287481qkn.11 for <>; Thu, 10 Sep 2020 12:43:29 -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=i3u0FPVdpTEGrt/T2l/jiSQH26T13eATx35QhNQEgt4=; b=cN8gYasGIj7KSpYy0YtKKp5r2opfEqfiosjrmZLm8qSJkchtoWfWBLrvbYjNyl8TRh 8M6MifIlLl47MDZ2kFTvvUcmZy+oTYVCOcc3IYCS7DrXLb4uTYxQ745kLSh3Y+qwD2u1 RzV3fJktKZ/SfyYYZnjcrrui64iy30OpfG9S4=
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=i3u0FPVdpTEGrt/T2l/jiSQH26T13eATx35QhNQEgt4=; b=LNdEDD3ezJlsHyyxkbN4JVidx+avy1RuqQOm+46KbKwQIUXXg0V+oTsLIS9hI28+cp a8/kEoaJb4fUDUq7YCiRRcJIhOwpz0GVSVLENpZa9n0i3TCpFXwWdN78RWh4bdBpDqcq gZzEJ+StYeNVt60t5FmX25JkdAg00c/Dnua6KCx4ZKuTGcY+M5fzW2oDv2WfEOXTuFM0 7Ufky6Go0w3TtYvQFrdgNBu4SwSw5wYOgd2G7OOdwed3Qvg42/EiNofiIrWbKhtcFqQi NuOGBtkIAyi9tgQWDKy2TywfJKsaZEINPConFqWTjUekYioSzeYnKALOa5+tNWEzs8hZ nqEw==
X-Gm-Message-State: AOAM532ZePAPVfRUzGVisa1pw0GVb/1NUgZnFSGOj+Tmwn5NvZ0WQZhc bGSXcpi5QBh+BB0YEDXPvtEEOJ2yfGuZWmmKcloFPmFuQkr9oKVI
X-Google-Smtp-Source: ABdhPJwr9be//V8VhnWh4PwF5gl8y702F7usLIEu2L2E0hO3PJ0qOFd7tv2E5ZO5mZuAfzzRmyDK4hUaC1Awq84GrN4=
X-Received: by 2002:a37:545:: with SMTP id 66mr9405588qkf.338.1599767008360; Thu, 10 Sep 2020 12:43:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Christopher Patton <>
Date: Thu, 10 Sep 2020 12:43:17 -0700
Message-ID: <>
To: Mike Bishop <>
Cc: Christian Huitema <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000041e61105aefac88b"
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:43:31 -0000

Hi Mike,

I've since updated the proposal to address the replay attack, but not
Christian's MITM attack:

A quick question about Chrisitian's suggestion of using the "key_shares" to
derive the hint. I believe a slightly stronger variant of the MITM attack
beats this mitigation: suppose the server replays not only the original
hint, but also the original "key_shares" shares extension. It won't be able
to decrypt the client's response, but can't the attacker still detect ECH

Chris P.

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 isn’t
> limited to cases where the observer/attacker is the one performing the
> replay.
> 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.