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

From: Jim Fenton <[email-masked]>
Date: Mon, 16 Apr 2007 17:34:04 -0700

This is the first of a few issues that come in trying to rationalize at
least two of the SSP proposals, draft-hallambaker-dkimpolicy-00 and
draft-allman-dkim-ssp.  I'd like to keep the issues separate, because I
think they're largely independent, so please respond in kind if at all
possible.

=====

Phill Hallam-Baker has proposed the publication of a new PTR-like  RR
type, tentatively called XPTR, in order to improve the scalability of
the SSP mechanism to a large number (~1000?) of additional types of
policy in the future.  To look up the signing policy of example.com, the
sequence would be:

1.    Query for XPTR record for example.com.  If result is an NXDOMAIN
error, the domain does not exist.  If result is a NODATA error, either
the policy or the domain does not exist.
2.    Query for [RRtype TBD; separate issue] record for
_dkimpolicy.{result of XPTR query}; policy record is stored at that
location.

Argument Pro:  Supports a potentially very large number of policies, as
might be needed for WS-* (for example) in the future.  Permits a central
point of control and modification for policies relating to different
classes of nodes in the domain.

Argument Con: Requires an additional lookup per query; other types of
policy are out of scope for the WG.

My personal opinion is along the lines of "Argument Con", that it is not
up to the DKIM Working Group to define a fully general policy
mechanism.  There may be good arguments for IETF to charter some work in
this area, but that's a much larger question than this WG and
undoubtedly a much more time-consuming one as well.

-Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Apr 2007 02:41:16 -0400

> policy are out of scope for the WG.
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.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Apr 2007 09:42:08 -0700

On Apr 16, 2007, at 5:34 PM, Jim Fenton wrote:

> This is the first of a few issues that come in trying to  
> rationalize at least two of the SSP proposals, draft-hallambaker- 
> dkimpolicy-00 and draft-allman-dkim-ssp.  I'd like to keep the  
> issues separate, because I think they're largely independent, so  
> please respond in kind if at all possible.

This assumes a simple authorization scheme is not effective at  
protecting a principal domain.  For example, if the industry creates  
a list of domains used for the purpose of registries, then this would  
identify precisely which domain should be queried.  As there are some  
TLDs publishing MX records, such a list becomes even more important  
from the prospect of limiting the scope of TLDs with respect to DKIM  
sub-domain validations.

> policy are out of scope for the WG.

This is a clever idea, but perhaps a bit late in DNS's evolution.   
The additional overhead is unlikely to become automated, or even  
supported within the corporate environment.  From a DDoS perspective,  
any wildcard scheme can be perilous.

As an industry, establish a list of domains used by registries.  This  
approach facilitates rapid discovery of any number of record types,  
and not just policy related records.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Apr 2007 22:54:27 +0200

Jim Fenton wrote:

> up to the DKIM Working Group to define a fully general policy mechanism.

I kind of like the concept, but unfortunately I haven't the time at the
moment to find out why this couldn't be somehow built on top of U/S-NAPTR

> There may be good arguments for IETF to charter some work in this area,
> but that's a much larger question than this WG and undoubtedly a much
> more time-consuming one as well.

<sigh />  Without knowing it you might have repeated a MARID argument.

Frank

---

From: Jim Fenton <[email-masked]>
Date: Tue, 17 Apr 2007 20:35:36 -0700

Douglas Otis wrote:
>> This is the first of a few issues that come in trying to rationalize
>> at least two of the SSP proposals, draft-hallambaker-dkimpolicy-00
>> and draft-allman-dkim-ssp.  I'd like to keep the issues separate,
>> because I think they're largely independent, so please respond in
>> kind if at all possible.
>
> protecting a principal domain.  For example, if the industry creates a
> list of domains used for the purpose of registries, then this would

I'm not clear on specifically who "the industry" is that you're
referring to that creates and maintains the list.  It sounds like you're
proposing some other kind of non-self-published database that identifies
mailing domains.  It doesn't sound like the SSP of which we just
completed the last-call of the requirements document.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 17 Apr 2007 20:26:23 -0700

> moment to find out why this couldn't be somehow built on top of U/S-NAPTR

Phill should probably be the one to comment directly on the reason for
the new XPTR record type, but I'm under the impression that he's trying
to avoid conflict with existing uses of PTR.  I, at least, had not
considered use of NAPTR here; can you outline how it might work?
> <sigh />  Without knowing it you might have repeated a MARID argument.

