Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ECHConfigList, IPv4 and IPv6 hints for reaching proxies without DNS #257

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

ECHConfigList, IPv4 and IPv6 hints for reaching proxies without DNS #257

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8b78dd9
Added ech key to pass ECHConfigList
yaroslavros Oct 6, 2024
1fea994
Reverting change from another branch
yaroslavros Oct 6, 2024
3396248
Added ipv4hint and ipv6hint
yaroslavros Oct 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions draft-ietf-intarea-proxy-config.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -143,8 +143,8 @@ Each proxy is defined by a proxy protocol, a proxy location (i.e., a hostname an
{{!URITEMPLATE=RFC6570}}), along with potentially other keys.

This document defines two mandatory keys for the sub-dictionaries in the
`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}}.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. We could have other ECH-protected data other than SNI
  2. This location is more trusted/secure than DNS

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also not sure if this needs to be here. This also adds another place that needs to be coordinated.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's discuss at IETF 121!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Other optional keys can be added to the dictionary
to further define or restrict the use of a proxy. Clients that do not
recognize or understand a key in a proxy sub-dictionary MUST ignore the entire
Expand All @@ -156,6 +156,7 @@ uses. These keys are registered in an IANA registry, defined in {{proxy-info-ian
| protocol | No | The protocol used to communicate with the proxy | String | "connect-udp" |
| proxy | No | String containing the URI template or hostname and port of the proxy, depending on the format defined by the protocol | String | "https://proxy.example.org:4443/masque{?target_host,target_port}" |
| alpn | Yes | An array of Application-Layer Protocol Negotiation protocol identifiers | Array of Strings | ["h3","h2"] |
| ech | Yes | Base64-encoded ECHConfigList structure as defined in {{?ECH=I-D.ietf-tls-esni}} | String | "AD7+DQA65wAgAC..AA==" |

The values for the `protocol` key are defined in the proxy protocol
registry ({{proxy-protocol-iana}}), with the initial contents provided below.
Expand All @@ -179,6 +180,9 @@ If the `alpn` key is present, it provides a hint for the Application-Layer Proto
(ALPN) {{!ALPN=RFC7301}} protocol identifiers associated with this server. For HTTP proxies,
this can indicate if the proxy supports HTTP/3, HTTP/2, etc.

The value of `ech` provides information for constructing Encrypted Client Hello {{ECH}} when TLS
encapsulation is used for proxy communication.

When a PvD that contains the `proxies` key is fetched from a known proxy
using the method described in {{proxy-pvd}} the proxies list describes
equivalent proxies (potentially supporting other protocols) that can be used
Expand Down
Loading