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

Nick Sullivan <nick@cloudflare.com> Mon, 23 March 2020 10:55 UTC

Return-Path: <nick@cloudflare.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 2CF373A077F for <tls@ietfa.amsl.com>; Mon, 23 Mar 2020 03:55:12 -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 8XCRseXtTyjm for <tls@ietfa.amsl.com>; Mon, 23 Mar 2020 03:55:10 -0700 (PDT)
Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 DFA7A3A0784 for <tls@ietf.org>; Mon, 23 Mar 2020 03:55:09 -0700 (PDT)
Received: by mail-vs1-xe2e.google.com with SMTP id s10so53vsi.9 for <tls@ietf.org>; Mon, 23 Mar 2020 03:55:09 -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=dX4XBMabjNXa4LOVOujldHBmfc7Tgim+cQdj3dpjJ/g=; b=lwN09ctRuI5M8QjWkeN/x0AaqqNcAP66hpLg2oLhFas9A1uZO23VKo9vn0ggNzjfsM DYCYF21TkaX6Q4frEdmBGzZxdT1tiNC2vVFhxAAkm4i26QKoSQeQ8dV/vEzpyTgwGLVZ XMErst2VrInyMwIxtUt2kBsZi8UNza3gzPnX0=
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=dX4XBMabjNXa4LOVOujldHBmfc7Tgim+cQdj3dpjJ/g=; b=cANkCmTpYFI500eEWMHJBdsR3aVj5H+sHwXWpdJOmVv+g3pK2rFX3WwGtcuzx8B80Z 6ZLDG5qh7Vp7uKwM1psDAMshIniMpxcYNfpijD8unp/oHB+IhEdVeoXkRBMaSyrIsCQs 2m8+5VAn6hgM91gU2HL39TAa7PCXVhgcFuKIc+/FxUgADYi371AfTI5C/0eftzfVn7VO LlneFxA6cm8qd7R8Yi3KqdyFiBed9KNtFeRcHgzbegk/l6jDNw1UJ7o1qtyrnd/ALE/M W1qS6/QUcjdYhkLY8O0H+OlGGE1WXWhRnqgZU/3BeKfPl5H42kYKh+eBrEzNUuzP1xRH 41rw==
X-Gm-Message-State: ANhLgQ226tFePgyGMLccRp9vuZmg9id8pWTawYDrFhf3EqDKJJk1J0Sr Ng0k9u3ShxtO/aUf7unvq30U8fSUWIKRf1hbFi6v8o20pT0=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvAvTN74kF0forn5IZ37ZVz3HHJ0WSK2KzG1Qjk?= =?utf-8?q?Q6ZIXvoHwP06GMTgJv7685TketRRWXcirjh1NQg7rGy4qAE=3D?=
X-Received: by 2002:a67:26c2:: with SMTP id m185mr15167046vsm.180.1584960908512; Mon, 23 Mar 2020 03:55:08 -0700 (PDT)
MIME-Version: 1.0
References: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
In-Reply-To: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
From: Nick Sullivan <nick@cloudflare.com>
Date: Mon, 23 Mar 2020 03:54:57 -0700
Message-ID: <CAFDDyk8U7R9ROizUMQebC_r+bnNQi8XbCc1qyHgmqMvA-WKTUg@mail.gmail.com>
To: Christopher Wood <caw@heapingbits.net>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000efa41c05a183771c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aSTmHwaaYSv_0mCH43AAmyurO6U>
Subject: Re: [TLS] Dropping "do not stick out" from ECHO
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: Mon, 23 Mar 2020 10:55:28 -0000

I have reservations.

On Sun, Mar 22, 2020 at 9:54 AM Christopher Wood <caw@heapingbits.net>
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 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.


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.


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?

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?


>
> 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.



>
> What do others think?
>
> Thanks,
> Chris (no hat)
>
> [1]
> https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.4
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>