Subject: [ietf-dkim] SSP issues

From: Jim Fenton <[email-masked]>
Date: Wed, 30 May 2007 15:22:53 -0700

What we had hoped to do in the next revision of the allman-ssp draft was to unify it as much as possible with Phill Hallam-Baker's draft.  I opened three new issues on April 16 that I think need to be resolved in order to do that.

(1) Use of XPTR records for SSP.  The idea here is to create a more general policy mechanism that can be used by WS-* and such.  There were about 20 messages discussing this from 5 people.  I'm not reading a clear consensus on this.

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

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

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 30 May 2007 18:37:51 -0400

On Wednesday 30 May 2007 18:22, Jim Fenton wrote:

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

Agreed.  There is also a view that if you go with a new RR type, don't bother 
with SSP.  By the time a new RR type is widely deployable, the market will 
have found a different solution.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 May 2007 15:52:17 -0700

> have found a different solution.

I have a lot of sympathy for this point of view, but something
also to consider here is that there is a relatively small, but
motivated set up of people who would like to use SSP as early
adopters. These are people who are being attacked by phishers
and would find it relatively easy to make a broad statement like
"by all means, trash mail from me that isn't signed". For those
folks, it just needs to be possible at all. For bind, this is a
straightforward, if somewhat aesthetically unappealing, process.
Other resolvers may vary (obviously).

 From my point of view, the question is does a new RR actually
bring something advantageous to the table. And is that advantage
enough to overcome the energy barrier of the deployment difficulties.
As I recall, the current SSP draft tries to make a case for that,
but I honestly don't understand the logic behind it. Maybe Jim
and Eric can elaborate.

		Mike

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 30 May 2007 16:54:35 -0700 (PDT)

On Wed, 30 May 2007, Jim Fenton wrote:

> (1) Use of XPTR records for SSP.  The idea here is to create a more 
> general policy mechanism that can be used by WS-* and such.  There were 
> about 20 messages discussing this from 5 people.  I'm not reading a 
> clear consensus on this.

This should not be handled as part of this WG but within dns group.

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

If you need another opinion, do both TXT and custom record.
I guess that does not help your consensus searching though...

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

Dont do it. The issue is that you can not properly tell where zone
delegation starts. I know resourceful programmers (including me)
keep track of this data and know that for example ".com" is one
delegation but ".uk" is not and there you have ".co.uk". But the
list is actually rather large and for several ccTLDs you have both
use ".com.??" and ".??" as proper delegation zones. So getting
around this is just way too tricky and if you don't what you end
up doing is sending multitude of extra queries to ccTLD name servers.
This is not proper operational approach as extra load would not be
spread but directed towards several single points on the net.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 May 2007 16:19:57 -0700

On May 30, 2007, at 4:54 PM, william(at)elan.net wrote:

