Subject: RE: [ietf-dkim] The URL to my paper describing the DKIM policyoptions

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 Jul 2006 17:33:57 -0700

> From: Douglas Otis [mailto:[email-masked]] 

> On Mon, 2006-07-24 at 22:27 -0700, Patrick Peterson wrote:
> 
> > > http://www.ietf.org/internet-drafts/draft-hallambaker-pcon-00.txt
> > 
> > I think this is a great idea and am surprised it didn't 
> generate more 
> > traffic on the list. It's not easy to cram needed new functionality 
> > into a backward-compatible solution.
> 
> This concept requires a wildcard PTR record at every label.

You need a record of some sort REGARDLESS of whether you use my mechanism or define a new RR. 

The records can be generated automatically. Nobody is going to be editing their zone file directly in the DNSSEC era. We might as well get into the habit now. The semantics are identical for this as for MX. Which again is a good thing. Consistency is good. 

> This assumes there are no other PTR record used beyond 
> reverse lookups, which may not be the case. 

As I have said, I would accept definition of a new record for the pointer if it is clear that this is the case. So far nobody has given me a case where it is an issue.

> Name errors 
> would not be reported, which might make other searches 
> difficult and perhaps risk flooding caches with PTR RRs. 

Again, there would be no difference here 
 
> This will also require special treatments at delegation points.

They work fine. As several people have pointed out you don't want a wildcard to blow through a delegation.

> The intent was to point to a general label where policy 
> references are found.  Philip suggested this should point to 
> an HTTP server.  HTTP is needed to support the size of an all 
> encompassing policy response.

No I did not make that suggestion. 

What I did say is that we should not look to put more that the bare essentials into the DNS system, that is the data that a client is going to use to make a choice between services and to configure the security context to connect to a service. If there is a need to go beyond that we can link out to HTTP but that is not necessary for DKIM

> If the PTR record can not be overlaid, then a new RR type is needed.
> Defining a new RR type allows this RR type to be wildcarded 
> at every label and contain the policy information specific 
> for a particular protocol.  No multi-record lookup or HTTP 
> would then be required. : )

No you do not understand the problem. 

Defining a new RR only solves one half of the problems of wildcards, the poor interaction with prefixes. You still have the problem that the semantics don't work the way that you would want and you have to populate the zone with macro wildcards. The difference with my scheme is that you only need to do it once for all protocols. 

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Jul 2006 19:09:54 -0700

On Jul 25, 2006, at 5:33 PM, Hallam-Baker, Phillip wrote:

>> The intent was to point to a general label where policy references  
>> are found.  Philip suggested this should point to an HTTP server.   
>> HTTP is needed to support the size of an all encompassing policy  
>> response.
>
> What I did say is that we should not look to put more that the bare  
> essentials into the DNS system, that is the data that a client is  
> going to use to make a choice between services and to configure the  
> security context to connect to a service. If there is a need to go  
> beyond that we can link out to HTTP but that is not necessary for DKIM

My apologies.  I see that you have suggested resource records located  
at the underscore label will use protocol specific policy RR types to  
avoid collision.  Currently, this process requires an attempt to  
directly obtain desired policy RR types at the underscore label.  If  
that fails, a transaction then obtains the prefix-wildcard RR  
record.  The content of the prefix-wildcard RR then locates the  
desired policy RR type for one more transaction.

Of course, a script or complaint DNS server generates the added  
wildcard records, but this may create issues related to revealing  
nodes within a domain.  Assuming this disclosure is not a problem,  
automating this prefix-wildcard RR record would ideally always return  
the desired policy RR on the first transaction "as if"  
_policy.<subdomain.domain> contained the policy RRset.  Specialized  
handling for the prefix-wildcard RR in this case would conflict with  
PTR definitions, however.  As this scheme expects new and protocol  
specific RR types, defining an RR to support the prefix-wildcard  
seems appropriate as well.

Perhaps it could be defined as:

_policy.<domain> PWCARD	<list-of-RR-types> <location-of-RR-types> ;no  
need for the ** label as this would be keyed off of the PWCARD type.

The list of policy RR types might help handle policy RRset overflow  
conditions.  The list allows individual queries of the most  
appropriate policy type without iterative queries to discover what is  
available.  This assumes policy structures may evolve, and that more  
than one policy for a protocol might be published.  If this approach  
does become popular, it may not be possible to obtain the entire RRset.

-Doug