Subject: Re: [DNSOP] Proposed text for reverse-mapping-considerations draft

From: Dean Anderson <[email-masked]>
Date: Fri, 1 Jun 2007 00:07:48 -0400 (EDT)

On Thu, 31 May 2007, Andrew Sullivan wrote:
> 
> The popular TCP Wrapper package was originally conceived to discover
> the network location of an attacker [Venema1992].  It used the reverse
> mapping of a connecting host to provide the hostname of that host in
> its output.

No. Early TCP wrappers just provided logs of activity, and then later to
provide access control. 

 "This paper presents a simple tool to monitor and control incoming
 network traffic. [...]

 "Services  such as finger do not
 require a password, and almost never keep a record of  their
 use.  That  explains  why  all  his  fingering  activity had
 remained unnoticed."

Access control:

 "5.  First extension: access control.
 [...]
     /etc/hosts.deny:

         ALL: terminus.lcs.mit.edu hilltop.rutgers.edu monk.rutgers.edu
         ALL: comserv.princeton.edu lewis-sri-gw.army.mil
         ALL: ruut.cc.ruu.nl 131.211.112.44
         ALL: tip-gsbi.stanford.edu
         ALL: tip-quada.stanford.edu
         ALL: s101-x25.stanford.edu
         ALL: tip-cdr.stanford.edu
         ALL: tip-cromemaa.stanford.edu
         ALL: tip-cromembb.stanford.edu
         ALL: tip-forsythe.stanford.edu"

TCP Wrappers did do access control based on reverse DNS, but that was
soon discovered to be insecure. I note that the original 1992 didn't
know that:

 "o    Protection against hosts that pretend to  have  someone
       elses  name  (name  server spoofing). This is important
       for network services  such  as  rsh  and  rlogin  whose
       authentication  scheme  is  based on host names. When a
       host name or address mismatch is detected  the  connec-
       tion  is  dropped  even before the access-control files
       are consulted."

The TCP wrapper program did not succeed at stopping nameserver spoofing,
nor could it. The author (Venema) just didn't know enough about DNS to
know that. This is the origin of the reverse DNS "security" myth.

Years and much effort has been expended to dispel the myth, but true
believers are hard to dissuade. That is a monument to something, but I
don't know what.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Dean Anderson <[email-masked]>
Date: Fri, 1 Jun 2007 00:07:48 -0400 (EDT)

Access control:

		--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 1 Jun 2007 10:42:19 -0400

Hello Dean,

On Fri, Jun 01, 2007 at 12:07:48AM -0400, Dean Anderson wrote:
> > the network location of an attacker [Venema1992].  
> 

You may have overlooked the sentence in the paper that says, "I
decided, however, that it would be more productive to maintain the
service and to find out where the finger requests were coming from."
(p1)  In any case, the distinction between "discover the network
location of an attacker" and "provide logs of activity" seems to me to
be mostly one of a matter of narravtive abstraction.  Given that this
is intended to be a quick narrative history, I think the "intentional"
level of abstraction is the right one, so I will leave this alone
unless I hear support from the Working Group for your alternative
gloss.

> nor could it. 

I don't believe anyone claimed it did; and if you have evidence that
the proposed text says it did, I would surely like to correct it.

> know that. This is the origin of the reverse DNS "security" myth.

What you regard as a myth others regard as a useful clue.  That's the
nice thing about the Internet: we can all use the information we get
out at the edges to do the things appropriate to our judgement and
conditions.  The caveat is that this requires smart, well-informed
operators who can agree to disagree about one another's practices, so
long as none of the practices are harmful.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 1 Jun 2007 10:42:19 -0400

Hello Dean,

A

---

From: Dean Anderson <[email-masked]>
Date: Sat, 2 Jun 2007 03:31:36 -0400 (EDT)

> service and to find out where the finger requests were coming from."

No; I looked further into the context of that statement, and I cited
that context to you in my previous message: The purpose of the TCP
Wrappers tool was to provide _logs_ for programs which didn't produce
logs and for which source code wasn't available.  I showed you the logs
produced by the tool which were given as examples in the paper.

My draft also points out the flaw of using Reverse DNS for logging, and
so the 1992 TCP-wrappers' tool is discredited in that regard.  This is a
major difference between our drafts: Your draft presents discredited
practices as credulous, while I provide the full context, including the
fact that these practices were discredited.