>
>> (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.
>
> around this is just way too tricky and if you don't what you end up  
> doing is sending multitude of extra queries to ccTLD name servers.  

I would be happy to help co-author a draft that establishes a list of  
current domains levels used by registries which should be excluded  
from queries for DKIM related records.  The list therefore  
establishes the first and perhaps only location needing to be checked  
regarding email related policies.  A rather manageable domain list  
established by this document would eliminate a need to use any type  
of wildcard mechanism.   To avoid query overhead, new upper level  
domains should want to be added to this list as the need arises.  A  
wildcard mechanism is also something relatively easy to abuse.  As  
such, it is doubtful any wildcard scheme will gain acceptance within  
DNSEXT or DNSOPS WGs.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 30 May 2007 19:20:21 -0400

>>> (2) SSP record type (TXT vs. something new). Only 4 messages in 
discussion,
>Other resolvers may vary (obviously).
Receivers need to be able to query it too for it to be useful.  Doable in 
BIND is intersting, but not nearly sufficient.

Scott K

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 30 May 2007 17:25:28 -0700 (PDT)

On Wed, 30 May 2007, Douglas Otis wrote:

>>> 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.
>> 
>> delegation starts. I know resourceful programmers (including me) keep 
>> track of this data and know that for example ".com" is one delegation 
>> but ".uk" is not and there you have ".co.uk". But the list is actually 
>> rather large and for several ccTLDs you have both use ".com.??" and 
>> ".??" as proper delegation zones. So getting around this is just way 
>> too tricky and if you don't what you end up doing is sending multitude 
>> of extra queries to ccTLD name servers. This is not proper operational 
>> approach as extra load would not be spread but directed towards several 
>> single points on the net.
>
> current domains levels used by registries which should be excluded from 
> queries for DKIM related records.

That's not the way to do it. The list only provides info on current
moment where as technology should be general and should not restrain
or be restrained by policy issues (and deciding if they want or do not 
want to offer direct SLD for come ccTLD is a policy issue).

Besides that there are other issues with just doubling number of
queries for new record. The only case where I see it as acceptable
is for transition period (i.e. A & AAAA ; although clearly such
"trasition" periods can last very very long time...).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 May 2007 16:35:12 -0700

> BIND is intersting, but not nearly sufficient.

While I have sympathy on the server side, I have little sympathy on
the client side. Consing up a DNS query is hardly rocket science, and
there are lots of resolver libraries to accomplish that for somebody
tasked with the development.

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 May 2007 17:01:33 -0700

On May 30, 2007, at 5:25 PM, william(at)elan.net wrote:
>> I would be happy to help co-author a draft that establishes a list  
>> of current domains levels used by registries which should be  
>> excluded from queries for DKIM related records.
>
> moment where as technology should be general and should not  
> restrain or be restrained by policy issues (and deciding if they  
> want or do not want to offer direct SLD for come ccTLD is a policy  
> issue).

Internally, a list of this nature is being maintained already.  The  
document would simply help establish a repository for where such a  
list could reside.  Domain owners wishing to use a domain for email  
are free to have their domain removed, but this will likely be an  
extremely rare event.  The more likely scenario are additions  
instead, to curtail unnecessary queries hitting their servers.  It  
would be surprised to find that such a list is not welcomed in vast  
majority of cases.  Exceptions to this list will also be far easer to  
manage separately.

> "transition" periods can last very very long time...).

The concept is to provide a text file in some standardized format  
listing the domain to be avoided.  An announcement might be made that  
a change occurred to prompt administrators to update their  
configurations based upon this list.  I would not expect this file to  
change so frequently as to be unmanageable.  If anything, domains are  
remaining fairly flat.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 May 2007 21:16:08 -0400

> have found a different solution.

IMO, I think we should stop wasting further time on this repetitive 
issue and just establish two, a new RR with a TXT fallback, as part of 
the specs.

The bottom line is that client applications will learn to adapt to 
domains. They are not stupid. If they sees that a domain only uses TXT, 
it may stop doing a RR lookup for this domain.  To re-adapt to RR, one 
easy solution would be to have a TXT attribute:

     rr=1

that says the RR record exist and the client should use the RR first, if 
it can.

If we stick with TXT only, we loose the opportunity to use RR in the 
future (even if its years).

If you stick only with RR, then we risk early and optimal adoption and 
compatibility.

So we should use both with an initial RR, TXT fallback with insights for 
client to learn, and we should also consider a TXT attribute, like RR=1 
that says that a RR record exist for those clients that can read it via 
the network

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Steve Atkins <[email-masked]>
Date: Wed, 30 May 2007 18:38:22 -0700

On May 30, 2007, at 6:16 PM, Hector Santos wrote:

>>> mostly saying "if you support TXT, don't bother with anything  
>>> else." Again, no clear consensus.
>> Agreed.  There is also a view that if you go with a new RR type,  
>> don't bother with SSP.  By the time a new RR type is widely  
>> deployable, the market will have found a different solution.
>> Scott K
>
> issue and just establish two, a new RR with a TXT fallback, as part  
> of the specs.
>

SRV provides some extra functionality over an A record for publishing  
a website.

But the A record works. Anyone publishing a website needs to provide  
the A record. If they just published a SRV record, most clients  
wouldn't find or visit the site.

A client needs to support the A record, and because it can safely  
assume that every site has an A record, looking for an almost  
certainly non-existent SRV record before looking for an A record is  
simply overhead and delay. Clients can safely just look for the A  
record and save themselves the pain.

