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

Christopher Patton <cpatton@cloudflare.com> Tue, 08 September 2020 18:22 UTC

Return-Path: <cpatton@cloudflare.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0B3A0C29 for <tls@ietfa.amsl.com>; Tue, 8 Sep 2020 11:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkb36cibPdxB for <tls@ietfa.amsl.com>; Tue, 8 Sep 2020 11:22:52 -0700 (PDT)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5323A0C27 for <tls@ietf.org>; Tue, 8 Sep 2020 11:22:52 -0700 (PDT)
Received: by mail-qv1-xf32.google.com with SMTP id j10so165471qvk.11 for <tls@ietf.org>; Tue, 08 Sep 2020 11:22:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l27AtgoZqYp0eLl71jR6RBAO91HtVaIVdebscuuAnu8=; b=av7+gJgARdU2dJJ+6c3x+ScOAiKyImVrVxKYtEUhTRCAV6gQXIvJ30+quV5yeRbInB 4hCdQXP2Rk5JziMq6w7OGFMLxHwCPO0OG/O87S+2gEJks770Hgb3TUgioKyrjBipXnUU bfgNl+xrQn5JdmGzGVPei2X5fUQ7EYOLHfTuc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l27AtgoZqYp0eLl71jR6RBAO91HtVaIVdebscuuAnu8=; b=g459LmJcUAca1Kqs7b8KiSLsBxwYQUNtBF8bGRj/2PW+PdYweosETkIsUNpdvhusav Y4ATJxuOBKmx5I6ZHMGVfWJ5PgCSNmjE9HnYAamMSU+RCsxF8bYjIfT/a6RBGIsRDC8g 9XtAoPn2II1SwrTND8tEcwCXqaN/1Q2oH+beQ9IXdYXjr8odDNZ9ru/9KYshqqi+Al5Y 2OVHcdFOhinOGFFgiliwCMBKQFR8KfRXdgk75kIGczjGlImYOVDiOYiiESy+gtzMSZUl VQiAE3xXRPOc+3LStnk4f2Du+ZIWKApfY/LtDs/t/NwhhcJ09Azgp6YSefKMkRP3lG20 4kCw==
X-Gm-Message-State: AOAM531TX2WGSwOZIGRvLmYHNPZvKHMCHmsgMTqbTf0CBb8veES0mT4e HIAj0WRrs9QbAd21jjvZZHTeaVvI7qZFLbTV88n9CDA/Lia6mw==
X-Google-Smtp-Source: ABdhPJygs2KHZndRAxhri3mchfBP+ZUMYgRUm0zHsXF27S97lfJJM1LWBe+ofr4jB7xNX1rCCwMbs9+IiPh827LftZ4=
X-Received: by 2002:a0c:f44e:: with SMTP id h14mr384036qvm.4.1599589371137; Tue, 08 Sep 2020 11:22:51 -0700 (PDT)
MIME-Version: 1.0
References: <d33c685c-6bf3-1584-4d95-1fe2cf6695e8@huitema.net>
In-Reply-To: <d33c685c-6bf3-1584-4d95-1fe2cf6695e8@huitema.net>
From: Christopher Patton <cpatton@cloudflare.com>
Date: Tue, 08 Sep 2020 11:22:40 -0700
Message-ID: <CAG2Zi23NQRPUzHbVKSSSxR_eaNokVF--K9FfCNMagrCKnSHMZQ@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000040f3f405aed16c6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LiQmIB1J-jK8NyerJg4-qcqu260>
Subject: Re: [TLS] TLS ECH, how much can the hint stick out?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2020 18:22:54 -0000

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.