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

Ben Schwartz <bemasc@google.com> Fri, 11 September 2020 14:09 UTC

Return-Path: <bemasc@google.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 4FEC53A09D8 for <tls@ietfa.amsl.com>; Fri, 11 Sep 2020 07:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ZKE_brY-UDXN for <tls@ietfa.amsl.com>; Fri, 11 Sep 2020 07:08:58 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 3617C3A09C5 for <tls@ietf.org>; Fri, 11 Sep 2020 07:08:58 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id p13so9107024ils.3 for <tls@ietf.org>; Fri, 11 Sep 2020 07:08:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i01tBjHpYvFg1V5CWmlWr3V2QhxZ5TmGya9yhfYRfv8=; b=EXDDpMLa5SgLyiGoVEEgKpho3CelDQ0MPlU+Z4tNLZKaHRTvs8UZaW53BoTQHWxt7K 9aAhAITo5YdCN0gtUsf8RlI0KzzyfbN7eyq2Hn9xIYlAM+mdRHVW0PQgnLCph7qQMgs6 iCtjIrM3uFvFIpGWYh8EsDZPfC3Ph7PXjxstqlmbdUaPJ034Veqt+coR7mnejgoug7in BEBCKftwMgFjWDSyuUeVr6Y7dJpzpqkovulgR8t4Z2hZuoWKefF30oXGBWzcEyPtiQff 93+A9/kkrbFoOINgGpFPkN91SR4z/w6+y/AnKENSkBNW02G04d6frh29so2UhPwn/JOm C1LA==
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=i01tBjHpYvFg1V5CWmlWr3V2QhxZ5TmGya9yhfYRfv8=; b=fjRsPxzJmMbHcGxYwqMb6x+8rGERsG93Z4A2eFkm3ve9pAEvLdhPUivPc+empQlwvz lTT7cU1wyl0ErXFl65GudQDA1ujmN1kMwIRSOMnJ5GywPr7JMtJPxqxuaed/0A+Reh7m JYx9v4XTwI82Cjvngm8Du+TUBFenjZwMoBFVyzvNIf/o/u6CNH1hdICEu0gSaf5i6Q3M +XC/z5GSpL6AtToTCYEXqXs1A/VI7hwsxKhT2ameqlfQXJkseF7DyngJe6mmYvev9vhW kbWkL4aiWzIfqqIHDC77HlTbOQ1//breaT/6C02QlQolLSbobAwhSh9fFuQyJ+HG73tK lwhA==
X-Gm-Message-State: AOAM530hPuKlu/W+jDPiO9tgmABGHg3oQq8iWAuof3+I/gVsu+AKD/YB TSkuGRorEw1aoJ2tCBzl/X/RvTuwSEIqPhnYCJiyVw==
X-Google-Smtp-Source: ABdhPJxJCzSyCYJc2SuRoGcA91XRzKHI0tle02AsPCRzUT7F/zWrvy+SFiKJQLPxEDU1+MDbtcb+p1OGW9DkTItYkaU=
X-Received: by 2002:a05:6e02:1141:: with SMTP id o1mr1862082ill.275.1599833337123; Fri, 11 Sep 2020 07:08:57 -0700 (PDT)
MIME-Version: 1.0
References: <d33c685c-6bf3-1584-4d95-1fe2cf6695e8@huitema.net> <696D22EB-2B7C-47AB-946F-B3246709A10B@inria.fr>
In-Reply-To: <696D22EB-2B7C-47AB-946F-B3246709A10B@inria.fr>
From: Ben Schwartz <bemasc@google.com>
Date: Fri, 11 Sep 2020 10:08:44 -0400
Message-ID: <CAHbrMsDq9fxH9Yvw-BozrZtF4iUU-oeOiMucJ1FBpCZurQsnNQ@mail.gmail.com>
To: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
Cc: Christian Huitema <huitema@huitema.net>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c9c1c305af0a3998"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sM48hWy8-AhAKrFDAhKFiTKsE7s>
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: Fri, 11 Sep 2020 14:09:00 -0000