I suspect I may have.  Are you suggesting we take this on?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 17 Apr 2007 20:40:13 -0700

> trying to solve will likely be solved some other way.

I know this has come up before; I have long been searching for specifics
on what needs to be updated.  Name servers?  Resolvers?  Caches?  I know
you can do this today with current and recent versions of BIND.  I have
heard that some Microsoft products may have problems with new RR types,
but real facts have been elusive.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2007 00:13:20 -0400

> but real facts have been elusive.
The only recent parallel that I'm aware of if the new RR Type for SPF.  It 
will be two years ago in July when the type was assigned.  Within a week of 
the assignment a few domains where publishing Type 99 records (and those of 
us that maintain the Python SPF library had Type 99 support implemented in 
about the same amount of time).   So, yes.  Rapid deployment for test use is 
possible.

That is not the same thing as something that gets deployed for production use.  
The first version of BIND that natively supports Type SPF was just recently 
released.

I think that the reality is that unless a new RR type is the only possible 
solution to a pressing problem, the internet will just route around the 
roadblock and solve the problem another way.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2007 00:47:32 -0400

On Wednesday 18 April 2007 00:29, Steve Atkins wrote:

> At that point the only thing the new RR adds is the requirement to
> do two DNS queries, rather than one, as you'll still need to be checking
> TXT forever.
>
> When the issue has come up before the usual problem that's claimed
> is not dns servers or resolvers, so much as management software,
> web interfaces to manage dns records and so on. I don't really
> buy that, but it's something that probably needs to be answered.
>
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.

New RR types are easy is an interesting theory, but unproven.

The only problem I see a new RR type solving is wildcarding.  I just don't see 
it as being a significant use case.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Tue, 17 Apr 2007 22:03:13 -0700

(Sorry for the duplicate, Scott. I bet you wondered why I mailed
you off-list to agree with you. :) ).

> The first version of BIND that natively supports Type SPF was just  

But there was much less urgency for that as nobody will ever need
to use it. For SPF TXT records are there, and they work today. If the
RR support were needed before the protocol could be deployed the RR  
support
would deploy sooner (and the protocol support later).

> roadblock and solve the problem another way.

The alternative phrasing is that if you cobble together some pseudo- 
syntax
and stuff it in a TXT record "just until you get a real RR" then you'll
have a deployed base of TXT records and never move it all over to
the new RR.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Apr 2007 10:13:53 -0700

On Apr 17, 2007, at 8:35 PM, Jim Fenton wrote:
>> protecting a principal domain.  For example, if the industry  
>> creates a list of domains used for the purpose of registries, then  
>> this would identify precisely which domain should be queried.  As  
>> there are some TLDs publishing MX records, such a list becomes  
>> even more important from the prospect of limiting the scope of  
>> TLDs with respect to DKIM sub-domain validations.
>
> referring to that creates and maintains the list.  It sounds like  
> you're proposing some other kind of non-self-published database  
> that identifies mailing domains.  It doesn't sound like the SSP of  
> which we just completed the last-call of the requirements document.

The DKIM base specification already establishes an expectation of  
there being a general agreement upon what is a TLD domain.  Proper  
use of DKIM must also consider second level domains as well, to avoid  
errant registries publishing DKIM keys for questionable purposes.   
There are already a few publishing seemly broken MX records.

DKIM also depends upon domain reputations, instead of just IP address  
reputations.

Consider how one might wish to implement such a domain reputation query.

With a daily churn of millions of new domains, there can be no prior  
knowledge of who the bad actors are by name.  One would not want a  
cache flooded with the garbage created by spammers using random sub- 
domains.  The query must be required to stop at the principal domain  
to protect a reputation service cache.  The cost of the network  
traffic related to such a service is not cheap, where caches are  
essential.

This form of reputation exploitation is enabled by wildcard MX  
records.  In this respect, the wildcard MX has proven to be a bad  
idea.  Wildcard MX records allow those few with MDAs to process  
domains and local-parts in clever ways, but is that really worth the  
trouble that it creates?  What percentage of email depends upon  
wildcard MX records that can not be easily accommodated with static  
records.

I can inquire as to whether our company would be willing to offer  
this as a service, if this sounds like a good approach.  They do wish  
to support DKIM.  I am sure others would join such an effort.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Apr 2007 20:08:05 +0200

> considered use of NAPTR here; can you outline how it might work?

