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

Christopher Patton <cpatton@cloudflare.com> Sat, 12 September 2020 18:41 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 E6A203A0CD8 for <tls@ietfa.amsl.com>; Sat, 12 Sep 2020 11:41:15 -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 iceh2Ins1al9 for <tls@ietfa.amsl.com>; Sat, 12 Sep 2020 11:41:14 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 2B2953A0CD2 for <tls@ietf.org>; Sat, 12 Sep 2020 11:41:14 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id n18so10540218qtw.0 for <tls@ietf.org>; Sat, 12 Sep 2020 11:41:14 -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=Jd2LgW2vlhmy+XbJNn0PKxSYgQzTS43hZ4McLPxXCZU=; b=ktNbv2afNERoHXFf1vDClFtYpId1EiMx84/1uMfq9MYglT/qszJvLUHKr4YXOaDOdE OtuepGJjOg5bckCxVBp9LNXRx28IfE2zVAWP2HOxs9t6kKtEcP162duY1oGm6XdZ/xsX bc11iv5se4DLvrCxwqsU9ov5mjkL8tWOsnrj0=
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=Jd2LgW2vlhmy+XbJNn0PKxSYgQzTS43hZ4McLPxXCZU=; b=Bmh8HZQdzoqVsbuo2pukknUcyfWe4t6zp3W4LWJlChI5iwXz5sibVBVQUdJNAkwS5Q ZO/XTQF8Ca7I8WdGKo7w9xmNz2vl3b7JQpjyxc6RH5Sdyr5BmXMabLci4qgW8ERwM0WQ 8USAPDSz5/ixn0G1qfcGV089dZuqe543w3aZZYhi10VXpYb9Wgjc9Gz2cGVVimNcHAdU aqOz2DdAuNj2hCgKrl1HAfGYbzvLsaGYrgx/0O3WnQX9d0SgA1RRijgVNGdTjEG64+eu FTnMPYvj5ST46hjIlyeDWY2Wq7anbGDFnmA2xfAAFI9I8DsCUI2YJP3t3YKzi8a7vnbH QIwA==
X-Gm-Message-State: AOAM531uOoqBHFhY0CpYXoC3uMb5+M3a2l1ivaTZyNpULW62sxVBl3fB 7fM8EOi6QFAVPFhX9T2SQHxy//O+72FZminc/TuP0g==
X-Google-Smtp-Source: ABdhPJwaCPmoQL2YQpB8jWmQOyy//jbe+5PgjbxqUv27Rs6zfh90JRpaA7YW/okTngEXLx5gEgdVTlKAyrJcL1U3unQ=
X-Received: by 2002:ac8:76c7:: with SMTP id q7mr7066287qtr.293.1599936073179; Sat, 12 Sep 2020 11:41:13 -0700 (PDT)
MIME-Version: 1.0
References: <d33c685c-6bf3-1584-4d95-1fe2cf6695e8@huitema.net> <696D22EB-2B7C-47AB-946F-B3246709A10B@inria.fr> <CAHbrMsDq9fxH9Yvw-BozrZtF4iUU-oeOiMucJ1FBpCZurQsnNQ@mail.gmail.com> <3452C763-05CA-459C-A114-BB0163AB59EC@inria.fr>
In-Reply-To: <3452C763-05CA-459C-A114-BB0163AB59EC@inria.fr>
From: Christopher Patton <cpatton@cloudflare.com>
Date: Sat, 12 Sep 2020 11:41:02 -0700
Message-ID: <CAG2Zi227cJFbh2-Uh7yynFUyPt6Bk0V9BXhHzzfQGZqdRGS_3Q@mail.gmail.com>
To: Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>
Cc: Ben Schwartz <bemasc@google.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004e43bf05af222587"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VejJtxEgqmj1c1_XPnq9dGJD1Uk>
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: Sat, 12 Sep 2020 18:41:16 -0000

I agree with Christian. The reason to use the ServerHello.random trick is
to make real ECH connections look like connections in which the client
sends a dummy ECH extension to a non-ECH server. In particular, this design
pattern is needed for property (1).

Property (2) is achievable if the ECH configuration is secret, i.e., if the
server is deployed in such a way that it does not reveal it speaks ECH
unless the client offers the right configuration. In particular, the server
need not publish the ECH config, either via DNS or the ECH retry logic.
This won't be feasible for the vast majority of deployments.

As I said above, I think ECH should support use cases for which keeping the
configuration secret is feasible. The trial decryption mechanism might
provide this already, but overall the trial HMAC approach is a much better
design. It would be useful if someone from QUICville could chime in on how
painful it would be to implement. (It doesn't seem that bad for vanilla
TLS.)

Chris P.