Cheers,
   Steve

---

From: John Levine <[email-masked]>
Date: 31 May 2007 02:47:33 -0000

>bring something advantageous to the table.

Yeah, it makes wildcards work, which is fairly important in the
presumably common situation where you want to say that none of your
subdomains sends mail.  If you're going to use a TXT record, you need
to use a _something component in the name to keep it from colliding
with _domainkey and other uses of TXT, which makes wildcards not work.

; this attempt to condemn mail from subdomains won't work
; because internal * in a name doesn't work
_ssp.*.example.com TXT "ssp=bogus"

; but this will work (give or take adding explicit SSP records to nodes
; that have other kinds of records) because terminal * does work
*.example.com SSP "bogus"

> And is that advantage enough to overcome the energy barrier of the
> deployment difficulties.

That seems to be more a political than a technical question at this point.

R's,
John

---

From: John L <[email-masked]>
Date: Wed, 30 May 2007 23:46:59 -0400 (EDT)

> Super dumb question: Can we change the model around from a "default does 
> send" to a "default does not send"?
>
> Just as you have an MX to indicate you do accept mail (modulo the historical 
> A mess), perhaps you have an SSP to say you do send authenticated mail with 
> the default being unauthenticated un-SSPed mail is eventually discardable?

I don't see how that could work unless you plan to throw away all mail 
from non-DKIM users.  Some people won't publish SSP to assert they don't 
send mail.  Other people won't publish SSP because they do send mail, but 
they haven't updated their software since 2002.  There's no way to tell 
the difference.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John L <[email-masked]>
Date: Thu, 31 May 2007 00:14:45 -0400 (EDT)

> You're questioning the transition issues. I'm asking where do we want to end 
> up. I'm suggesting that SSP should be designed for our end-goal.

This is the Internet -- the transition will never be over, so something 
that only works after the transition won't happen.

> My strawman is that our end-goal is we don't want to accept mail unless it's 
> authenticated by DKIM. If you agree with that, then SSP should push us in 
> that direction.

I agree that's a fine goal, but I don't see how SSP helps.  Ideally, at 
some point there will be little enough unsigned mail that the benefit of 
picking through it to find the trickle of non-spam is less than the cost 
of the picking.  We'll know that by looking at our mail streams, not from 
individual assertions by mailers.

R's,
John

---

From: Graham Murray <[email-masked]>
Date: Thu, 31 May 2007 07:23:55 +0100

> change so frequently as to be unmanageable.  If anything, domains are

Or use a DNS system, as used by some other systems (eg SpamAssassin and
ClamAV), to indicate when an update is available. Clients periodically
query the DNS, which returns the latest version number of the file and
if this is newer than the one the client currently holds it can retrieve
the new version.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 31 May 2007 01:52:02 -0700

On May 30, 2007, at 11:23 PM, Graham Murray wrote:

>> listing the domain to be avoided.  An announcement might be made  
>> that a change occurred to prompt administrators to update their  
>> configurations based upon this list.  I would not expect this file  
>> to change so frequently as to be unmanageable.  If anything,  
>> domains are remaining fairly flat.
>
> Or use a DNS system, as used by some other systems (eg SpamAssassin  
> and ClamAV), to indicate when an update is available. Clients  
> periodically query the DNS, which returns the latest version number  
> of the file and if this is newer than the one the client currently  
> holds it can retrieve the new version.

Setting up a zone file under some domain would require someone to  
offer this service.  That seems logical and even a good idea, but who  
would run such a service?  This service should be controlled directly  
or indirectly by some organization, such as IETF, ICANN, or IANA.  It  
seems such organizations have more experience setting up a web page,  
than a zone file.  The web page could even offer a request for  
addition or a deletion forms confirmed in some manner, perhaps by a  
special "NO_MAIL.<domain>. A IN 128.0.0.2" DNS entry.  It would be  
rather silly to use a role email address such as postmaster to  
confirm a request to indicate a domain does not handle email.  A role  
email address could confirm a request for removal from the list,  
although that should be a very rare request.  This web page could  
offer an RSS feed or a DNS zone file as an added service, but having  
a web page seems like a bare-bones minimum.  Perhaps a friendly  
company or two could offer the web page information in the form of a  
DNS zone file. ; )