Sorry, no, that's why I said that I'm lost with DNS issues, and haven't
the time to learn more about it.  The U/S-NAPTR records allow to locate
"services" somehow starting from a given name, and at the end you could
get an address record plus a protocol to use.  For our purposes here we
would need a TXT record with the signing policy at the end.  Or maybe
the address of a Web server hosting the signing policy, I can't tell...

   [Phil's proposal]
>>> that's a much larger question than this WG and undoubtedly a much

> I suspect I may have.  Are you suggesting we take this on?

Really, I can't judge it.  Whatever the folks here decide, please check
it with some "namedroppers" before we waste months revisiting ratholes.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Apr 2007 11:51:40 -0700

On Apr 18, 2007, at 11:08 AM, Frank Ellermann wrote:

> Really, I can't judge it.  Whatever the folks here decide, please  
> check it with some "namedroppers" before we waste months revisiting  
> ratholes.

Aside from a few issues remaining with DNSSEC, such as DLV, little  
seems to show up on the radar.

There were several major players to claim a lack of interest in re- 
visiting automation of a new type of wildcard.  Whether that  
qualifies as a rathole or fatigue, it is hard to tell.  A new DNS  
mechanism offering protocol policy requires extensive review, but  
this seems highly unlikely.

DKIM protection requires:

1) Trust established with the signing domain.
2) Clearly marked messages validated by trusted signing domains.

SSP plays _no_ role in providing either of these critical points now  
offered by existing plugins.

The general assumption driving SSP is that it provides a means to  
reject non-complaint messages at the MTA.

Rejection at the MTA offers an allusion of protection.  Protection  
through rejection alone remains prone to look-alike and cousin domain  
exploits, growing ever more problematic with the introduction of  
Internationalizations.  Dependence upon an allusion of protection  
creates a larger number of victims.  There can be no half measures  
with respect to security.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 18 Apr 2007 15:00:11 -0400

> with respect to security.

Then I guess your solution is to do nothing until we have a complete solution 
to the entire phishing problem?

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Apr 2007 12:24:32 -0700

On Apr 18, 2007, at 12:00 PM, Scott Kitterman wrote:

>> through rejection alone remains prone to look-alike and cousin  
>> domain exploits, growing ever more problematic with the  
>> introduction of Internationalizations.  Dependence upon an  
>> allusion of protection creates a larger number of victims.  There  
>> can be no half measures with respect to security.
>
> Then I guess your solution is to do nothing until we have a  
> complete solution to the entire phishing problem?

Those domains with email being phished SHOULD implement DKIM.   
Perhaps they could publish a policy record at their principal  
domain.  DKIM used in conjunction with aggressive anti-phishing  
filtering will not need policy records to be wildcarded.

Phishing will not be slowed substantially solely by email-address  
policy rejections at the MTA.  DKIM is _not_ an anti-spam mechanism  
for many reasons.

Anti-phishing requires message analysis of content.  Such content is  
not covered by an email-address policy.  Anti-phishing must not  
depend upon a recipient being able to visually recognize trustworthy  
email-addresses.

-Doug

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 19 Apr 2007 16:08:19 -0700

> [mailto:[email-masked]] On Behalf Of Scott Kitterman

> 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.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 19 Apr 2007 16:19:59 -0700

> 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.

I think it is an entirely rational concern. XPTR creates a two level system:

1) ANYONE can publish a DKIM policy without upgrading their DNS server
	To publish policy for example.com you publish 
		_dkim.example.com TXT "DKIM"

2) Wildcard policy publication requires a server upgrade
	To publish policy for *.example.com you publish
		_dkim.example.com TXT "DKIM"
		*.example.com XPTR _default.example.com
		_dkim._default.example.com TXT "DKIM NOMAIL"

OK so why did I decide to cave to the demands of the DNSEXT working group, not just to get along.

The problem here is that REGARDLESS of whose scheme you use you are going to need to deal with the problem that DNS wildcards do not have the semantics that you would want as an administrator. As we have discussed ad-nauseam, a DNS wildcard only applies to nodes in the zone which do not exist. 

So to make any of these schemes work we need a DNS server with the ability to manage macro-wildcards. This applies to Jim's schemes and to my schemes and to anyone else's schemes. 

If we have to add this capability to the DNS server there is not a significant cost to an XPTR record.

