On Mon, Mar 19, 2007 at 11:06:48PM +0100, Ted Lemon wrote:
> Fortunately, in a spam scoring system, as long as you don't use this
> as your exclusive score, it's probably okay - hopefully other
> indicators will tell you a different story.
Right; this is why I think the "security" and "utility" questions
can't be answered in a binary way. Sometimes the answer depends very
much on what _else_ you know. It's clear to me, though (from your
very helpful remarks as well as from some other comments that I've
received) that such a message just isn't clear enough in the draft as
it stands, which is why we need another round.
> and how many are unreasonable, like my ssh example? If the number
> of the latter is not zero, that might explain the pushback you've
> been seeing.
Yes, I think you're right, and I appreciate the observation. (And
certainly, the number of unreasonable uses is not zero, or we would
have found consensus long ago.)
> The cure is for us to think about this and modify the document
> accordingly, not for you to explain here on the mailing list what
> you meant.
No question. My point in explaining here what I meant is rather to
see if a different expression of my meaning makes that meaning clearer
to others, because that gives starting points for what text can
improve the draft. I really appreciate the feedback, since it enables
me to focus more carefully on the places where my own poor edits to
the draft have obscured meaning or have sent the wrong message.
In that spirit, let me ask whether including the following
notions (not yet actual text for inclusion) would help:
1. An attempt to use reverse mappings as a single-source authentication
or security mechanism is almost always a very bad idea, and may
actually undermine better security or authentication
practices. [How do we make the text say this more clearly? I
thought it already says this plainly in some places, but I guess
not.]
2. Some people report that using evaluation of the reverse mapping
(either for existence or matching) is sometimes useful, especially
in the presence of other data about the connecting host. [Also,
does a DNSSEC-enabled reverse tree help here? Perhaps concrete
examples would be more helpful? I'm leery of the latter, because
the state of affairs in this area is liable to change.]
3. In most cases, a weaker reliance on reverse mapping tests will
yield better results, because the risk of false positives (and the
consequent failure modes) is lower.
4. The [potential?] utility of the reverse tree to all users of the
Internet declines as fewer people implement reverse mappings. [I
think this is implicit throughout the draft, but it maybe needs to
be stated baldly?]
5. Maintaining reverse mappings (especially matching reverse
mappings) is not free for operators of networks, and in some cases
that cost may outweigh the benefit to anyone, such as is the case
where the number of entries cause the query response to require
truncation.
Someone also hinted to me that a new section comprising a short survey
of the history of some practices -- especially those that now fall
into the category of "obviously bad" -- would help frame the
discussion. Do people think that would be useful? (I worry it could
be a rathole out of which the draft would never emerge, but I
nevertheless see how it could clear up confusion for operators who
don't care what an IETF is, but are looking for guidance on what to
do and why something they heard about once as a good idea is no longer
widely viewed as helpful.)
Thank you very much for the comments and insights.
A
--
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<[EMAIL PROTECTED]> M2P 2A8
jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
