ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP issues

2007-05-31 10:41:40
The problem is that the default needs to be "I do send mail", and "I
don't sign everything", since that is the current situation.  In other
words, the lack of an SSP record corresponding to "badguy.foo.com"
cannot be interpreted as suspicious, since it could simply be someone
who hasn't implemented SSP and doesn't have a record for that reason.

-Jim

Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
Please excuse my lack of DNS knowledge here
Ssp.foo.com returns "I send no mail"
Would work in the same fashion as mx.foo.com, a query returning a
result. If a bad actor wanted to claim badguy.foo.com and an ssp query
did not return data from ssp.badguy.foo.com it then becomes a local
policy decision on whether to deliver or not. I must be missing
something.
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
Sent: Thursday, May 31, 2007 10:26 AM
To: Hallam-Baker, Phillip
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] SSP issues

Hallam-Baker, Phillip wrote:
  
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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?
  
As a general rule: deployment of a new Internet protocol or protocol
    
enhancement such as DKIM should not require consumption of any finite
infrastructure resource. DNS RRs are one such resource.
  
  
    

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 only objection made to using TXT that has been sustained is the
    
wildcard issue and that has been answered by XPTR. The principled
approach here is to use a new RR to extend the DNS infrastructure so it
never needs future extension for other projects with similar goals. 
  
I think that we should only do TXT. The consequence of this is that
    
any email sender can express the policy 'I sign all mail from
example.com' without modifying their DNS. The sand in the shoe is that
they have to upgrade their DNS server to express the policy 'All mail
from *.example.com is signed'.
  
  
    

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?
  
I accept the sand in the shoe reluctantly for the following reasons:

1) I don't think that the policy 'All mail from *.example.com is
    
signed' is legitimate, I can see a need for the policy 'No mail is sent
from *.example.com' but that is out of scope. I can see how this can
happen due to split DNS but anyone operating DKIM in this mode should
either enter the DNS nodes in the external DNS or do the appropriate
mapping before they sign.
  
2) Regardless of the wildcard mechanism employed (new RR, XPTR,
    
whatever) administrative wildcards are going to be essential on a zone
of any size.
  
  
    

I think I know from context and from talking with you what
"administrative wildcards" are, but is this a generally used term?  If
not, you might want to explain.
  
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.


  
(3) Upward query vs. wildcard publication.  27 messages in 
discussion from 15 people.  Most of the discussion was a 
rehash of the idea of associating semantics with DNS 
zone-cuts, which we had already discussed and rejected.  I 
have also been trying to get an opinion from DNSOP on the 
idea of a one-level upward search (which I think solves 90% 
of the problem), but haven't gotten any response.

So I don't know what to write in a revision of the draft.  I 
could just write my opinions, but that's basically what's in 
the draft-allman-dkim-ssp-02 draft already and doesn't make 
any progress toward unifying the different proposals.  I want 
to get something done soon, well before the July 2 deadline.
    
      
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.
  
What does make sense is to have a policy:
      'All mail from {example.com, alice.example.com, bob.example.com}
    
is signed'
  
     OTHERWISE 'No mail is sent from *.example.com'

I can't see where I would be signing mail from a domain name with no
    
external existence.
  
OK here we come to a strange observation I made to Jim earlier. DKIM
    
does not require a wildcard for DKIM signature policies. 'I sign
everything in *.example.com' does not make sense, the wildcard that does
make sense is 'Nomail is sent from *.example.com'. Which is of course
out of scope, so maybe the whole wildcard issue is out of scope for DKIM
policy and is only in scope for DKIM policy extensions (e.g. NOMAIL).
  
  
    

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.

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

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

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

<Prev in Thread] Current Thread [Next in Thread>