> What you regard as a myth others regard as a useful clue.

A "myth" is something which isn't true.  False claims can certainly be
useful clues, but only to identify those other dependent ideas that also
aren't true.

But I think the history of the Venema paper is probably important, and
I'm going to add it to my draft, as well.  Thanks for the suggestion.  
That was a very good item.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sat, 2 Jun 2007 03:31:36 -0400 (EDT)

--Dean

---

From: Robert Story <[email-masked]>
Date: Mon, 4 Jun 2007 08:12:24 -0400

On Thu, 31 May 2007 17:24:48 -0400 Andrew wrote:
AS> We received a suggestion that a short section outlining the history of
AS> the use of reverse mapping in security contexts would be a good thing
AS> to add to the reverse-mapping-considerations draft.  I have some
AS> proposed text to add.  Before I add it, I'd like to ask for comments.

I think it's useful, but I also think you should have a concluding
paragraph on why it's no longer a recommended practice. Something along
the lines of "as attack became more sophisticated, they included
spoofing reponses to reverse DNS requests, so the attacker appeared to
be coming from a trusted machine."

-- 
Robert Story
SPARTA

---

From: Robert Story <[email-masked]>
Date: Mon, 4 Jun 2007 08:12:24 -0400

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Jun 2007 09:37:15 -0400

> be coming from a trusted machine."

I believe notes to this effect have been in the draft all along, but
please check the -03 version (which should come out RSN) to make sure
the recommendations that are in it meet your criteria.  They belong in
a different section -- recommendations about what to do today.  This
history section is proposed to address the problem that some people
said they were having, which was that the discussion of the security
portion seemed to come from nowhere if you didn't already know why
people did it in the first place.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Jun 2007 09:37:15 -0400

A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Jun 2007 10:31:22 -0400

Hi Dean,

> produced by the tool which were given as examples in the paper.

As I said in my response already, I don't think this is different in
any way except the level of detail.  The point of getting the logs
was, as the paper says, to find out where on the network the
connection originated.  For the purposes of the draft, I think the
level of detail is enough.  The draft is already getting pretty long
given its topic, so I don't think I want to add the extra detail; but
if others disagree with me, I will cheerfully include your
suggestions.  (By the way, I appreciate that you are willing to
comment on the draft, since you said that there is no way it could be
modified to address your concerns.  But also due to that statement by
you, I believe we've been released from trying to address concerns you
raise, since every attempt is apparently guaranteed to fail.)

> fact that these practices were discredited.

I suppose you mean "credible"; I believe what the
reverse-mapping-considerations draft says is that in some
circumstances, it _is_ a credible practice.  As I've said before, this
is not "my draft" but the working group's; I'm just editing it.  The
feedback that I've received so far is broadly that there are cases
where using reverse mapping is a useful practice for them (although
there are some who disagree with that, such as you).  Since some of
that feedback comes from people who are apparently otherwise
competent to speak on these topics (e.g. they operate networks, they
write protocols, &c.), I take their remarks to be informed ones.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Jun 2007 10:31:22 -0400

Hi Dean,

A

---

From: Dean Anderson <[email-masked]>
Date: Mon, 4 Jun 2007 19:22:08 -0400 (EDT)

On Mon, 4 Jun 2007, Andrew Sullivan wrote:

> but if others disagree with me, I will cheerfully include your
> suggestions.

It seems others disagree.

> (By the way, I appreciate that you are willing to comment on the
> draft, since you said that there is no way it could be modified to
> address your concerns.  But also due to that statement by you, I
> believe we've been released from trying to address concerns you raise,
> since every attempt is apparently guaranteed to fail.)

Your failure to address concerns is up to you. Obviously, the draft CAN
be modified to address my concerns: Indeed, I wrote that modification in
draft-anderson-reverse-dns-status.

Rather, I don't believe __you__ will address the issues since it seems,
based on extended and repeated experiences, that your goal is to mislead
people about specific uses of reverse DNS, while simultaneously trying
to convince critics of the draft that their concerns have been addressed
and that discredited claims have been removed.  Again and again the
presence of discredited claims has been shown;  and again and again you
make trivial, gratuitous changes and report "all fixed!".  But it isn't
fixed.  7+ years this has gone on.  Some people are tired of it, but
getting tired doesn't mean anyone should give approval 'as is'.

