search

tlswg / draft-ietf-tls-esni

TLS Encrypted Client Hello
https://tlswg.github.io/draft-ietf-tls-esni/#go.draft-ietf-tls-esni.html
Other
231 stars 57 forks source link

Relax public_name to public_identity and describe how clients construct CHOuter based on it. #425

Closed chris-wood closed 3 years ago

chris-wood commented 3 years ago

(This change assumes the answers to (1) and (2) from #424 are both "yes.")

Previously, public_name was assumed to be a DNS name. #413 added validation criteria for this value. This change relaxes public_name to be a reference identity for the client-facing server. As a result, clients use this identity when constructing CHOuter and authenticating the client-facing server. This identity may be either a DNS name or an IP address, depending on the particular client-facing server deployment.

I'm totally open to bike shedding the validation criteria, but would really like to hear high-level opinions on this change before doing so.

cc @bemasc, @davidben, @sftcd, @martinthomson, @dmcardle

Closes #424, #405, #396

bemasc commented 3 years ago

As I mentioned in #424, I think RFC 8738's approach is worth considering:

As [RFC6066] does not permit IP addresses to be used in the Server Name Indication (SNI) extension HostName field, the server MUST instead use the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP address as the HostName field value instead of the IP address string representation itself. For example, if the IP address being validated is 2001:db8::1, the SNI HostName field should contain "1.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa"

We would leave the SNI empty for the IP case, but use this as the encoding of IP addresses in public_name. This encoding is not very efficient, but it's nicely unambiguous and widely implemented.

If we decide to stick with this ambiguous encoding, I would suggest relying on the URI host syntax from RFC 3986, rather than cloning it as this text does.

chris-wood commented 3 years ago

(Noting here that we're bike shedding on encoding, and not on whether or not the identity can be an IP address.)

We would leave the SNI empty for the IP case, but use this as the encoding of IP addresses in public_name. This encoding is not very efficient, but it's nicely unambiguous and widely implemented.

If folks think this is adequate and easy to implement, I'm fine with it. (I don't know how widely implemented this is.)

If we decide to stick with this ambiguous encoding, I would suggest relying on the URI host syntax from RFC 3986, rather than cloning it as this text does.

I do not feel strongly, but, any particular reason why you'd lean on RFC 3986?