Karthik: That approach works, but unless the ECH echo is universally
deployed, it still reveals to a passive observer whether the server is
ECH-enabled.  That means, at least for several years, exchanges that are
using ECH will likely "stick out" to a passive observer.  This is something
we are trying to avoid.

On Fri, Sep 11, 2020 at 10:00 AM Karthik Bhargavan <
karthikeyan.bhargavan@inria.fr> wrote:

> Perhaps I am misunderstanding the design constraints and the following idea
> has been thought of and discarded, but could we not remove trial decryption
> and replace it with a trial HMAC, at the cost of adding yet more crypto.
>
> - The outer ClientHello contains an ECH extension as usual.
> - The ServerHello ALWAYS echoes the ECH extension, whether it chooses the
> inner or outer ClientHello.
> - This ServerHello extension contains an HMAC  of (say) an empty
> bytestring (or the current transcript)
>    with a key derived from the chosen handshake secret (i.e. either using
> the innerCH or outerCH),
> - On receiving the ServerHello, the client generates both possible
> handshake secrets and both
>   possible HMAC keys, verifies the HMAC and uses it to choose the correct
> handshake secret.
>
> Does the above still conflict with QUIC and open up active MitM attacks?
>
> Best,
> Karthik
>
> > On 8 Sep 2020, at 17:19, Christian Huitema <huitema@huitema.net> wrote:
> >
> > The ECH proposal for Encrypted SNI is almost ready, but for a very small
> > debate. The original proposal was using trial description to distinguish
> > between ECH aware responses to the encrypted inner Client-Hello from non
> > ECH aware response to the "cover" outer CH. This is problematic in the
> > QUIC use case. The latest proposal is to embed a "hint" in 8 bytes of
> > the Server Random. The proposal was for ECH-aware servers to use eight
> > bytes of a hash of the inner Client Random as a hint. Analysis shows
> > that this enables two attacks:
> >
> > 1) If the Client Hello is replayed, the same hint will be present in the
> > response to the original CH and to the response to the copy, providing
> > observers with a clear indication that ECH was used.
> >
> > 2) If the Client Hello is intercepted by an MITM attacker, the attacker
> > can rewrite the server's response before presenting it to the client.
> > The attacker formats its own Server Hello that reuses the Server Random
> > from the original server response, but use its own key share, etc. The
> > hint will cause the ECH aware client to create an handshake key using
> > the inner CH. In a QUIC set up, the MITM attacker can easily detect
> > that, before even transmitting the server's certificate. Thus, the MITM
> > attacker can detect usage of ECH.
> >
> > We have a simple proposal that solves the replay attack: set the hint as
> > a hash of both the inner Client Random and the "non-hint" bytes of the
> > Server Random. That's clearly a good idea, but it does not solve the
> > active MITM attack. Solving that requires tying the hint with the
> > handshake key derived by the original server, for example by hashing the
> > inner Client Random, the "non-hint" bytes of the Server Random, and the
> > server key share. That's harder to implement, so the question is about
> > cost and opportunity.
> >
> > This all relates to how much ECH is "sticking out". The current stance
> > is that a passive attacker cannot distinguish between a client using ECH
> > to access a hidden SNI and a client merely greasing the ECH extension.
> > The observation is that there may be many potential active attacks,
> > especially if the server shares its ESNI/ECH configuration publicly. If
> > there are many such attacks, and if defense of the hint against MITM is
> > hard to implement, implementing the defense might make the code more
> > fragile, with little actual gain. But I am not convinced by that
> > argument, because it smells a lot like "the other side of the boat is
> > leaking too, why should I plug this particular leak?"
> >
> > And so, at Chris Wood's request, I am sending this message to the list.
> >
> > -- Christian Huitema
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>