On Wed, Mar 20, 2024 at 10:39 PM Raghu Saxena <poiasdpoi...@live.com> wrote:
> > On 3/15/24 00:02, Eric Rescorla wrote: > > > > > > So, if I understand correctly, for my domain "abc.com > > <http://abc.com>", I could > > purposely choose to have my ECHConfig public_name be "google.com > > <http://google.com>", and > > > > > > As I said earlier, using "google.com <http://google.com>" would be > > unwise because it > > would allow Google to mount an attack where they terminated > > the connection and replaced the ECHConfig. You should instead > > use a name that is either unregistrable or that you control. > > Just so I understand correctly - the scope of the attack if they were to > really intercept the TLS handshake and replace the ECHConfig, would > allow them to "just" decrypt my ClientHelloInner, correct? Since > ultimately the real origin I am connecting to (e.g. "mydomain.com") is > not something they control, and so they can't present a valid cert for > it and complete the full TLS connection (i.e. impersonate the true origin). > Correct. -Ekr At least this is what I understand from Section 6.1.7, specifically: > "Note that authenticating a connection for the public name does not > authenticate it for the origin. The TLS implementation MUST NOT report > such connections as successful to the application." > > Regards, > > Raghu Saxena > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
