tlswg / draft-ietf-tls-esni

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

Avoid a normative reference to WHATWG-IPV4 #574

Closed davidben closed 11 months ago

davidben commented 11 months ago

DNS names and IPv4 literals are a bit of a mess. RFC 1738 said:

The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses.

This is sensible, but was replaced by RFC 3986 with a "first-match-wins" algorithm:

If host matches the rule for IPv4address, then it should be considered an IPv4 address literal and not a reg-name.

The WHATWG URL spec originally mirrored this, but with a much more permissive IPv4 parser, to reflect reality. ECH originally cited this, to be sure we don't accidentally mix up IPv4 literals and DNS names.

The change in RFC 3986 was a mistake and introduced a security problem. The RFC 1738 formulation said a.1.2.3.4 was a syntax error, neither a DNS name nor IPv4 literal. The RFC 3986, along with the analog copied into WHATWG, says it's a DNS name because the IPv4 parser rejects it. But this means:

See also https://github.com/whatwg/url/issues/560

This means DNS names are no longer closed under suffixes! This causes problems for any systems (e.g. eTLD+1s) that need to suffix a DNS name. WHATWG since effectively reverted the RFC 3986 mistake. After https://github.com/whatwg/url/commit/ab0e820b0b559610b30c731b7f2c1a8094181680, the rule in WHATWG is: if it ends in a number (all digits, or 0x + all hex), parse as an IPv4 literal. Otherwise it's a DNS name.

This rule is finally simple enough that we can just lift it into ECH.

(If we want, we can simplify this by just reverting to the RFC 1738 formulation, which should be safe in this context. It is a pity RFC 3986 made a mess here.)