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>", andAs I said earlier, using "google.com <http://google.com>" would be unwise because itwould 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).
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
OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
