[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Response from IAB re: Checking data for validity before usage in protocol

IESG, here is the response you requested.

Geoff, can you make this available on the IAB website please?

paf

Review of draft-klensin-name-filters-03.txt
-------------------------------------------


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, a number of references in the I-D are missing
in the text.




Statement on heuristics applied in applications regarding addresses entered by users
------------------------------------------------------------------------ ------------

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 term "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.