Date: Sat, 8 Nov 2003 09:57:13 +0100 To: iesg@ietf.org Cc: iab@ietf.org From: Patrik Faltstrom <paf@cisco.com> Subject: Response from IAB re: Checking data for validity before usage in protocol
At the request of the IESG, the IAB has undertaken a review of the internet- draft document "draft-klensin-name-filters" and the associated architectural issues that the document raises, and has the following comments.
The IAB has reviewed draft-klensin-name-filters-03.txt and has the following comments.
The document summarizes many of the issues with filters, but the IAB believes that the document can use stronger wording in three areas:
When filtering and guessing on DNS names, the document could explore in further detail the implications of existence of a search path in the resolver. The communication channel between the application and the resolver may not permit the application to know or control what the resolver does with search paths. The text should include a description of problems when both the application and the resolver try to "add" suffixes for domain names. This is intended to create a more complete picture of these issues.
When an application guesses domain names, in some cases multiple DNS queries are issued. For example, with various TLD's as suffixes (to a misspelled domain name). This increase of DNS queries might not be optimal from a DNS perspective, so applications should be careful with this mode of operation. Particular care is required in identifying local contexts, such as PTR records for RFC 1918 addresses, domain names with "local" domains ("localhost." or private domains which are not registered in the DNS like domain names below the pseudo TLD "local."). Discussions around this topic is also relevant to the context of ENUM (RFC 2916) and overlap dialing. For example, "Should a DNS lookup be permitted after each key on a phone is pressed?". Discussion should stress the need for dns negative response caching to help suppress some of the useless queries generated by search paths and other forms of name guessing.
The text in many cases uses statements of the form "...in general..." before explaining what might be possible to do "in general". A casual reader might miss the "in general" statement and think the proposed filters can be applied in a too broad sense which would give this draft the opposite result than what is intended. The editorial comment here is that this should be expressed in separate sentences so that the intention is carefully defined.
Apart from these comments, an editorial note is that a number of references in the I-D are missing in the text.
The document draft-klensin-name-filters-03.txt describes some pitfalls that exist when applications try to guess what a user is entering in the application. The document does not take a stand on whether in general testing as described is a good thing or not.
IAB believes it appropriate to emphasize the statements in the draft of the form "...in general...the following filters are appropriate..." and "...if filters like this are applied, this is how to create them...". What should be emphasized here is not how the proposed filters are to be created, but instead the terms "in general", and "if".
As the document indicates, the best situation for an application, and possibly the best situation for a user, is if the application does not guess what the user wanted. The application can instead indicate to the user: "sorry, this address is not valid" and the user would have to try again. If an application attempts to guess, the match of the guess to the actual intended use may not strike a high level of correlation. The space in which the guess is formulated may be too small (such as, for example, a domain name guess where there are TLDs in existence that the application has no knowledge of). In such cases the user may be incorrectly denied access to the resources at the specific address.
If filters (and other kind of heuristics) are to be applied, it should only be made inside the realm of the application itself, and the user should always have the ability to really enter what she wants. This means among other things:
The area where a user is to input a URI (domain name) in, for example, a browser is not really an area to enter an unadorned domain name. It must be clear to users what form of input is required, as results might not only be "guesses" from the the application's or a resolver's point of view, but also a fallback of the choice of the browser of what search mechanism to use to if all DNS lookups result in NXDOMAIN.
A user is to be able to enforce / bypass mechanisms which try to "help" but in some cases do the contrary. One good example is listed at the end of the document, regarding internationalization of domain names. Note that this example talks not only about the ability to enter the non- encoded (Unicode) version of the domain name and the encoded (which starts with 'xn--'), but also about the (very) different policies different registries have regarding what Unicode codepoints are allowed in a non-encoded domain name.
Even though filters on for example LDH characters in DNS is in general correct (if one limits the domain name to encoded internationalized domain names), octet values of 0-255 (decimal) are allowed in labels, and some resource record types (SRV for example) explicitly uses codepoints outside of the alphanumerical characters.
The rules for what is a correct protocol identifier changes over time, and possibly more often than end users update their software. There is a risk users with old software which is unable to communicate with newly created resources on the Internet because of this.
Implementation of "clipboard" functionality (copy and paste identifiers between applications) can create confusion if different applications use different filters. It might be confusing enough for users to copy and paste internationalized domain names between IDNA-aware and non IDNA- aware applications for a number of years.
Conclusion: The IAB urges application developers to implement filters with great care, if they are to be used at all. The implementation should only work inside the scope of one application, and the users should be both informed, and able to turn such "help" off.
This page is maintained by the IAB Executive Director for the IAB.