On Wed, 14 Feb 2007, Ted Lemon wrote:
> On Feb 14, 2007, at 10:17 PM, Dean Anderson wrote:
> > Basically, many people have greatly misunderstood this document,
>
> That people have misunderstood the document is your assertion, which
> may or may not be true. That people agree that using in-addr for
> security is clearly true, as your quotations suggest. However, your
> primary assertion - that people have misunderstood the document in
> the way that you assert - remains unproven.
It certainly has been proven, repeatedly over the last 7 years that this
draft has been on the table. They have two issues that don't belong, and
which they keep trying to put in:
1 in-addr should be required.
2 forward/reverse checking is a legitimate security test.
Over the course of 7 years, The authors first said these things bluntly
in draft-in-addr-required, with a title that said in-addr was required.
That was rejected by the Working Group. Since then, they have
alternately said that they aren't making these claims, and then when
called to task--'here are the claims again in your document'--they say,
as recently, that they want to encourage this viewpoint. Rather that
giving a rational, logical reason for their views, they have argued that
one is __entitled__ to act without a rational basis. That is,
irrationally. Of course, the IETF should not encourage irrational
behavior by allowing it to be implied to be rational.
My point that a number of people (that includes Ted Lemon in particular)
have misunderstood the the document was proven (in particular to Ted
Lemon) in 2005. Apparently you (Ted) have no memory of our last
conversation on this subject in 2005: You agreed in 2005 that people
misunderstood the document as I had said in 2005:
You said then:
==================
Re: [dnsop] Tangible harm caused by in-addr-required draft
by Ted Lemon Fri, 1 Apr 2005
"> Dean Anderson writes:
> 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. [...]"
==================
You said 'This is a legitimate, specific criticism'. I had been saying
that all along in 2005, but apparently you didn't understand that then,
as you apparently don't understand it now. But I eventually did get the
point across to you in 2005. I hope to get it across again. If you need
more of the conversation to jog your memory, I'll be happy to give links
to the original messages.
But, maybe I've assumed to much. I'll try to make it more explicit:
The document _still_ seeks to make the in-addr map required, and _still_
seeks to describe in-addr mapping as useful for security purposes.
Persons reading this document, especially those persons inexperienced
with the past history of these claims, will get the idea that these
practices are required, and that in-addr is useful for security
purposes.
I note this text from Section 4, 4th paragraph, 1st sentence:
"All IP addresses in use within a block should have a reverse
mapping."
This is the old in-addr-is-required claim. If in-addr really is
required, why make them change the title and even the document name?
This statement, in conjunction with the advocacy that missing reverse
DNS is a legitimate security concern, implies that in-addr is required.
Take this example from Section 3.1, Second paragraph:
Some applications use DNS lookups for security checks. To ensure
validity of claimed names, some applications will look up records in
the reverse tree 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 interpreted as a potential security
concern.
Most people would read this as an endorsement of the use of DNS for
security checks. It implies there is some legitimacy to this practice.
Further, it implies that operator has no choice. I know of no
applications which perform such a check without a configurable choice.
The only example was TCP wrappers, which _can_be_ configured this way.
Look at the last sentence:
"Failure to resolve matching names is interpreted as a potential
security concern".
Thats the same old thing as before.
How about the phrase "To ensure validity"? How is validity ensured?
If the first DNS query was faked [by a variety of methods, including
brute force or inline sniffing], how is it now the second one is
trustworthy? Obviously, it isn't, and just as obviously there is no
validity or legitimacy to the claim. Kevin Darcy had it right in 2001,
this draft is no good.
This is the same notion of 'legitimate security concern' that
in-addr-required had in 2005, for which you then said was a legitimate
complaint about the draft. The draft is __filled__ with this kind of
stuff.
This is a good point to note that the draft claims in Section 3.1:
"Some anti-spam (anti junk email) systems use the reverse tree to
verify the presence of a PTR record, or validate the PTR value points
back to the same address as the system originating the mail. Some
mail servers have the ability to perform such checks at the time of
negotiation, and to reject all mail from hosts that do not have
matching reverse mappings for their hostnames. These PTR checks
sometimes include databases of well-known conventions for "generic
naming" conventions (for example, PTR records for dynamically-
assigned hostnames and IP addresses), and sometimes allow complicated
rules for quarantining or filtering mail from unknown or suspect
sources. Even very large ISPs may reserve the right to refuse mail
from hosts without a reverse mapping."
Note that the 'dialup' in the name (Robert Story's example, which you
noted was unreasonable) is a "generic naming" convention. [I note that
not even the authors do this.**]
Note the last sentence:
"Even very large ISPs may reserve the right to refuse mail from hosts
without a reverse mapping."
Most people would read this as saying that large ISPs refuse mail from
hosts without a reverse mapping, which just isn't so. [again, neither
of the authors' refuse mail based on missing reverse mapping.**]
A close parsing of the sentence, however, shows it to be entirely
meaningless: 'Even very large ISPs' _could_ reserve the right to do just
about anything--Indeed, any one can _reserve_ any right. Its the
exercise that may cause problems. Such meaningless statements should be
removed, especially where they are very likely to be misread. Have you
really read the draft to identify and remove such statements? [Btw, to
"critically read" a document, means you are supposed to search out
ambiguities in the document, identify for removal or rewording such
meaningless sentences that will be misparsed and misread; Find things
that different people might take to mean different things; To critique
the document.]
For the previous draft, I posted a list of such dubious claims, but
received no response justifying the claims. This new draft was posted
that contained basically the same dubious claims slightly reworded, but
with the same objected implications as before, on the assurance that
objections had been addressed. Obviously, they keep trying to work in
the same two objectionable ideas. Those ideas don't belong in the
document.
Just because the same dubious claims keep being resubmitted does not
mean this Working Group should just approve the draft. It could also
start refusing to consider new drafts from these authors. The authors
obviously refuse to remove the objected notions.
I argued in 2003 that we shouldn't accept any more drafts on the
subject, but Ed Lewis stated then that there is an interest and a need
for a report on the current state of affairs. I can accept a report on
the current state of affairs, but I can't accept the two false premises
the authors keep trying to more or less sureptitiously work into the
document in various ways.
I think the onus is not on me to prove that each subsequent new document
contains similar statements as previously, but should be on the authors
to prove that it doesn't----that they actually removed objectionable
statements and claims.
The reason I'm writing an alternate draft is that many people, myself
included, think there should be some statement about the current state
of affairs. My draft will omit the agenda of trying to legitimize
irrational reverse-mapping claims of zealots, and instead show why
commonly occuring irrational claims about reverse mapping are not
rational and should be discouraged.
--Dean
** I took off the reverse mapping for cirrus, and did some testing:
[EMAIL PROTECTED] tmp]# dig mx senie.com
; <<>> DiG 9.2.1 <<>> mx senie.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56611
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;senie.com. IN MX
;; ANSWER SECTION:
senie.com. 3600 IN MX 5 mxb.amaranth.net.
;; Query time: 211 msec
;; SERVER: 130.105.11.3#53(130.105.11.3)
;; WHEN: Fri Feb 16 11:19:30 2007
;; MSG SIZE rcvd: 59
telnet mxb.amaranth.net. 25
Trying 204.10.1.19...
Connected to mxb.amaranth.net..
Escape character is '^]'.
220 mxb.amaranth.net ESMTP (44a2b828e188d015a20a7f64ac843dc6)
helo av8.net
250 mxb.amaranth.net
mail from: <[EMAIL PROTECTED]>
250 Ok
rcpt to: <[EMAIL PROTECTED]>
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
Hi Dan. Just testing.
--Dean
.
250 Ok: queued as 24D2B53F3
dig mx ca.afilias.info
; <<>> DiG 9.2.1 <<>> mx ca.afilias.info
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23227
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ca.afilias.info. IN MX
;; ANSWER SECTION:
ca.afilias.info. 300 IN MX 20
antispam2.afilias.info.
ca.afilias.info. 300 IN MX 10
antispam.afilias.info.
;; Query time: 100 msec
;; SERVER: 198.3.136.10#53(198.3.136.10)
;; WHEN: Fri Feb 16 11:21:31 2007
;; MSG SIZE rcvd: 84
[EMAIL PROTECTED] tmp]# telnet antispam.afilias.info 25
Trying 207.219.45.36...
Connected to antispam.afilias.info.
Escape character is '^]'.
220 antispam.ca.afilias.info ESMTP (89f05a796082cd6312c69e8fa318f08f)
helo av8.net
250 antispam.ca.afilias.info
mail from: <[EMAIL PROTECTED]>
250 Ok
rcpt to: <[EMAIL PROTECTED]>
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
Hi Andrew. Just testing.
--Dean
.
250 Ok: queued as DCC3285DD
quit
221 Bye
Connection closed by foreign host.
[EMAIL PROTECTED] tmp]# dig cirrus.av8.net
; <<>> DiG 9.2.1 <<>> cirrus.av8.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36728
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;cirrus.av8.net. IN A
;; ANSWER SECTION:
cirrus.av8.net. 3600 IN A 130.105.36.66
;; Query time: 8 msec
;; SERVER: 198.3.136.10#53(198.3.136.10)
;; WHEN: Fri Feb 16 11:24:30 2007
;; MSG SIZE rcvd: 48
[EMAIL PROTECTED] tmp]# dig -x 130.105.36.66
; <<>> DiG 9.2.1 <<>> -x 130.105.36.66
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46245
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;66.36.105.130.in-addr.arpa. IN PTR
;; Query time: 9 msec
;; SERVER: 198.3.136.10#53(198.3.136.10)
;; WHEN: Fri Feb 16 11:24:42 2007
;; MSG SIZE rcvd: 44
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