But the key advantge here is that anyone can start DKIM signing and publishing SSP records today. That is not the case for a new RR.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 19 Apr 2007 16:23:25 -0700

> [mailto:[email-masked]] On Behalf Of Frank Ellermann

> Really, I can't judge it.  Whatever the folks here decide, 
> please check it with some "namedroppers" before we waste 
> months revisiting ratholes.

I have discussed this on namedroppers several times. 

That is how it changed from the original PTR scheme to this one. 

XPTR does not fighten folk at this point.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Apr 2007 18:03:07 -0700

On Apr 19, 2007, at 4:19 PM, Hallam-Baker, Phillip wrote:

> The problem here is that REGARDLESS of whose scheme you use you are  
> going to need to deal with the problem that DNS wildcards do not  
> have the semantics that you would want as an administrator. As we  
> have discussed ad-nauseam, a DNS wildcard only applies to nodes in  
> the zone which do not exist.
>
> So to make any of these schemes work we need a DNS server with the  
> ability to manage macro-wildcards. This applies to Jim's schemes  
> and to my schemes and to anyone else's schemes.
>
> But the key advantge here is that anyone can start DKIM signing and  
> publishing SSP records today. That is not the case for a new RR.

The XPTR is a clever concept, but seems unlikely to be quickly  
embraced.  Regardless of the record used, this record accompanies all  
other records found at each leaf.  While scripts can be used to  
populate a zone, automation needs to be endorsed and assured secure.   
This represents a sizable investment with little added benefit from a  
performance standpoint.

Publishing a list of domains run by registries provides far greater  
performance for obtaining domain policy and reputation.  This type of  
list does not demand complex changes to DNS or usurping a RR selected  
from the few supported in the corporate environment.  This list  
requires occasional maintenance, which is why it would be good to  
standardize format and centralize where it is published.

Not as bad as distributing a host file, however every company  
tracking domain reputation heavily depends upon this essential  
information.  Rather than each company individually generating their  
own list, DKIM's base specification compatibility depends upon this  
list being generally accepted and standardized as these domains are  
to be excluded validating sub-domains.  A specialized RR could even  
be published by SLDs to signal the domain's use by a registry, which  
could help with standardization efforts. : )

Mark's suggestions regarding domain depth offering sub-policies  
(assuming sub-polices are less restrictive) seemed reasonable.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Apr 2007 08:57:30 -0400

On Thursday 19 April 2007 19:08, Hallam-Baker, Phillip wrote:
> 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.

> 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

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 

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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 20 Apr 2007 15:52:16 +0200

Scott Kitterman wrote:
 
> 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.

Is it now shipped with a "this is the conformance test suite, I'm forced
to bahave" heuristics ?  <g>

 [new RR type] 
> 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.

Depends.  One proponent of a future v=spf3 indicated that he would go
for "only in SPF RRs, not in TXT RR", and IMO that makes sense if no
better strategy like Phill's XPTR is available at this time.

>> 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.
 
> non-sanctioned uses of PTR?

Somebody on "namedroppers" mumbled something in this direction, but IMO
it was neither convincing nor conclusive.  We could make sure that any
legacy or idiosyncratic uses of XPTR are still possible and allowed for
folks not interested in the new semantics.  Like SPF "allows" to use
TXT as specified for text, with a detailed specification how to find a
say "v=spf1" text if that's what you're looking for, plus considerations
about the size of a complete TXT RR set.

For Phill's (X)PTR this would be considerably simpler, it's mainly a
political question, the technical idea is KISS.  I'd feel much better
if a NAPTR expert tells us that (X)PTR is not only simple but also 
"the right thing" (tm) for its job.

> 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.

IMO that's something for our ADs or rather the IESG to decide, if we
decide to want it.  They're free to start a new WG or to propose an
individual submission or to update the Charter or whatever it takes.

They're however not free to suppress ideas just because they don't like
to get into disputes with namedroppers and the IAB (as it would likely
happen in this case).  Obviously Jim and Barry need all available ammo
for this approach, minimally a clear WG consensus based on a published
draft.

>> Getting along does not mean surrender or automatic compromise.

+1

> Someone MIGHT already be using _dkim.example.com for some other non-
> sanctioned use.

And we are absolutely sure that this is perfectly legal.  I can use 
this construct for whatever purpose I like.  DKIM base doesn't force me
to stay away from "_dkim" labels for other purposes.  But of course I
own the "_dkim" pieces when I try to have my cake and eat it too :-)

Frank