Re: [TLS] publishing ESNIKeys under a .well-known URI...

Daniel Kahn Gillmor <> Thu, 21 November 2019 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDBDC120B66 for <>; Thu, 21 Nov 2019 11:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=zvnIiw34; dkim=pass (2048-bit key) header.b=e99iSRj/
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AGLkf7qHJSiA for <>; Thu, 21 Nov 2019 11:29:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B310C120B64 for <>; Thu, 21 Nov 2019 11:28:59 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1574364538; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=oft7n3iskcbnRKM4PWuM4TpjyeK7m8IZyADyclYJohw=; b=zvnIiw34wiTlOYJIQUgUurNEiVk7t7K5ndKRl/tPMge/RKG3M3kpkAQ4 zZEkrwy62Lo2f452O+IyBKzt+g/0Cw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1574364538; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=oft7n3iskcbnRKM4PWuM4TpjyeK7m8IZyADyclYJohw=; b=e99iSRj/2uFUeE1DJsI0iRKuUrnsgAq6+VeXl2Mq4Af5RHgDhujlmRHE GwG0KTBSenA8BfukOWUw8ItOl4YkGy15jefm4TGBfYRV2Eo6qYoZYb03de cXuezUtUlobYSSrJjnLdWZhp9q6KVl+PCk9GC5hpy+KP/Nu+c55Gncf/iU Brm/l7rGB37Q+ul5VTEh0cW1s9lgAjqEWE8Pj9AKt/z7QT7MoL8nheIeoL Cd9eDt67v8vL1PziEuRy9e7WpXnOCzf8L2KLmylhKf5DaorzfnQX9/YWHh DoB3+/NyglyCumaRwqaAEz0o49YccdFug+rZJgr3iptVoIVOzbdr1Q==
Received: from (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id A5FE7F9AF; Thu, 21 Nov 2019 14:28:57 -0500 (EST)
Received: by (Postfix, from userid 1000) id 5B2602038D; Fri, 22 Nov 2019 03:28:50 +0800 (+08)
From: Daniel Kahn Gillmor <>
To: Stephen Farrell <>, Christian Huitema <>
Cc: "tls\" <>
In-Reply-To: <>
References: <> <18514.1561564689@localhost> <> <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw==
Date: Fri, 22 Nov 2019 03:28:49 +0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI...
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: Thu, 21 Nov 2019 19:29:04 -0000

On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote:
> It doesn't take much to encourage me so I just
> pushed out that idea in I-D form:-) [1]
> [1]

Thanks for this (and for the -01 update for the draft).  I like this
work, and i think we should pursue it in the WG.

A couple notes/questions:

 - Clients might use this, not just "zone factories".  For instance,
   consider a client with limited access to the DNS that makes an
   initial direct connection to the hidden host, leaking SNI.  If, in
   that connection, it also fetches this record, it could use that to
   bootstrap future connections to the host, right?

   The draft currently contemplates this briefly for followup queries
   for some clients, but it doesn't go into it in more detail.

 - Why is it hosted on the cover server, instead of on the hidden
   server?  is that just so that the zone factory doesn't leak $HIDDEN
   to the network?

   Surely on a zone factory update, the zone factory already knows the
   eSNI for $HIDDEN so it could make the request with eSNI to
   https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to

   At the same time, for $COVER to publish this information potentially
   puts $COVER at more risk, right?  And, a $COVER could *claim* to be a
   cover for $HIDDEN without approval of the $HIDDEN site by publishing
   these records; if anyone believes that claim, it could cause traffic
   to be re-routed through the ersatz $COVER.  If it's going to be
   hosted at $COVER and not $HIDDEN, we should be explicit about what
   defends against such an attack.

   There could be an "obvious" reason for the choice of hosting it at
   $COVER instead of at $HIDDEN, but it should be spelled out in the

 - If this is treated as a separate/independent source of authority
   about ESNI data for a host from the DNS (e.g. in the client examples
   contemplated in my first point above, not just the "zone factory"),
   then the draft probably needs some text discussing what to do when
   discovering a discrepancy between what's in the DNS and what's found
   at .well-known.