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
