Re: [TLS] [ECH] Reverting the config ID change
Ben Schwartz <bemasc@google.com> Wed, 17 February 2021 22:28 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 D445E3A1DE5 for <tls@ietfa.amsl.com>; Wed, 17 Feb 2021 14:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 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, 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 1rpbuyDn0RBx for <tls@ietfa.amsl.com>; Wed, 17 Feb 2021 14:28:08 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 488DE3A1DE4 for <tls@ietf.org>; Wed, 17 Feb 2021 14:28:08 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id s24so15635330iob.6 for <tls@ietf.org>; Wed, 17 Feb 2021 14:28:08 -0800 (PST)
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=izzh0sNird2BX/oLEZ4SVgURVsjmHCL2k1exFV16Dfg=; b=a/KQV4iNttTRJzU00q7E/urB8qtCGwWdnLkvlfGhyhr5L55mmFj00hkvvq3ir179k2 oQmXbVdVkgdYZOf4cjuDyIqJ0CgPdOQNX2feSCcFaSHTMp2VvjzHQGECbFHwCxuoaKtk YYiEQUXKMKj1rEvojgdQcnj/WsayhKflLF1g79j3epcjFadgQomgjvOh057FZrUyP4N6 r7m9D7Uem95y0ytj+2A9lWIppcfnuGucmyOo6JK1VHPEx7vP97HHPN8OIQQ7Z9BuBpLA u/dGd6VTHYRGN11Cjh1KReT9UOA3hW6+CPI+WeAZjszRZIGdavKM07vtqVCqnB+8wANz CBLw==
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=izzh0sNird2BX/oLEZ4SVgURVsjmHCL2k1exFV16Dfg=; b=dNcbwC1RZsQd/maLCj/DK5i+cz6/YOlMr/LsTsIQVBCORfC4UIIKNaO42OLxaaqyHe YO6ssMQJVXqgz1WmXGqxDgtWiiQ8fr2auIm8aixQ98Qo9+BagpJ5r8PrO67iWwuvcqlZ 3Wp/JKXPFUOIFQf0rfLsPw1zcm79ECkrhvSzZU0oNegDz6CjQoNruovTJCRqfpggXJP+ I4eoIspeuRB5c85sUPzGlO4l8bsiV9FOqt/BW3oAqK3i2G9sg1W01kT70NtCB93gTTz6 AcJYcZPKg32nnutYSxx1JfaBAiER0UZMnmIk/DXP64/fBJUOiYp/yp4498v4Y21zIZ41 m8lg==
X-Gm-Message-State: AOAM530tfNpxLqTwpzX9t87K4EzRvjKbs3TXTJw2iz30q7bDDCLjEW8v GiK4gaLOTGL4cuu2kLi08+qMh6p5Aa7JiLQIuIyjMgQ2xpU=
X-Google-Smtp-Source: ABdhPJyz/RlPFT6tzfOVUuJFgUtug8v9lcK56TBbFx5LqGGfWeeWya9jP0m5f8gWOSZt0wLbgC7PsgmBqot/2QsRV9g=
X-Received: by 2002:a6b:be86:: with SMTP id o128mr977138iof.111.1613600887308; Wed, 17 Feb 2021 14:28:07 -0800 (PST)
MIME-Version: 1.0
References: <e44be9d1-bd0a-4e99-b092-b1b21c517b0e@www.fastmail.com> <7925717a-bcba-4b29-b12b-b47e622c62b3@www.fastmail.com> <CABcZeBO20+09dZ+9ckdm=N-RigMh_O+Svx3m51NsXZY1QFZ73Q@mail.gmail.com> <e55a60e4-e948-4cc5-ad1a-0a1086485305@www.fastmail.com> <b35c4e78-d0ff-8fed-5297-4f16667f18d8@cs.tcd.ie> <CABcZeBPT8mhsqJz_EiCQnzpNiC+S30uMA=S50kV-6Jc7EnciZw@mail.gmail.com> <f3e974b5-fb97-d92b-9257-5910f2b54245@cs.tcd.ie> <CABcZeBPWVv2dDoKTabS6fOUMRT_V7DoygXsG62C1MJiCArxVSA@mail.gmail.com> <b9007c4f-18c7-d85f-eaee-62f0f004a6aa@cs.tcd.ie> <CABcZeBNNHT1cfAPVwAVeYh8cFvDgMxYgmxGc96eXrqa4UN8P9Q@mail.gmail.com> <35fd7353-feb5-8d6a-89f7-7c6922c7e328@cs.tcd.ie>
In-Reply-To: <35fd7353-feb5-8d6a-89f7-7c6922c7e328@cs.tcd.ie>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 17 Feb 2021 17:27:55 -0500
Message-ID: <CAHbrMsDaEsFYepoApJD5n0bscAtkRcT98CMmS4P_fKqMih_zGw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Eric Rescorla <ekr@rtfm.com>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000b8eac905bb8fbb41"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/m13bFK_KY9LpPgB8MHt5O-70LZQ>
Subject: Re: [TLS] [ECH] Reverting the config ID change
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: Wed, 17 Feb 2021 22:28:10 -0000
One interesting property of ECH is that it can enable deniable connection to the public name for GREASE users. In other words, a passive onlooker cannot tell the difference between a GREASE user who is actually connecting to "www.example.com" and an ECH user whose ECHConfig.public_name is " www.example.com". Even an active onlooker cannot be sure that the GREASE user was really connecting to the specified domain, unless they have confidence that they have exhaustively enumerated the valid ECHConfigs. In some contexts, adding doubt to a user activity attribution can be a meaningful privacy gain. Adding visible structure to the config_id has the potential to impair this privacy gain. If all known ECHConfig.config_ids for a public_name have some visible structure, GREASE users will be more readily distinguished with higher confidence, and have less privacy. I'd like to avoid inviting significant visible structure in the config_id field (say, >2 bytes of non-random content) unless we have a compelling use case in mind.
- [TLS] [ECH] Reverting the config ID change Christopher Wood
- Re: [TLS] [ECH] Reverting the config ID change Christopher Wood
- Re: [TLS] [ECH] Reverting the config ID change Ben Schwartz
- Re: [TLS] [ECH] Reverting the config ID change Eric Rescorla
- Re: [TLS] [ECH] Reverting the config ID change Christopher Wood
- Re: [TLS] [ECH] Reverting the config ID change Martin Thomson
- Re: [TLS] [ECH] Reverting the config ID change Eric Rescorla
- Re: [TLS] [ECH] Reverting the config ID change Carrick Bartle
- Re: [TLS] [ECH] Reverting the config ID change Stephen Farrell
- Re: [TLS] [ECH] Reverting the config ID change Eric Rescorla
- Re: [TLS] [ECH] Reverting the config ID change Eric Rescorla
- Re: [TLS] [ECH] Reverting the config ID change Stephen Farrell
- Re: [TLS] [ECH] Reverting the config ID change Carrick Bartle
- Re: [TLS] [ECH] Reverting the config ID change Rob Sayre
- Re: [TLS] [ECH] Reverting the config ID change Eric Rescorla
- Re: [TLS] [ECH] Reverting the config ID change Stephen Farrell
- Re: [TLS] [ECH] Reverting the config ID change Jonathan Hoyland
- Re: [TLS] [ECH] Reverting the config ID change Carrick Bartle
- Re: [TLS] [ECH] Reverting the config ID change Jonathan Hoyland
- Re: [TLS] [ECH] Reverting the config ID change Carrick Bartle
- Re: [TLS] [ECH] Reverting the config ID change Eric Rescorla
- Re: [TLS] [ECH] Reverting the config ID change Stephen Farrell
- Re: [TLS] [ECH] Reverting the config ID change Ben Schwartz
- Re: [TLS] [ECH] Reverting the config ID change Christopher Patton