Hi Ben, Thanks for the engagement on this topic, it really helps sharpen the focus in a way that will improve the next version of the draft. Additional notes inline.
On Wed, Mar 11, 2026 at 10:27 PM Ben Schwartz <[email protected]> wrote: > > In this example, the Proxywerks ASN and BYOIP spaces are slow to change and > trivial to enumerate, so I don't think they contribute much to the value of > this proposition. I think that’s fair. TLS is agnostic to the underlying IP layer, and this draft deliberately does not make assumptions about address allocation, routing, or how expensive it is to identify the relevant server IPs. In many/most practical deployments, IP-based traffic identification may still be relatively easy and efficient. > If we imagine that Proxywerks also has dynamic arrangements in which IP > addresses are borrowed from many different ISPs, that could make enumeration > more challenging and potentially justify this proposal. However, in my > experience: > > * These kinds of borrowed IPs are usually limited to use in a particular > region, and are not available in the regions under threat. > * These IP addresses are slow to change. > * These IP addresses are easy to identify via forward or reverse DNS. > > Perhaps a more compelling example would be a "virtual CDN" that doesn't own > any hardware or IP space. Instead, it rents a variable number of virtual > machines, each with an accompanying (presumed unpredictable) IP address, from > a shared public cloud provider, and makes them available via fast-changing > DNS answers. I don't know of a deployment like that today, but it seems like > an architecture where the CDN's server IP addresses might not be trivial to > identify. Yes, and I think that indicates that this issue is more likely to be solved with novel network designs or composition with different transport-layer technology rather than something TLS should try to solve by itself. Work in other places, e.g. MASQUE-style proxying, may help with privacy at the IP layer, but that is generally out of scope for a TLS document. > > > and all of those IPs are also used for many unrelated origins. > > If Proxywerks is serving other origins from the same IP addresses, and wants > them to be indistinguishable from ECHConfig Foo to an attacker, why doesn't > it just give those other origins ECHConfig Foo too? In practice, some customers disable ECH for various compatibility, policy, or operational reasons. This line was meant to highlight that IP-based identification is inherently coarse: it includes all traffic from those addresses, including non-ECH origins as false positives. A fixed visible public_name is different: it is a precise TLS-layer selector for likely membership in the ECH deployment. The point of this draft is to take that precise selector away. > > I don't understand this justification, but I also think it is unnecessary. > The proposal can be justified by preventing trivial distinction between > traffic that is inside Proxywerks' network and traffic that is outside of it, > if we are willing to assume that this is not already obvious from the server > IP addresses. I think that's the right framing. The draft is not claiming to solve IP-layer observability, and in practice IP-based identification tools may still be useful. The claim is narrower: TLS should not unnecessarily preserve an easy SNI-based classifier when that classifier can be removed. As an aside, IP-based and name-based filtering are not always on the same legal footing: for example, Austria’s telecom regulator, in the TKK case R 31/22, allowed targeted name-based blocking to stand while holding that IP address blocking violated the Open Internet rules because of the risk of overblocking. So removing a TLS-layer selector can still matter even where some IP-based identification remains technically feasible. -Nick _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
