Re: [TLS] [ECH] Reverting the config ID change

Ben Schwartz <> Wed, 17 February 2021 22:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D445E3A1DE5 for <>; Wed, 17 Feb 2021 14:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.6
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1rpbuyDn0RBx for <>; Wed, 17 Feb 2021 14:28:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 488DE3A1DE4 for <>; Wed, 17 Feb 2021 14:28:08 -0800 (PST)
Received: by with SMTP id s24so15635330iob.6 for <>; Wed, 17 Feb 2021 14:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 17 Feb 2021 17:27:55 -0500
Message-ID: <>
To: Stephen Farrell <>
Cc: Eric Rescorla <>, "" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b8eac905bb8fbb41"
Archived-At: <>
Subject: Re: [TLS] [ECH] Reverting the config ID change
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: 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 "" and an ECH user whose ECHConfig.public_name is ""quot;.  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.