The corporate environment established by Microsoft creates a barrier,  
as access to DNS may be through RPC.  This takes some joy out of  
introducing new RRs just to support wildcards.  A bad-actor can also  
utilize wildcard RRs for staging a DDoS attack.

Wildcards ensure a means to obtain an uncached and relatively large  
DNS packet.  The DNS question is always included in the answer.  The  
bad-actor simply needs to ask about random domain names of a maximal  
size, where an SSP policy response would then be added to these  
labels.  Such unusual requests may exceed a maximal DNS packet size,  
which could be analogous to pushing someone's fist into their own  
face, while saying "Stop hitting yourself."  This would be especially  
true for likely bloated policy records which always seem destine to  
use the greatest number of bits for representing one bit of  
information.  DNS information is best kept compact, but that will  
_not_ happen when describing policy.  People like to spell this stuff  
out using ASCII.  : (

Establishing a list permits a convention for where to first always  
look for a record.  A list seems like a safe approach, and could also  
facilitate domain reputation requests which would be less likely to  
clog a DNS cache with junk created by far too prevalent bad-actors. : )

This list should be able to assume a TLD is excluded unless the TLD  
indicates otherwise.  The lists of domains to be excluded should then  
also be able to indicate exceptions made at the TLD, if or when this  
is required.  A zone file might be able to indicate these exceptions  
by assigning a different value to an A record.  A normal exclusion  
could have an A RR address of 128.0.0.2 whereas the TLD exception  
could have the value 128.0.0.4, as example.

-Doug

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 31 May 2007 04:04:01 -0700

> [mailto:[email-masked]] On Behalf Of Jim Fenton

> What we had hoped to do in the next revision of the 
> allman-ssp draft was to unify it as much as possible with 
> Phill Hallam-Baker's draft.  I opened three new issues on 
> April 16 that I think need to be resolved in order to do that.
> 
> (1) Use of XPTR records for SSP.  The idea here is to create 
> a more general policy mechanism that can be used by WS-* and 
> such.  There were about 20 messages discussing this from 5 
> people.  I'm not reading a clear consensus on this.

I would order this slightly differently. The point of XPTR is that it avoids the need to create new RRs for future policy records. The reason I believe this is essential is that in the future I anticipate a policy record for every protocol and I anticipate a vast increase in the number of protocols as we enter the machine-machine communication era.

Current Internet protocols are almost exclusively designed either for human endpoints directly or to support protocols that terminate at human endpoints. This constrains proliferation of protocols. Once we are in the Web Services era proper we lose this constraint. I expect development of these protocols to be organic, bottom up with the standards process only kicking in at a late stage.

If I am right a means of distributing protocol policy will be essential to manage the proliferation, moreover gating deployment on IETF action required to allocate a finite resource (RR codes) and update the DNS server infrastructure is simply usustainable.

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

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.

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

3) There is an advantage to DKIM in encouraging deployment of DNS servers capable of DNSSEC.

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

If we put it on the table and the DNS cabal raise an objection which is sustained for cause it will be harder to resist if they make complaints in areas where they don't really have a cause.

I thought I would want 'I sign all mail from *.example.com' but I don't, and I don't think anyone else really does.

There are three cases of interest:

1) The node exists in the internal DNS and the external DNS  
		'example.com', 'alice.example.com'
2) The node exists in the internal DNS but not the external DNS
		'bob.example.com'
3) The node exists in neither DNS
		'spammer.example.com'

If the site does not have split DNS the only cases that appear are 1 and 3.

I don't think that case 1 is the sort of thing you want to handle with a wildcard. If you care enough to sign the mail and setup the key records then you care enough to stipulate the policy.

Case 2 is an interesting edge case, but I don't think it is realistic. If I am hiding the existence of the node from the external world it should not be sending mail.

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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 31 May 2007 07:03:53 -0700

> spread but directed towards several single points on the net.