> > practices as credulous, while I provide the full context, including
> > the fact that these practices were discredited.
> 
> I suppose you mean "credible"; 

You suppose wrongly.  "Credulous" means "inclined to believe, especially
on thin evidence". By contrast, "Credible" means "trustworthy,
believable".

> The feedback that I've received so far is broadly that there are cases
> there are some who disagree with that, such as you).

Wrong again. I've never said that reverse mapping isn't useful. I even
wrote a draft on Reverse DNS Status. Your report of my opinion isn't
accurate, and is misleading.

I (and others) have just said that claims of improved trust and (some
few other assumptions) have been discredited.  No one has long suggested
otherwise; it is a minority view, at best.  Even the people supporting
your draft, usually don't think it says what it actually says; they are
MISLED by assurances. But once they are explicitly shown all the
statements in the draft, and they put everything together and see the
presence of the discredited claims, they agree with me and disagree with
you.  In retrospect, your past assurances to remove discredited claims
hasn't been believable.

> As I've said before, this is not "my draft" but the working group's;
> I'm just editing it.

The group has repeatedly rejected the claims in the draft that "you just
edited" once it is detailed how the draft supports discredited claims.
Demonstrating the presence of the discredited claims sometimes takes
some effort to detail, but the group obviously doesn't support the
discredited claims you keep trying to work in [while simultaneously,
these last few years anyway, saying you aren't].

But, perhaps the draft does need a new editor. Or perhaps a new draft
(mine) should be used instead. I'd be happy to take over as editor of
the draft.

> Since some of that feedback comes from people who are apparently
> otherwise competent to speak on these topics (e.g. they operate
> networks, they write protocols, &c.), I take their remarks to be
> informed ones.

It isn't that __their__ opinions aren't informed. It's that __you__ take
their statements (and mine) out of context. It's that what you
__report__ about their opinions (and mine) is just wrong.

You would fail the MIT freshman advanced placement essay, which tests
incoming students for their ability to summarize 8 articles and report
the important points in the articles without attempting to persuade
anyone of a point of view.  You can't seem to do that. Whether that
failure reflects on writing skill or intention is unclear. But either
case is not fixable by the WG other than by finding a new editor and an
essentially new draft.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 4 Jun 2007 19:22:08 -0400 (EDT)

--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2007 12:13:43 -0400

Hi Dean,

> It seems others disagree.

On the point in question, I have received not a single indication of
agreement with your proposed text.  Until I do, I consider this topic
(and, therefore, this thread) closed.  I'm a little concerned about
some of the rest of the claims you make, however, so I want to reply
to them below.  I don't think a great deal of to and fro on what
appear to be mostly irrelevant topics serve the working group, so you
may consider this my last posting on this topic unless someone comes
up with some suggested changes to the text.

> draft-anderson-reverse-dns-status.

I believe you suggested that your draft should be considered entirely
alternate text.  That is not a modification of the text, it is a
wholesale replacement; and a replacement that engages (as I already
noted in my comments to you) a somewhat different set of topics than
the reverse-mapping-considerations draft.  That makes me believe that
your real claim is simply that the existing text is entirely wrong,
which entails that it cannot be repaired and has to be replaced.
Therefore, you are not engaged with _this_ text, but with some other one.

> and that discredited claims have been removed. 

To be clear: that is not my goal.  I'm also not entirely sure what
motivation has to do with the result, which is supposed to be a text
that stands on its own.  If I didn't know better, I would imagine you
to be attempting to impugn my character instead of addressing the
text.

> Again and again the presence of discredited claims has been shown;
> and again and again you make trivial, gratuitous changes and report
> "all fixed!".

I do not believe the changes to the draft that have been made in the
last year (I was only appointed to help edit this draft in July 2006,
I think the archive will show) have been trivial or gratuitous; I
believe the changes in fact alter the meaning of the draft.  They may
not completely alter the draft to say what everybody (you, for
instance) wants, but that is not the same thing as the changes being
trivial or gratuitous.

> I (and others) have just said that claims of improved trust 

You have repeated this charge several times, and I keep pointing out
that the draft does not in fact anywhere make the claims you seem to
be saying it does.  Your continued insistence on this point makes me
very suspicious of any claim you might make to have read and
understood the actual text.  It is hard to take seriously objections
that appear to be based on mis- or non-reading of the text.

> edited" once it is detailed how the draft supports discredited claims.

I am not sure what your evidence is for this claim (especially since
we have seen precisely one response so far to the -03 draft, and a
number of responses this year suggesting broad agreement with the -02
draft).  If you wish to press that claim, I would urge you to point me
to the mailing list messages that support your view.

> these last few years anyway, saying you aren't].

The remark in brackets there makes me suspect you have me confused
with someone else.  I think it is probably worth making the discussion
a little less personal, so I actually don't care who you think I am.
But it doesn't serve anyone to muddle the discussion with claims about
what I have been doing for "the last few years" in respect of this draft.

> anyone of a point of view. 

I am pleased to congratulate you on your appointment to the entry
and placement committee at MIT!

Best regards,

Andrew

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2007 12:13:43 -0400

Hi Dean,

Best regards,

Andrew

---

From: Dean Anderson <[email-masked]>
Date: Tue, 5 Jun 2007 18:07:25 -0400 (EDT)

I urge people to support my draft (draft-anderson-reverse-dns-status).
My draft encourages Reverse DNS, improves understanding of Reverse DNS,
informs about discredited practices, and recommends good practices.  My
draft accomplishes the purpose charted by the WG much better than the
Sullivan draft and doesn't have any of the drawbacks of Sullivan's
draft.

Inline

On Tue, 5 Jun 2007, Andrew Sullivan wrote:

> the reverse-mapping-considerations draft.

I (Anderson) copied some text from Sullivan's draft, and rewrote those
parts that were wrong, and I included some information about Reverse DNS
that was informative. So my draft really just has an entirely different
editor.  My draft engages in the topic that the working group decided to
work on: Encouraging Reverse DNS.  I agree Sullivan's draft has a
slightly different set of topics that deviates from the topic of
Encouraging DNS IN-ADDR as charted by the WG.

> To be clear: that is not my goal.  

That leaves a lack of writing skills as the cause of the problems.  But
there is a element of willfulness over the repeated experiences that
can't be entirely ignored.  But I do agree we are not here to teach
writing skills; Just to diagnose the problem that prevents effective
writing of the draft and correct that problem.  Once we conclude there
is a problem, we don't need to further investigate the root causes of
the problem.

> I'm also not entirely sure what motivation has to do with the result,
> which is supposed to be a text that stands on its own.  If I didn't
> know better, I would imagine you to be attempting to impugn my
> character instead of addressing the text.

I'm disputing Sullivan's abilities and disposition to correctly report
facts, statements, and opinions of others. Those abilities are relevant
and requisite skills for the task of editing this draft.

> > The group has repeatedly rejected the claims in the draft that "you
> > just edited" once it is detailed how the draft supports discredited
> > claims.
> 

I think Mr. Sullivan well knows the history of this draft from its
previous incarnation as the draft-ietf-dnsop-inaddr-required, and
Sullivan knows that the version number was reset when the draft was
renamed and re-submitted under the new name. Sullivan knows that the
name was changed to address concerns about the implication of the name,
even after explicit calls to 'require in-addr' were supposedly removed
from the draft. Sullivan knows that the WG didn't support that the
notion that inaddr was required, nor did it support any other
discredited notions.  So Mr. Sullivan knows the past claims that were
very explicitly rejected.  This is yet another example of a failure to
report accurately.

Indeed, The history of the in-addr draft dates back to 2000:

Robert Elz stated it best (7 years ago and still relevant): 8/13/2000
http://www1.ietf.org/mail-archive/web/dnsop/current/msg00544.html

"Sorry people, this draft is a total waste of time.

"I'm an absolute supporter of properly running in-addr.arpa domains,
and if someone wanted to write an RFC to explain to people what they're
useful for, and why the data needs to be maintained, that would be 
fine."

For 7 years, we've had the same argument, as advocates try to mislead
people about the contents of the draft, and people (such as myself, Elz,
and a host of others) have picked up each new draft to find essentially
the same set of discredited claims.  So, I finally wrote a draft that
says the right things.

BTW, these same 'broad statements of support' for the purposes of
Sullivan's draft, (similar to Elz's quoted above) can also be considered
to support the statements in my draft as well:

  People support status and encouragement of Reverse DNS.

  People don't support the claims that either depend on false
