Primary eng (and PM) emails
Summary
This I2D&R is to restrict the set of valid hostnames that the network name resolver will attempt to resolve. We will restrict names to those that follow the “preferred name syntax” established for hostnames (A/AAAA) — in particular, those containing only letters, digits, and hyphens (the “LDH rule”). In addition to supporting these characters, for web-compatibility reasons, we will also accept underscores (‘_’).
This is an attempt to resolve known interoperability issues with spec non-compliance, but also security issues that arise from the current, liberal approach.
Because internationalized domain names (IDNs) are encoded as Punycode before being sent over the network, and because Punycode follows the LDH rule, this will not change support for IDNs in Chrome.
Motivation
DNS is a complex protocol. On the wire, RFC 1034 (and related RFCs) establish that a valid DNS record can include any character (“8-bit clean”), other than the NUL byte (‘\0’, used to separate labels). However, hostnames in particular (A/AAAA) are expected to observe the preferred name syntax, which is letters, digits, and hyphens. While other record types (such as SRV) use additional characters, like underscores, these are not part of the legal syntax for hostnames. Further, names using the preferred name syntax are expected to match in a case-insensitive manner. The confusion is broadly covered in RFC 7719 in its discussion of terminology.
Many DNS libraries do not validate that the input follows the preferred name syntax, and thus send whatever the caller requests over the wire. This can create security vulnerabilities, both in clients and in parsers (such as URL parsers) that attempt to determine the hostname portion, since the expected syntax rules are not followed.
Interoperability and Compatibility Risk
The current Chromium code attempts to resolve any names that callers pass, even when they do not conform to the LDH rule. This includes any arbitrary 8-bit sequence, including both spaces and control characters, provided that there are no embedded NUL bytes (‘\0’).
We expect limited interoperability or compatibility problems, since these names do not conform to the relevant RFCs for valid hostnames.
To measure this, we added the UMA historgram Net.ValidDNSName, which measures resolution attempts for invalid characters. As of 22 May 2017, Chrome Stable (58) shows that approximately 0.02% of resolutions include invalid characters.
While this means there is some interoperability risk for DNS, these names are invalid for use in other contexts. For example, hosts using such names cannot use QUIC (which strictly enforces the proposed rule), and they are not supposed to use TLS SNI (which Chrome always includes, except for IP addresses), because SNI is specified to follow the LDH rule.
Alternative implementation suggestion for web developers
Web developers whose servers have names that currently resolve should experience no change. :)
Usage information from UseCounter
The UMA histogram measures name resolution attempts, rather than successes, and shows a low number of attempts (0.02% on stable). This is higher than we expect, but we are still confident that this will not cause real web breakage — as explained above, such hostnames will already fail in a variety of web contexts. We expect that the invalid hostnames are due to errors that are already causing breakage, such as malformed URLs and HTML markup.
OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=716626
Entry on the feature dashboard
https://www.chromestatus.com/feature/5747040885669888
Requesting approval to remove too?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOuvq20r56rsxKQKYxJjhLR6jxtzkQ4WZvoYYEAQzMQYvjGL2A%40mail.gmail.com.
I assume this I2R doesn't affect Chromium's mDNS resolver for browser features (Cloud Print, Cast, etc.)?
DNS-SD hostnames always include underscores. However, I don't believe there's a way to trigger resolution of them from navigation or Web content.
Summary
This I2D&R is to restrict the set of valid hostnames that the network name resolver will attempt to resolve. We will restrict names to those that follow the “preferred name syntax” established for hostnames (A/AAAA) — in particular, those containing only letters, digits, and hyphens (the “LDH rule”). In addition to supporting these characters, for web-compatibility reasons, we will also accept underscores (‘_’).
--
Non-OWNERS LGTM. Even aside from security issues, tightening restrictions on the data we send over the wire is a good thing (Postel was wrong!),
and aligning our DNS lookup behavior with our Omnibox behavior as pkasting@ suggests sounds like the right thing to do. Would you be willing to change the restrictions you're proposing to match that behavior?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAHOzFBQ37DkAadHSQskwDBtgykN9Ai2GAMeQHyyzJztZQ%3DcWA%40mail.gmail.com.
You might want to try shipping the relaxed behavior with some kind of monitoring code to check how often it would have violated the stricter behavior, before just going to that. It's possible that this case does come up, but only in intranets, and we haven't seen bugs from those folks filed against the omnibox? I'm willing to believe that the omnibox needs to get looser to match your behavior rather than the other way around.
Sure, I can do that. I'll put up a CL for review and people can see what they think.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9362ba3b-109c-4fed-b183-d230a7ed6325%40chromium.org.
If this doesn't affect any _succecssful_ resolutions (eg. because DNS servers or our upstream DNS stack already prevent these cases), then I don't think there's really any web exposure and so no need for an intent at all.
But if even half of those cases turn out to be some special case that does actually work today and we break a bunch of page load, then we absolutely need to consider the compat and interop risks here.
Why are we measuring attempts at all? Could we instead just be measuring resolution successes of this form? If dev channel data suggests that's near zero, then I think you can safely treat this as a bug fix and not a web platform change at all.
I will try to write and land a CL to count 'successful' resolutions too. But keep in mind we're talking about things that would be hard for DNS server administrators to type into their zone files, even if the DNS server will accept such zone files.
Nice, thanks.To be clear, if the opinion of you and your code reviewers is that this should really never (or only exceedingly rarely) trigger, then you're free to treat it as a bug fix and skip the intent process ("trivial" web platform change). But this is definitely the data we'd want to see to evaluate the compat risk as an "intent to remove".
To be clear, if the opinion of you and your code reviewers is that this should really never (or only exceedingly rarely) trigger, then you're free to treat it as a bug fix and skip the intent process ("trivial" web platform change).
On Thu, Jun 1, 2017 at 7:27 AM, Rick Byers <rby...@chromium.org> wrote:To be clear, if the opinion of you and your code reviewers is that this should really never (or only exceedingly rarely) trigger, then you're free to treat it as a bug fix and skip the intent process ("trivial" web platform change).I've decided to take that tack:
I'd really like a Blink engineer to take on the Blink aspect of https://bugs.chromium.org/p/chromium/issues/detail?id=695474&desc=2 as well.