[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.
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.
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.
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.
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.
Nor do I see the logic in employing a heuristic tree walk rather than doing the
job properly.
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.
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.
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?
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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html