From nobody Sat Sep 12 11:41:17 2020 Return-Path: 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 ; 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 ; 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 ; Sat, 12 Sep 2020 11:41:14 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id n18so10540218qtw.0 for ; 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: <696D22EB-2B7C-47AB-946F-B3246709A10B@inria.fr> <3452C763-05CA-459C-A114-BB0163AB59EC@inria.fr> In-Reply-To: <3452C763-05CA-459C-A114-BB0163AB59EC@inria.fr> From: Christopher Patton Date: Sat, 12 Sep 2020 11:41:02 -0700 Message-ID: To: Karthik Bhargavan Cc: Ben Schwartz , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004e43bf05af222587" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2020 18:41:16 -0000 --0000000000004e43bf05af222587 Content-Type: text/plain; charset="UTF-8" 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. --0000000000004e43bf05af222587 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Christian. The reason t= o use the ServerHello.random trick is to make real ECH connections look lik= e 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 rev= eal it speaks ECH unless the client offers the right configuration. In part= icular, the server need not publish the ECH config, either via DNS or the E= CH retry logic. This won't be feasible for the vast majority of deploym= ents.

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 HMA= C approach is a much better design. It would be useful if someone from QUIC= ville could chime in on how painful it would be to implement. (It doesn'= ;t seem that bad for vanilla TLS.)

Chris P.

--0000000000004e43bf05af222587--