On Sun, Mar 22, 2020 at 2:49 PM Jonathan Hoyland <jonathan.hoyl...@gmail.com> wrote:
> I'm worried that it'll be too tempting for orgs and Governments to just > drop sessions which have negotiated ECHO. > Well, those orgs will also be able to block encrypted DNS, without which ECHO is useless. We don't have an answer for this either. 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. > This seems like it needs more than a bare assertion. It's certainly the case that some entities will opt to block ECHO but many will not and the clients (and hence users) can be made aware of which ones do. -Ekr 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
