Re: [TLS] Dropping "do not stick out" from ECHO

Christopher Wood <> Mon, 23 March 2020 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C7053A09D8 for <>; Mon, 23 Mar 2020 08:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=jjRKlaua; dkim=pass (2048-bit key) header.b=CNf3+bxE
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wcVBHnN5N17n for <>; Mon, 23 Mar 2020 08:40:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F46D3A0969 for <>; Mon, 23 Mar 2020 08:40:12 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 1917B5C02D2; Mon, 23 Mar 2020 11:40:11 -0400 (EDT)
Received: from imap4 ([]) by compute1.internal (MEProxy); Mon, 23 Mar 2020 11:40:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=ZT ptabx+k9DkNM9ZYM+eV3jompl2XYPR8+ErGXXjCO4=; b=jjRKlauapbKLiB7u6e EH7be1eISPPYXovS9uQ2SBMX+qImAcZElc+46RDULefs1FMcDhXADIcB4vNLSk5/ Th8tBFeGAPAtwaWE3kTbhXBSvCweKTzav9P0BLbozlZ3ckgwd0+ALHXosSXMbLkt sTL9hOEgn1ot/aqPXHub8lH/YqwBGOMJsI6f8CSUjjgw/h0TEv4coqSs1bIRC2O0 PQVjNLXbSFZUItoqYzF1Fu4Tw7wo5Pr6ccTZ1XV4FN64uW82Ka0glbyj2QwDiQoF 38d4Dw+NDKWzQbLRXFKzZHXNxA1887hIU5A1yEkir6AaXNALTtG/6kzDm/OmyCoj irFQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ZTptabx+k9DkNM9ZYM+eV3jompl2XYPR8+ErGXXjC O4=; b=CNf3+bxEHmQt6SEl26VewyB4YyDq6kj8yvXm8SiWxBIHHV7bjgpWHM5ZA Y0LLOflgWFGYQuSj/CT9Hsfq9ZM6P8A/zA/xldQYCq5RwPcc1fr7hDXK77+1Ndtd 2MYhck/SxihwpPArjdGNQSq3aSofnbbNV79VYGFKniBHXiBVdwLjd/uaoi+ZoP7m tTrrmu7UepPbOPyQQ3EpkQE8w8skd1LhRmGWtxv84cV7ehc1jyOWSPVFA30yxG4t 5MBNmXwSVBcby5ovTpFbm8nAkJkycXuypcWRZ/vo7EfR8O7s9BrxIz65mh1UCBSj nws7p+WEWmXwmH0ksNQlebDDRa2vw==
X-ME-Sender: <xms:Wth4XhSQR29kDsSrX8vGVp642f7-6qYHpAqDAMdOaHMBNJJSjOATDQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegkedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegt rgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:Wth4XhTG5shMJGmYjBbKqwUBvghTmGZFmO80tU0ptZTb-oF7tvZ5_Q> <xmx:Wth4XqDvpDGAE8hFz2u79rilLgFy2nt3rm-s-eQy51cm4-IpEq33aw> <xmx:Wth4XjBcZDjmTeueBw4ocofDK4qItrSXjpu4H9LFaKMtdtehKmvFjg> <xmx:W9h4XqBSa7xkHQNhf_Uunl1GCZCVnHIHq8YhnSlZDPjUGoyfVwT5AQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE8143C00A2; Mon, 23 Mar 2020 11:40:10 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <>
Date: Mon, 23 Mar 2020 08:39:50 -0700
From: "Christopher Wood" <>
To: "Nick Sullivan" <>
Cc: "" <>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] Dropping "do not stick out" from ECHO
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: Mon, 23 Mar 2020 15:41:22 -0000

Trying to reply succinctly inline below!

On Mon, Mar 23, 2020, at 3:54 AM, Nick Sullivan wrote:
> I have reservations.
> On Sun, Mar 22, 2020 at 9:54 AM Christopher Wood <> wrote:
> > One of the original motivating requirements for ECHO (then ENSI) was "do 
> >  not stick
> >  out" [1]. This complicates the current ECHO design, as clients must 
> >  trial decrypt
> >  the first encrypted handshake message to determine whether a server used 
> >  the inner
> >  or outer ClientHello for a given connection. It's also trivial to probe 
> >  for ECHO
> >  support, e.g., by sending a bogus ECHO with the same key ID used in a 
> >  target client
> >  connection and checking what comes back.
> Do you mean that it’s trivial for an attacker to probe a server for 
> ECHO support or whether it’s trivial to check if a given connection 
> used ECHO or not?

In the current design: both. 

