At Mon, 19 Mar 2007 14:58:07 -0400,
Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> > They don't have to work. If they are stupid, they oughtn't to work.
> > E.g., if your ssh server is checking your reverse record to make
> > sure you are who you claim to be, it's kind of missing the point -
> > it should be checking your public key.
>
> I believe that there are cases where people apparently believe they
> are getting authentication via reverse mappings. Your example of
> using the matching reverse to authenticate an ssh connection would be
> an absurd but clear example of this. Some of those uses are, of
> course a historical accident. Some such uses are, I agree, also
> stupid, and they indeed need not work.
>
> But there are some controversial uses where some people claim checking
> for matching or existing reverse mappings is useful even as others say
> emphatically that the check is bad, evil, wrong, or just silly. The
> obvious case is disagreement on using reverse mapping as a hint in
> spam-candidate scoring. Some users report that, based on the analysis
> of their own traffic, some sort of reverse mapping test is a useful
> indicator. Others correctly point out that such a rule runs the risk
> of false positives and also does not catch all spam.
Actually, the current draft has the same subtle nuance as the above
paragraphs, and I believe that leads to the vagueness I'm seeing.
Let's count the number of "some"s in the above text; in general, the
current draft seems to state: "some people think some use cases of
reverse mapping are useful (and some people think some other use cases
are harmful). So you should provide reverse mapping for all IP
addresses you are managing". The problem is that different people may
have different definitions of the "some". I guess the discussion in
this thread proves that's the case.
As I mentioned earlier, if the objective of the document is to just
list various views and issues regarding reverse mapping without
judging they are good or bad, such "vagueness" might be justified.
But since we now know the goal is to recommend that people *should"
provide reverse mapping, I believe leaving the large room of
interpretation is just dangerous.
> My (editorial) view on this is that, given there are uses where some
> people who understand the limitations of the facility nevertheless
> claim there is utility in their own case, in the absence either of
> numbers to show that the wrong empirical conclusion has been drawn or
> that the use case is implicitly broken, then such a use is not
> obviously stupid.
I'd accept this view itself. But if we are then going to recommend
people should provide reverse mapping based on it, I'd not be
convinced because, at least to me, the use "that is not obviously
stupid" does not outweigh the operational cost at the provider side.
IMO, the requiring side is responsible for providing numbers to show
that the wrong empirical conclusion has NOT been drawn and that the
use case is NOT implicitly broken. The current draft does not show
the evidence while putting all the burden to the required side.
Seeing the controversy and varied opinions, I'm now feeling the best
thing we can do is to simply list the issues and controversy regarding
the use of reverse mappings without any specific recommendation (at
least about whether an IP address holder should provide reverse
mappings).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
