ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] New Issue: Use of XPTR records in SSP

2007-04-19 16:14:52
[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