If the load balancer can force a downgrade, an attacker can do it as well.

Only if the attacker has a valid certificate for the domain to complete the handshake with.

Relying on HTTPS and SVCB records will probably allow a downgrade for some attackers, but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult.

DNSSEC can also protect against malicious SVCB/HTTPS records and the spec recommends DoT/DoH against local MitM attacks to prevent this.

▲

tptacek 28 minutes ago | parent | next [-]

DNSSEC can't protect against an ECH downgrade. ECH attackers are all on-path, and selectively blocking lookups is damaging even if you can't forge them. DoH is the answer here, not record integrity.

▲

johnisgood 5 hours ago | parent | prev [-]

> but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult.

Can you explain why, considering it is at the client's side ("browsers")?

	▲	jeroenhd 5 hours ago \| parent [-]
		If browsers remember which domains do ECH and refuse to downgrade to non-ECH connections after, the way the HSTS cache forces browsers to connect over HTTPS despite direct attempts to load over HTTP, then you only need an entry in the browser database to make downgrade attacks to accomplish SNI-snooping impossible. For HSTS, browsers come with a preloaded list of known-HTTPS domains that requests are matched against. That means they will never connect over HTTP, rather than connect over HTTP and upgrade+maintain a cache when the HSTS header is present. If ECH comes with a preload list, then browsers connecting to ECH domains will simply fail to connect rather than permit the network to downgrade their connection to non-ECH TLS.