From nobody Thu Sep 10 18:54:30 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 5F4513A0A1E for ; Thu, 10 Sep 2020 18:54:27 -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 usNJYHO1mBEX for ; Thu, 10 Sep 2020 18:54:25 -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 00A9C3A0A0C for ; Thu, 10 Sep 2020 18:54:24 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id db4so4441135qvb.4 for ; Thu, 10 Sep 2020 18:54:24 -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=iJmENZ/kGw60j9i7FjkAjgb+XqxVk9hMNp68B6k4c3I=; b=jIwsa8h1UP8hdJDGxZ1DTcEBlKnNRNXgKrdjyOwGakAy3KOvrZxSSLnDPTBT2COgUn iLLsJO1SqQjXvEljoB6N4x9NY7CnncK4I2aj/ym3lWFTfNWjs8SaJeagzo2psWC6gKZp L4LtbKjpLd92KhrB6V+htZldvO2G/8exAxSys= 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=iJmENZ/kGw60j9i7FjkAjgb+XqxVk9hMNp68B6k4c3I=; b=c00aXYOOdisCUFC0kfoWF3b2oyp23z6m8htvc7fKRFAJjA44uNBKOz/Q7+Tl7jGywS z8GO+2OekTNbf45dH4eh3uAJut93jN7PS8+kEVBupOVGx5f2Gt0khwBA/4a3vKywMs5b Rj+vFVsvRRRbxfVSPFc/+9Xzvs6oxU5IU2Ymmq5460gf14ow4I54rXgRYkIHKCcBw25l 37D2dPgc5FLYuzt/zaMq/8XJ0dx8vRH6TbgwepPucquxyPcOhdqXmZ6HFPd1nUmrmyjz A7fCLF5i749iSGWeuAiByi4pfWKq5BzJ9SD42dLOlLY1Z+JPyDKexNetBtexkxp9mLpg niSQ== X-Gm-Message-State: AOAM530E+iVGx2ihN9w8GWIur7pPl4t2TYo2tCQelAoLvkedJJp9rB5n yM/l2eaMZrFrMcx8UWKiqA//S3L+AavAYd/3IB7wRaPvPq0FXA== X-Google-Smtp-Source: ABdhPJzRR/uFKnvG7ivl+zf4/crzQi15NXRtTIcBymcFXZmAhy3ZIEFJ7Tz07KggWKijBeE2u64NcCb4xDR2Zq7nQFA= X-Received: by 2002:a05:6214:d6b:: with SMTP id 11mr24679qvs.30.1599789263964; Thu, 10 Sep 2020 18:54:23 -0700 (PDT) MIME-Version: 1.0 References: <1c13374e-f375-0bdb-2316-f6fc222192b4@huitema.net> In-Reply-To: <1c13374e-f375-0bdb-2316-f6fc222192b4@huitema.net> From: Christopher Patton Date: Thu, 10 Sep 2020 18:54:13 -0700 Message-ID: To: Christian Huitema Cc: Mike Bishop , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cb720c05aefff627" 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: Fri, 11 Sep 2020 01:54:28 -0000 --000000000000cb720c05aefff627 Content-Type: text/plain; charset="UTF-8" Hi Christian, No, I don't think the server can detect ECH usage by doing that. The > client will complete the exchange as if connected to the server. The > client's response would pretty much the same as if the server's response > had not been modified, and the MITM will not be able to test whether > this is ECH or not. If it could, ECH would be seriously broken. > I think we should be careful with the word "broken" ... here we're talking about "don't stick out", which is a deployment consideration only. The main security goal is confidentiality of the ClientHelloInner. > But there may be some attack plausible by playing with the ciphersuite, > or maybe the TLS version extension. I don't think so, but I can't prove > it either way. One solution would be to incorporate more elements in the > hash. Another would be to serialize the whole server hello, with a > proforma random, and add to the hint hash the server hello bytes that > follow the "random" part. > The latter seems to be the lowest cost in terms of implementation complexity. Nevertheless, I continue to believe that its cost outweighs the benefit of this mechanism. To summarize my reasons: 1. The class of active attacks it addresses is quite narrow, and we have no reason to believe that it poses a deployment risk to ECH. (It certainly doesn't invalidate the main security goal.) 2. We know of much simpler active attacks for distinguishing real ECH from cover ECH, which means the intended threat model isn't fully addressed. 3. Any future mechanism that rigorously addresses the intended threat model will replace what we specify today. It seems like good hygiene to keep the thing we'll be replacing as simple as possible. The current proposal (https://github.com/tlswg/draft-ietf-tls-esni/pull/287) doesn't stick out much to passive attackers, and it even mitigates (accidental) replay attacks. This ought to be enough to begin experimenting with deployment. We won't know what the real-world deployment risks are until we do. Best, Chris P. --000000000000cb720c05aefff627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christian,

No, I don't think the server can detect ECH usage by doing that. The client will complete the exchange as if connected to the server. The
client's response would pretty much the same as if the server's res= ponse
had not been modified, and the MITM will not be able to test whether
this is ECH or not. If it could, ECH would be seriously broken.

I think we should be careful with the word "b= roken" ... here we're talking about "don't stick out"= ;, which is a deployment consideration only. The main security goal is conf= identiality of the ClientHelloInner.
=C2=A0
But there may be some attack plausible by playing with the ciphersuite,
or maybe the TLS version extension. I don't think so, but I can't p= rove
it either way. One solution would be to incorporate more elements in the hash. Another would be to serialize the whole server hello, with a
proforma random, and add to the hint hash the server hello bytes that
follow the "random" part.

The latter seems to be the l= owest cost in terms of implementation complexity. Nevertheless, I continue = to believe that its cost outweighs the benefit of this mechanism. To summar= ize my reasons:
  1. The class of ac= tive attacks it addresses is quite narrow, and we have no reason to believe= that it poses a deployment risk to ECH. (It certainly doesn't invalida= te the main security goal.)
  2. We know of much simpler active att= acks for distinguishing real ECH from cover ECH, which means the intended t= hreat model isn't fully addressed.
  3. Any future mechanism tha= t rigorously addresses the intended threat model will replace what we speci= fy today. It seems like good hygiene to keep the thing we'll be replaci= ng as simple as possible.
The current proposal (https://github.com/tlswg/draft-ietf-tls-esni/pull= /287) doesn't stick out much to passive attackers, and it even miti= gates (accidental) replay attacks. This ought to be enough to begin experim= enting with deployment. We won't know what the real-world deployment ri= sks are until we do.

Best,
Chris P.
--000000000000cb720c05aefff627--