On Thursday 19 April 2007 19:08, Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott
Kitterman
Additional arguement Con is that a new RR type takes a LONG
time to deploy.
In 2 - 5 years when this new RR type is deployed, whatever
problem it was trying to solve will likely be solved some other way.
The idea here is to balance the political constraints as well as the
technical.
People seem to demand that we have a new RR. There are four choices:
1) Ignore them and plough on regardless (from a technical point of view PTR
records would serve as well as XPTR)
2) Begin using TXT records but promise to transition to a new RR at some
future date
3) Accept a new RR to support wildcard capability
4) Accept a new RR to publish all policies.
The astute will recognize that option 2 results in the same exact outcome
as option 1. Once there is infrastructure deployed to support TXT nobody is
ever going to transition away from it. Option 2 results in the absolute
worst case outcome, we end up supporting two parallel infrastructures for
publishing the same data.
Yes. This is what was done for SPF and Type99 has essentially zero deployment
and is likely to stay that way. In fact, in the latest release of the Python
SPF library we disabled Type99 lookups by default since it was just causing
wasted DNS queries.
Option 4 is the next worst option, measurement of the number of Windows DNS
servers out there shows that the number is significant. While it is
possible to cause the Windows DNS server to emit the bit sequences for new
RRs the procedure required to do so cannot possibly be considered to be
acceptable as an administration option. Windows is a GUI based O/S and
there is no support in the GUI for new RR types. Nor is there support to
save a zone file with new RR types.
In my view, if we are going to do option 4, we as well save ourselves a lot of
trouble and pack up now and go home. It'll never get deployed. Some may not
care if the product of the WG is actually deployable, but I've got better
things to do with my time.
So that leaves us with options 1 and 3.
XPTR could be realized using PTR records. This was my original proposal. It
is a viable technical proposal but it does redefine the semantics of an
existing record. This usage does not cause conflict with any sanctioned
uses but it might well conflict with non sanctioned uses.
I think that shouldn't block it. A larger concern would be would
non-sanctioned uses interfere with this proposal. Does anyone know of
non-sanctioned uses of PTR?
My concern here is to make DKIM work as well as possible with the DNS
_as_it_is_today_. So the concerns raised in the DNSEXT group appear to me
to be reasonable.
OK. I agree with work as well as possible with today.
XPTR is more efficient than any of the tree walking schemes proposed. In
normal use the search will terminate in one or two steps. The only case
where three steps are required is if the attacker decides to attempt a
particular attack that they do not currently have an incentive to attempt
and is certain to fail. Ergo I do not accept Jim's claim that the
possibility of a third lookup should be considered a performance hit
against XPTR.
In the scheme of DNS and mail, I don't think this is a significant issue.
Nor do I see the logic in employing a heuristic tree walk rather than doing
the job properly.
I think this has been explored in the past and has been found wanting. Let's
not waste our time revisting it.
The DNSEXT group has every reason to accept the XPTR proposal when it
receives the draft next week. It has been stated repeatedly that it is
going to be easy to obtain new RRs. The XPTR feature will only be
applicable to a prefix record if the prefix search strategy states that it
is to be applicable. Moreover to reject XPTR would force me to employ PTR
for the same purpose.
Yes, but that's but the first step. So far I don't see a measurable downside
to PTR. How long from WG approval is it to deployed in the DNS
infrastructure?
More importantly XPTR provides a generic solution to the wider problem of
heuristic hunt and peck discovery schemes that are causing real problems
for core DNS. Half the DNS traffic is due to attacks. The other half is due
to misconfigured servers. Legitimate use is essentially a rounding error.
Then this idea should proceed independent of this WG. Perhaps in this WG we
use PTR now with the idea of migrating to XPTR when the policy protocol moves
along through the standards process IF XPTR is deployed. In a reply to
another part of this message:
I think the burden here is to prove that a new RR Type is
both needed and deployable, not desirable and will get out
there someday.
You said:
I think it is an entirely rational concern.
At this point, I can see XPTR would be handy for this WG, but not NEEDED. If
it solves a general class of problem, I'd say let it go solve that problem
and a future WG can leverage it's success. There's no demonstrated need to
depend on it.
Why should the DNSEXT working group be less willing to accept a solution
that takes their architectural concerns seriously and attampts to deal with
them in depth than one which represents yet another point solution?
Working Groups are, by charter, in the point solution business. Solving the
general problem you are trying to solve sounds like a good thing to do, but
it's not this Working Group's problem to solve.
We have to get along here with the rest of the IETF. That is the point of
being in the IETF rather than OASIS. Getting along means taking real
architectural principles and operational concerns seriously. It also means
taking seriously the IETF wide concern that deployment of DNSSEC should be
a priority. Getting along does not mean surrender or automatic compromise.
Yes, but none of that clearly drives this WG to XPTR instead of PTR. Maybe
I'm just not getting your point, but the only technical argument I see you
making for XPTR over PTR is:
This usage ... might well conflict with non sanctioned uses.
Might be a problem with some undocumented something really doesn't mean much.
Unless you know of unsanctioned uses that conflict, this same argument can be
made against anything. Someone MIGHT already be using _dkim.example.com for
some other non-sanctioned use.
I think this is headed in the right direction, but I'd like to understand
better your concerns about just using PTR.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html