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

Ben Schwartz <> Tue, 08 September 2020 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEBA33A0C40 for <>; Tue, 8 Sep 2020 11:36:43 -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 5D0j1st2DqDi for <>; Tue, 8 Sep 2020 11:36:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDFFC3A0C2F for <>; Tue, 8 Sep 2020 11:36:41 -0700 (PDT)
Received: by with SMTP id z1so272489wrt.3 for <>; Tue, 08 Sep 2020 11:36:41 -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=L183Wd8nSWeBp+fKZR2cndFmppsz86jdAbFftxjl1M0=; b=WmTDq2OyfCpiHMnWDbuT4jZyadHikRIeuBzf7lJsvpURpVPzkbhSDle9Bq/va7qNxI KwGuA1bRuGdy68zI91XqdCK6o1NdjLrTHn+so1VBDp2ytV2uphQqG5qmdUb2Pbu4i+7s eiRV4/C+gIglAR4sUyq5lruBcC1hzXGmvW4iISfMZtwFhNSwI07fQU/1Wlc1uFGyMmbE swGLlG+k2UyFxO9PeagZ0W49mGh9X0iYNQXaBu8Gjr3N9NrSYbwJpiWISBvM1lasaeiP mlIbGmyCzLJHJCyOT4D3vKkD2USwsD0biLR5sR7XmIOFc94+CNnMhpdjAm/DsZ5EIyJj ocew==
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=L183Wd8nSWeBp+fKZR2cndFmppsz86jdAbFftxjl1M0=; b=h6pJPXp3lDSFBOVACegrg1aYjkn2zu+GGQJp3cSjTD/93mxMOlt9uWz4hIQsc+HTcO qSCqb6addLJV3eWd+DeDzMhPQBamIsamSw7eLfVzGz70K85xV1xOZeA2OskbUbjPYa7k jZLKRoYDT/EBGWHmMsQ5YSFaTVvRbGTrSu6T5HwPSX2NxGSHS5X7LG2MbYkha1xB5/pO 4nOFsGd22EdW8W/OaxBx0X2ApI+dGDBnviHdjH0J3XPOfeHXsOHYtXTaUATp/T4lAQNW 0jY9XeNmbC7DYfQ3fhjiQrye0xE5YcLwlRG77VFC94e4wirJ82sl0HUF4lgvLsWdLDDS LPvw==
X-Gm-Message-State: AOAM533rqJp9UN0hYMbUdv/p7x6YTdjzT8tuLSDiGn6BEXOTDKqyCRTR lsnqPygZfIDclnjYTYXvk7sCM+Qmh1GENnMaCt2mdMSeBq4=
X-Google-Smtp-Source: ABdhPJyoiraAq8qr8J9Z2rcVDYZMmVQkG6tzRKRvT0lAB4z9FlFza3K81LqaJsVXNpHr791ph+0hAsr3ru9c7ggH5EE=
X-Received: by 2002:a5d:510d:: with SMTP id s13mr954461wrt.177.1599590200068; Tue, 08 Sep 2020 11:36:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 08 Sep 2020 14:36:27 -0400
Message-ID: <>
To: Christopher Patton <>
Cc: Christian Huitema <>, "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000b0285105aed19de0"
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: Tue, 08 Sep 2020 18:36:44 -0000

I think we all agree that this discussion concerns attacks that are outside
the baseline threat model, and that we are therefore not "obligated" to
defeat.  However, I also agree with Christian that each additional proposed
defense adds some value, even if the protection is limited -- enough value
to be worth including, but only if it doesn't impede deployment of ECH.

If we can establish how difficult it would be to hash the server keyshare
into the hint in various implementations, I think we'll have our answer.  I
suspect it is difficult enough to create a problem for someone, but I'm not
a TLS implementer.

On Tue, Sep 8, 2020 at 2:23 PM Christopher Patton <cpatton=> wrote:

> 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