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

[Ben Schwartz <[e-mail]>]

It might be helpful to have a more precise definition of "do not stick out".

Considering a passive intermediary on the network path who cannot see the
DNS path, I can think of a few different "not stick out" properties we
might want:

1. The intermediary cannot identify clients that support ECHO.
2. The intermediary cannot identify servers that support ECHO.
2a. ... based on the connection contents alone.
3. The intermediary cannot tell whether ECHO was actually used.
3a ... based on the connection contents alone.

ECHO currently does not have Property 1.
Property 2 seems unlikely to be achievable in practice.  By publishing an
ECHOConfig, the server reveals its support for ECHO to everyone.  Chris
also noted a way to probe directly for confirmation.
Property 2a seems to be the topic at hand.
Property 3/3a relies on GREASE.  Like Property 2, Property 3 is (normally)
easily broken by an intermediary with a database of published ECHOConfigs.
[*]

I'm OK with losing Property 2a.  However, Property 3a seems achievable and
potentially valuable.  Consider a network where most clients support ECHO
and use GREASE, but only a minority can actually fetch ECHOConfigs, e.g.
ECHOConfig fetching requires the user to change their DNS configuration.
An intermediary who wants to record all SNIs could block only the
connections that actually activate ECHO, forcing clients to revert their
DNS configuration change and reveal the SNI.  Limiting this blocking to
public names that the intermediary is aware of seems like a worthwhile
step, especially since these names can be rotated relatively rapidly
(~minutes).

Property 3a is compatible with a flag in the ServerHello, so long as the
flag says "ECHO in use" when actually GREASE is in use.  This could be
achieved by reporting "ECHO in use" whenever the SNI is not a Public Name
used by the server (assuming it is not an actual origin name), or adding a
"long term ID" field (at least 32 bits) to ECHOConfig that persists across
key rotations.

Perhaps a good approach would be a flag meaning "ECHO retry in use".
(Would it be safe to move "retry_keys" to the unencrypted extensions?)

--Ben Schwartz

P.S. Ideally, I still want Property 1.  I imagine it might be possible by
formatting the ECHO as 0-RTT data, as Christian Huitema and others have
discussed over the years.

[*] Actual ECHO ClientHellos to a server at some IP will have the Public
Name in the SNI field, whereas GREASE ClientHellos will have the origin
name there instead.  However, if the ECHOConfig Public Name is in fact a
valid origin, then (with sufficiently good GREASE) the intermediary is
unable to state with certainty whether any particular user visited that
domain, even if many users cannot actually fetch ECHOConfigs.  In the
extreme, a server could publish a slate of ECHOConfigs that name _all_ of
its domains as Public Names, so that seeing any of them in the SNI field is
not proof of anything.

On Sun, Mar 22, 2020 at 12:55 PM Christopher Wood <[e-mail]>
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.
>
> 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.)
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>