assumptions, discredited practices, or require in-addr.arpa.
 
Indeed, a serious problem is that people don't understand that they have
been misled about the contents of Sullivan's draft; instead people,
(rather like Elz in 2000, support honest information; to the extent they
have been misled, people think Sullivan et al aren't trying to require
in-addr or advocate discredited practices.  When it is pointed out to
them how each new version still does that, they are then against
Sullivan's draft.

In fact, there is hardly a person who supports the discredited practices
that Sullivan promotes in his draft while assuring people his draft
doesn't promote such practices. Sullivan has just misled people with
false assurances of "its fixed!", when its not fixed.

My draft and Sullivan's draft say very different things.  Anyone who
reads my draft, and thinks it basically the same as Sullivan's draft,
has greatly misunderstood Sullivan's draft.  I think most people will
agree with my draft; certainly, no one is misled by the plain clear
language in my draft.

> I am pleased to congratulate you on your appointment to the entry and
> placement committee at MIT!

Yet another false report from Mr. Sullivan. I suppose that report, too,
needs to be discredited: I am not on the placement committee at MIT.  
However, I know some of the people who evaluate the advanced placement
essays for MIT and sometimes for other universities.  I do not see the
individual essays, but I know how the system works.  There was nothing
in the previous text that would imply that I am on the 'entry and
placement committee at MIT'. The false report is yet another example of
the willful refusal or inability of Mr. Sullivan to accurately report on
the statements of others. It rather proves my assertion about Mr.  
Sullivan's abilities or disposition, though. Of course, so does the
previous litany of misrepresentations, such as Sullivan's recent false
report that I don't think Reverse DNS to be useful. I (like Elz and
many, many others), just don't think it is useful for trust purposes and
object to the false assumptions and discredited practices that Sullivan
presents as credulous.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 5 Jun 2007 18:07:25 -0400 (EDT)

