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 <huit...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