> In the current draft it seems trivial to identify servers that support 
> ECHO by:
> - querying DNS and seeing whether the record exists
> - connecting to the server with an ECHO extension that has a random key 
> ID and ECHO ciphertext and checking if the server returns “retry_keys” 
> (yes means ECHO support)
> Both of these can be done without observing a specific connection.

Agreed. I think we should assume that attackers know which servers support ECHO and which do not.

> If we’re talking about “don’t stand out,” would it be fair to consider 
> the attack you hinted at above as an active attack to identifies 
> whether a given connection used ECHO or not (3b in Ben’s email)? If so, 
> it points to a weakness in the current protocol description that could 
> be remedied.

It's definitely an active attack. I don't disagree that it's possible to fix. What I am concerned with is the cost of fixing it. 

> Here are three scenarios:
> Client connects to confirmed ECHO-enabled server with valid key:
> 1) client connects to server using an ECHO extension created with a 
> valid key ID and a valid ciphertext for that ID
> 2) server responds with handshake encrypted using the inner CH
> Client connects to confirmed non-ECHO-enabled server with GREASE:
> 1) client connects to server using an ECHO extension with a random 
> invalid key ID, and an invalid ciphertext
> 2) server responds with handshake encrypted using the outer CH, no 
> retry_keys
> Client connects to ECHO-enabled server with GREASE (say DNS was 
> blocked):
> 1) client connects to server using an ECHO extension with a random 
> invalid key ID, and an invalid ciphertext
> 2) server responds with handshake encrypted using the inner CH, sends 
> default cert and retry_keys
> For these scenarios, the attacker collects the handshakes and key IDs, 
> and wants to determine which is which. The attacker then probes the 
> servers with three connections:
> A. client connects to ECHO-enabled server using an ECHO extension with 
> a valid key ID (taken from a connection), and an invalid ciphertext
> The server will match the key ID and return “decryption_error” when the 
> ECHO ciphertext fails to decrypt.
> B. client connects to ECHO-enabled server using an ECHO extension with 
> an invalid key ID (taken from a GREASE connection), and an invalid 
> ciphertext
> The server will respond with handshake encrypted using the outer CH, 
> including retry_keys.
> C. client connects to non-ECHO-enabled server using an ECHO extension 
> with a the invalid key ID (taken from a GREASE connection), and an 
> invalid ciphertext
> The server will respond with handshake encrypted using the outer CH.
> All three are distinguishable. This lets the attacker know whether a 
> given connection actually used ECHO (outer handshake) or GREASE for an 
> ECHO -enabled site. This shows that we don’t currently have property 3a 
> from Ben’s reply.
> A simple way to eliminate this oracle would be for the server to treat 
> ECHOs that have valid IDs but are corrupted or don’t match the outer CH 
> differently: treat them as GREASE handshakes and respond using the 
> outer CH and retry_keys. This would make the results from A and B 
> indistinguishable.
> Given this modification, is there still an active attack to determine 
> if a specific connection used the outer or inner CH?

Yep -- David's attack still applies. If the outer CH has no ciphersuites and the connection succeeds, then the inner CH was  used.

> Does David Benjamin’s cut-and-paste attack still work if the cipher 
> list in the inner client hello is just a pointer to the cipher list in 
> the outer client hello?

Not that specific one. But we probably shouldn't pick and choose which things we need to bind, as that was problematic in past designs. Instead, we would probably need to bind the entire outer CH to the inner CH. (The current design has the machinery to do this: export a PSK from the HPKE context and use it to compute a binder over the outer CH.)

> >  I propose we remove this requirement and add an explicit signal in SH 
> >  that says
> >  whether or not ECHO was negotiated. (This will require us to revisit 
> >  GREASE.)
> A downside of this modification is that ECHO is no longer able to be 
> used by existing TLS 1.3 servers without modification.
> One of the neat features of ECHO is that a a server-controlled proxy 
> that only has access to ESNI keys can determinate which client hello to 
> use (inner vs. outer). This allows a shim proxy to decrypt ECHO (or 
> fail to) and send a singular CH on to the real server running 
> unmodified TLS 1.3 software. This modularity opens up a massive 
> opportunity for the large TCP load balancing providers out there with a 
> lot of IP space to enable ECHO for legacy applications without needing 
> access to their private key. Having a signaling extension in the 
> handshake eliminates this deployment scenario (one that CF is currently 
> exploring).
> Of course, without modifying the server, ECHO is less effective since 
> it won’t be possible to apply padding to the server’s portion of the 
> handshake. However, being able to deploy ECHO as an independent proxy 
> service is something I consider a huge plus of the current design. We’d 
> be losing it by adding a new signaling extension.

Admittedly, this is a nice feature. However, I don't have confidence in its efficacy without server-side changes. (This is probably worth a separate thread.)