Inline

 

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 6 Jun 2007 14:29:41 -0400 (EDT)

> very explicitly rejected.  This is yet another example of a failure to

BTW, here is part of an off-list message from Ted Lemon in 2005, that is
very much in the line of the continuous problems with this draft.  The
current draft still has this same problem---In the intervening two
years, the draft has just been rewritten in different ways to say the
same thing after objections are raised, and then Sullivan reports "all
fixed!", but it isn't fixed.

Ted writes below: "... I definitely want to make sure the document
doesn't give anybody the impression that using in-addr for security is
anything but a complete crock, or, as you say, an actual vulnerability."

By the way, I contacted Dr. Venema who also agrees, and doesn't want to
become known as the originator of the myth of reverse DNS security. 

		--Dean

---------- Forwarded message ----------
Date: Fri, 1 Apr 2005 18:01:58 -0700
From: Ted Lemon <[email-masked]>
To: Dean Anderson <[email-masked]>
Subject: Re: [dnsop] Tangible harm caused by in-addr-required draft

On Apr 1, 2005, at 3:19 PM, Dean Anderson wrote:
> Page 2 is full of it. I'll just give one example:
>
>    Some applications use DNS lookups for security checks. To ensure
>    validity of claimed names, some applications will look up IN-ADDR
>    records to get names, and then look up the resultant name to see if
>    it maps back to the address originally known. Failure to resolve
>    matching names is seen as a potential security concern.
> "Failure to resolve matching names is seen as a potential security
> concern"
>
> Basically, this says its ok to use in-addr based security, and if they
> don't match, that's a "security concern".
>
> In other words, matching in-addr is required.

This is a legitimate, specific criticism.  One that I haven't seen from
you before on the mailing list.  I very much support fixing cases where
the text can be misread in the way you suggest.  It would be disastrous
if someone read the document the way you suggest, and I can see where
someone could make that mistake, although it wasn't obvious to me until
you pointed it out.  If you could send a complete set of such changes to
the mailing list, I will support you in getting them done - if it
doesn't work on the list, I can talk to the authors in Paris.  I'm not
going to support you retargeting the document entirely, but I definitely
want to make sure the document doesn't give anybody the impression that
using in-addr for security is anything but a complete crock, or, as you
say, an actual vulnerability.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 6 Jun 2007 14:29:41 -0400 (EDT)

--Dean