Subject: RE: [ietf-dkim] SSP issues

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 2 Jun 2007 19:54:02 -0700

> From: Jim Fenton [mailto:[email-masked]] 

> Hallam-Baker, Phillip wrote:
> >> [mailto:[email-masked]] On Behalf Of Jim Fenton
> >>     
> >> (2) SSP record type (TXT vs. something new). Only 4 messages in 
> >> discussion, mostly saying "if you support TXT, don't bother with 
> >> anything else."  Again, no clear consensus.
> >>     
> >
> > I see no value in an SSP record type. The downside for DKIM 
> is serious - we are gated on new deployments of DNS server 
> code. The downside for the DNS described above is equally serious.
> >
> >   
> 
> If we would be gated on new deployments of DNS server code, 
> wouldn't this be equally true for XPTR records?

No, wildcard policy is a luxury, not an essential part of the spec.

As I point out the policy for my domain is likely to be

verisign.com        "ALL Mail is signed"
ops.verisign.com    "ALL Mail is signed"
**.verisign.com     "No mail is sent"

I don't see how I would end up in a situation where I attach a wildcard to a policy that says all mail is signed. Since NOMAIL is out of scope it is entirely acceptable to present the following options:

1) You can deploy DKIM policy for specific domain records using your existing DNS server.
2) To deploy a wildcard policy you will need to upgrade your server if it does not support new RRs

If I thought there was a serious deployment issue here I would still be pushing my original scheme to hijack PTR in the forward DNS for the same purpose as XPTR. 

> I would have expected this comment from the DNS directorate 
> if there was threat of running out of DNS RRs, but much the 
> opposite:  the IAB "DNS choices" draft recommends creation 
> and use of new RRs.

The DNS choices draft represents old thinking on the problem. It does not address the situation we now face in Web services.

We are not in an imminent danager of running out of RRs because nobody who is using the DNS for policy distribution is following the advice in choices. Instead people are defining their own prefix schemes and ignoring choices. 

> I'm not clear on what "only do TXT" means in this context -- 
> do you mean a directly referenced TXT record or one retrieved 
> via an XPTR lookup or both?

The policy record is only expressed using TXT
The discovery process being first look for TXT, if that is not find look for an XPTR and if found a TXT of the XPTR node.

> > 3) There is an advantage to DKIM in encouraging deployment 
> of DNS servers capable of DNSSEC.
> >   
> 
> Yes, but I don't see how that is relevant here.

It is the real reason why choices is written the way it is. 

> > I think that this is where we reach the 'non-negotiable' 
> issue for the DNS cabal. Misimplementation of upward query is 
> a major cause of load on the DNS. The DNS cabal will complain 
> loudly on this issue and they will actually have a case.
> 
> "...is a major cause":  currently?  I don't see how we can 
> design any protocol that is misimplementation-proof.

An algorithm that contains a loop is more likely to be error prone than one that always completes in a finite number of steps.

> Agree that the NOMAIL policy is the more interesting one to 
> express with a wildcard.  There are some cases where it might 
> be convenient to express a signing policy for subdomains, but 
> in every case I can think of it's practical for the 
> subdomains to publish their own SSP record.

Hence my belief that gating wildcards on a new RR is acceptable while gating policy itself is not. 

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

---

From: Damon <[email-masked]>
Date: Mon, 4 Jun 2007 11:20:46 -0400

> Hence my belief that gating wildcards on a new RR is acceptable while gating policy itself is not.

+1

Regards,
Damon Sauer

---

From: Jim Fenton <[email-masked]>
Date: Mon, 04 Jun 2007 15:43:44 -0700

> The discovery process being first look for TXT, if that is not find look for an XPTR and if found a TXT of the XPTR node.

This is apparently the central issue where I didn't understand your
proposal.  I thought you always looked up the XPTR first, but I see that
is not the case.

Is the rule then to always publish the prefixed TXT record, even if an
XPTR is also published, since some verifiers may not be able to support
XPTR?

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 4 Jun 2007 16:36:37 -0700

On Jun 4, 2007, at 3:43 PM, Jim Fenton wrote:

>> The policy record is only expressed using TXT.  The discovery  
>> process being first look for TXT, if that is not find look for an  
>> XPTR and if found a TXT of the XPTR node.
>
> proposal.  I thought you always looked up the XPTR first, but I see  
> that is not the case.
>
> Is the rule then to always publish the prefixed TXT record, even if  
> an XPTR is also published, since some verifiers may not be able to  
> support XPTR?

Either a process that makes assumptions based upon the location of MX  
or IP address records, or a linear search is required to discover  
policy records when support for some a new wildcard scheme can not be  
assured.

The concept offered by Phillip is to use a wildcard with a new type  
of PTR record.  This XPTR record then points to a location where  
policy records are located.  One could attempt to first find a  
prefixed policy record, and when that failed, attempt to find the  
XPTR record.  What happens with the XPTR pointer record does not  
appear to exist?  It would not mean there is no policy.

A scheme that relates policy locations to the location of an MX  
record provides offers very similar overhead without introducing a  
new RR type.  To ensure policy can be discovered in this manner, the  
MX record itself must not be using a wildcard.  However the new XPTR  
must be place at _every_ DNS node, otherwise some regions of a domain  
is not protected.

Once the use of A or AAAA records are obsoleted as a means to locate  
inbound SMTP servers, then only a policy record would be required at  
the location of the MX record.  Until then, only where A or AAAA  
records are placed would a policy record need to be published.  This  
actually represents less overhead than that of the XPTR scheme.

Perhaps it is time to start requiring MX records for SMTP.  Any type  
of wildcard leaves a domain prone to a DDoS attack, where reliance  
upon a wildcard would not represent the safest alternative.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Tue, 05 Jun 2007 08:47:00 -0700

> XPTR is also published, since some verifiers may not be able to support

I'm similarly confused. Is it possible to make a ladder diagram or
something akin to it so that we can grok the flow? And also: I'm still
completely confused by how any new RR, XPTR or otherwise, is going to
get around the lack of what is being called ** wildcards. Is the
proposal is that we define this new RR to specifically _be_ that kind
of wildcardable RR?

		Mike