ECHConfigList, IPv4 and IPv6 hints for reaching proxies without DNS #257
Conversation
draft-ietf-intarea-proxy-config.md
Outdated
| `proxies` array, `protocol` and `proxy`. There are also optional key, including | ||
| `alpn`, and keys for split-DNS defined in {{split-dns}}. | ||
| `proxies` array, `protocol` and `proxy`. There are also optional keys, including | ||
| `alpn`, `ech`, and keys for split-DNS defined in {{split-dns}}. |
There was a problem hiding this comment.
I wonder if this is really needed in this JSON... if the name of the proxy needs to be resolved with DNS, we could get ECH that way. If the proxy is just an IP address, do we need ECH?
The arguments I see in favor of having this are:
- We could have other ECH-protected data other than SNI
- This location is more trusted/secure than DNS
There was a problem hiding this comment.
You are spot on.
ECH is not just for SNI but could also be used to hide other potentially sensitive cleartext fields in ClientHello from passive observers - so it could be useful for proxies defined by IP.
And yes, this is certainly more trusted/secure than DNS - especially for privacy-centric proxy use cases.
Finally, in many legacy but still widely found enterprise setups explicit proxies are configured in environments that do not have access to public DNS resolution.
There was a problem hiding this comment.
I am also not sure if this needs to be here. This also adds another place that needs to be coordinated.
There was a problem hiding this comment.
The primary use case I had in mind is to allow ECH to the TLS enabled proxy in environments where clients do not have access to DNS and rely on proxy to perform the resolution.
Happy to discuss at IETF 121.
yaroslavros
changed the title
|
Added ipv4hint and ipv6hint to complete the use case when client cannot or does not want to use DNS. Again, this is not uncommon in enterprise environments to not allow end devices to perform DNS resolution and requesting everything through proxy by hostname. Providing IP address hints as well as ECH for the proxy would allow getting full benefits of TLS channel to the proxy in such setups. |
Signalling ECHConfigList would allow clients to use Encrypted Client Hello when establishing TLS-based transport with the proxy.
Since spec already suggests passing ALPN hint it makes sense to add
echkey similarly to HTTPS DNS record.