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

I'm worried that it'll be too tempting for orgs and Governments to just
drop sessions which have negotiated ECHO.
Even if we had wide scale deployment of GREASE, if a third-party can allow
GREASE but block successful ECHO handshakes then all the effort we've
expended will be wasted.

Does the probing attack only apply in cases without a key share, or is it
also possible in cases where key shares are in use?

Regards,

Jonathan

On Sun, 22 Mar 2020 at 18:00, Christian Huitema <huitema@huitema.net> wrote:

> On 3/22/2020 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.
>
> 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
>
>
> Section 5 of this draft says:
>
>                                                               ... In
>    practice, it may well be that no solution can meet every requirement,
>    and that practical solutions will have to make some compromises.
>
>    In particular, the requirement to not stick out presented in
>    Section 3.4 <https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.4> may have to be lifted, especially for proposed solutions
>    that could quickly reach large scale deployments.
>
> As part of AUTH48 changes, we agreed to add a line in section 3.4 pointing
> to this comment is section 5.
>
> We can observe that ECHO already sticks out, because of the presence of an
> unexpected encrypted field in the Client Hello. So in practice ECHO
> deployment already relies on achieve large scale deployment, and possibly
> greasing the encrypted parameter.
>
> -- Christian Huitema
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>