The number of upward queries to TLDs and other "non-delegation zones"
would be limited by negative cacheing; each verifier should only be
making one such query per minimum TTL period.  I'm not sure how to
assess what would be an "acceptable" load, however, and in any case the
min TTL is sometimes rather short (15 minutes for .com, I see) so that
might not be enough help.

As for Doug's subsequent suggestion of publishing a list of such
non-delegation zones somewhere, we would need to normatively refer to
such a list, which means that it would need to be maintained by IANA or
a similar authority.  I don't see that as a likely possibility,
especially since the usage of ccTLDs is outside IANA's scope.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 31 May 2007 07:26:22 -0700

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

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

> 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 i…

"...is a major cause":  currently?  I don't see how we can design any
protocol that is misimplementation-proof.
> 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…

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

---

From: <[email-masked]>
Date: Thu, 31 May 2007 11:12:45 -0400

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: [email-masked]
[mailto:[email-masked]] 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:
> 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.

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

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

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

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

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 31 May 2007 10:34:53 -0700

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

[email-masked] wrote:
>> 3) There is an advantage to DKIM in encouraging deployment of DNS
>>     
> servers capable of DNSSEC.
>   
>>   
>>     
>
>>       'All mail from {example.com, alice.example.com, bob.example.com}
>>     
> is signed'
>   
>> I can't see where I would be signing mail from a domain name with no
>>     
> external existence.
>

---

From: <[email-masked]>
Date: Thu, 31 May 2007 13:44:07 -0400

Exactly my point. The mail without an ssp pointer will be handled in the
same fashion as the mail without sigs as opposed to a dkim signed and
ssp matching policy statement.
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

-----Original Message-----
From: Jim Fenton [mailto:[email-masked]] 
Sent: Thursday, May 31, 2007 1:35 PM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]
Subject: Re: [ietf-dkim] SSP issues

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 31 May 2007 16:59:35 -0700

On May 31, 2007, at 7:03 AM, Jim Fenton wrote:
>> up doing is sending multitude of extra queries to ccTLD name  
>> servers. This is not proper operational approach as extra load  
>> would not be spread but directed towards several single points on  
>> the net.
>
> The number of upward queries to TLDs and other "non-delegation  
> zones" would be limited by negative cacheing; each verifier should  
> only be making one such query per minimum TTL period.  I'm not sure  
> how to assess what would be an "acceptable" load, however, and in  
> any case the min TTL is sometimes rather short (15 minutes  
> for .com, I see) so that might not be enough help.
>
> non-delegation zones somewhere, we would need to normatively refer  
> to such a list, which means that it would need to be maintained by  
> IANA or a similar authority.  I don't see that as a likely  
> possibility, especially since the usage of ccTLDs is outside IANA's  
> scope.

Jim,

Caching is more effective starting the search below the TLD.  Bad- 
actors often make use of random labels and wildcards to obfuscate  
their significant domain.  This rather common practice of random  
labels is flooding the DNS cache making it less effective.  A  
strategy starting high leads to fewer queries and less time per  
transaction.  However, this will cause second and third level domains  
to experience higher levels of undesired traffic.  An option these  
domains have is to terminate queries with a long lived record with a  
prefix and RR type used by the protocol causing the traffic.  As  
Phillip suggested, this would be a PITA and prohibit versioning.   
Forcing any publication of "dummy" records by second and third level  
domains would be demanding an inordinate amount of cooperation.

IANA could provide these second and third levels domains a much  
easier alternative.  With this alternative, they avoid a significant  
amount of traffic without publishing anything used directly by some  
protocol.

For just a _single_ IP address, our customers generate over 50  
queries per second for those items not cached and, at any point in  
time, more than 70 million IP addresses are active.  Think how bad  
this gets when there is no record to cache to quell the queries.

If IANA were to publish a list offering second and third level  
registries a simple solution to curtail this traffic, _no_ other  
enticement or legal obligation should be needed.  In this respect, we  
hold a different view about what might be possible and practical.   
This would be hundreds of times safer than wildcards, while also  
conserving a vast amount DNS cache which will otherwise contain  
mostly junk.  A list of this nature could assist many differ polices  
and protocols without resorting to wildcards of any sort.

-Doug