User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1
Mime-Version: 1.0
Message-Id: <7b575c92-894d-4fc8-998d-a55fc0ddb450@www.fastmail.com>
In-Reply-To:
 <CAFDDyk8U7R9ROizUMQebC_r+bnNQi8XbCc1qyHgmqMvA-WKTUg@mail.gmail.com>
References: <EB7DEE42-8EC4-4347-BA10-0EBF90CBF398@heapingbits.net>
 <CAFDDyk8U7R9ROizUMQebC_r+bnNQi8XbCc1qyHgmqMvA-WKTUg@mail.gmail.com>
Date: Mon, 23 Mar 2020 08:39:50 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "Nick Sullivan" <nick@cloudflare.com>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/tls/VasWxGSG2ir0PN1XI8iYazXbpQg>
Subject: Re: [TLS] Dropping "do not stick out" from ECHO
Precedence: list

Trying to reply succinctly inline below!

On Mon, Mar 23, 2020, at 3:54 AM, Nick Sullivan wrote:
> I have reservations.
>=20
> 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=20
> >  not stick
> >  out" [1]. This complicates the current ECHO design, as clients must=
=20
> >  trial decrypt
> >  the first encrypted handshake message to determine whether a server=
 used=20
> >  the inner
> >  or outer ClientHello for a given connection. It's also trivial to p=
robe=20
> >  for ECHO
> >  support, e.g., by sending a bogus ECHO with the same key ID used in=
 a=20
> >  target client
> >  connection and checking what comes back.
>=20
> Do you mean that it=E2=80=99s trivial for an attacker to probe a serve=
r for=20
> ECHO support or whether it=E2=80=99s trivial to check if a given conne=
ction=20
> used ECHO or not?

In the current design: both.=20

> In the current draft it seems trivial to identify servers that support=
=20
> ECHO by:
> - querying DNS and seeing whether the record exists
> - connecting to the server with an ECHO extension that has a random ke=
y=20
> ID and ECHO ciphertext and checking if the server returns =E2=80=9Cret=
ry_keys=E2=80=9D=20
> (yes means ECHO support)
>=20
> Both of these can be done without observing a specific connection.

Agreed. I think we should assume that attackers know which servers suppo=
rt ECHO and which do not.

> If we=E2=80=99re talking about =E2=80=9Cdon=E2=80=99t stand out,=E2=80=
=9D would it be fair to consider=20
> the attack you hinted at above as an active attack to identifies=20
> whether a given connection used ECHO or not (3b in Ben=E2=80=99s email=
)? If so,=20
> it points to a weakness in the current protocol description that could=
=20
> 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.=20

> Here are three scenarios:
>=20
> Client connects to confirmed ECHO-enabled server with valid key:
> 1) client connects to server using an ECHO extension created with a=20=

> valid key ID and a valid ciphertext for that ID
> 2) server responds with handshake encrypted using the inner CH
>=20
> Client connects to confirmed non-ECHO-enabled server with GREASE:
> 1) client connects to server using an ECHO extension with a random=20
> invalid key ID, and an invalid ciphertext
> 2) server responds with handshake encrypted using the outer CH, no=20
> retry_keys
>=20
> Client connects to ECHO-enabled server with GREASE (say DNS was=20
> blocked):
> 1) client connects to server using an ECHO extension with a random=20
> invalid key ID, and an invalid ciphertext
> 2) server responds with handshake encrypted using the inner CH, sends=20=

> default cert and retry_keys
>=20
>=20
> For these scenarios, the attacker collects the handshakes and key IDs,=
=20
> and wants to determine which is which. The attacker then probes the=20=

> servers with three connections:
>=20
> A. client connects to ECHO-enabled server using an ECHO extension with=
=20
> a valid key ID (taken from a connection), and an invalid ciphertext
>=20
> The server will match the key ID and return =E2=80=9Cdecryption_error=E2=
=80=9D when the=20
> ECHO ciphertext fails to decrypt.
>=20
> B. client connects to ECHO-enabled server using an ECHO extension with=
=20
> an invalid key ID (taken from a GREASE connection), and an invalid=20
> ciphertext
>=20
> The server will respond with handshake encrypted using the outer CH,=20=

> including retry_keys.
>=20
> C. client connects to non-ECHO-enabled server using an ECHO extension=20=

> with a the invalid key ID (taken from a GREASE connection), and an=20
> invalid ciphertext
>=20
> The server will respond with handshake encrypted using the outer CH.
>=20
>=20
> All three are distinguishable. This lets the attacker know whether a=20=

> given connection actually used ECHO (outer handshake) or GREASE for an=
=20
> ECHO -enabled site. This shows that we don=E2=80=99t currently have pr=
operty 3a=20
> from Ben=E2=80=99s reply.
>=20
> A simple way to eliminate this oracle would be for the server to treat=
=20
> ECHOs that have valid IDs but are corrupted or don=E2=80=99t match the=
 outer CH=20
> differently: treat them as GREASE handshakes and respond using the=20
> outer CH and retry_keys. This would make the results from A and B=20
> indistinguishable.
>=20
> Given this modification, is there still an active attack to determine=20=

> 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=E2=80=99s cut-and-paste attack still work if the c=
ipher=20
> list in the inner client hello is just a pointer to the cipher list in=
=20
> the outer client hello?

Not that specific one. But we probably shouldn't pick and choose which t=
hings 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. (Th=
e current design has the machinery to do this: export a PSK from the HPK=
E 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=20
> >  that says
> >  whether or not ECHO was negotiated. (This will require us to revisi=
t=20
> >  GREASE.)
>=20
> A downside of this modification is that ECHO is no longer able to be=20=

> used by existing TLS 1.3 servers without modification.
>=20
> One of the neat features of ECHO is that a a server-controlled proxy=20=

> that only has access to ESNI keys can determinate which client hello t=
o=20
> use (inner vs. outer). This allows a shim proxy to decrypt ECHO (or=20=

> fail to) and send a singular CH on to the real server running=20
> unmodified TLS 1.3 software. This modularity opens up a massive=20
> opportunity for the large TCP load balancing providers out there with =
a=20
> lot of IP space to enable ECHO for legacy applications without needing=
=20
> access to their private key. Having a signaling extension in the=20
> handshake eliminates this deployment scenario (one that CF is currentl=
y=20
> exploring).
>=20
> Of course, without modifying the server, ECHO is less effective since=20=

> it won=E2=80=99t be possible to apply padding to the server=E2=80=99s =
portion of the=20
> handshake. However, being able to deploy ECHO as an independent proxy=20=

> service is something I consider a huge plus of the current design. We=E2=
=80=99d=20
> 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 sepa=
rate thread.)

Thanks!
Chris