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

[Scott Kitterman]

On Thursday 19 April 2007 19:08, Hallam-Baker, Phillip wrote:
> > [mailto:ietf-dkim-bounces at mipassoc.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