Subject: RE: a suggestion for super-wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 12:38:06 -0700

OK in response to a request for clarification here:

> Hallam-Baker, Phillip

> > > sure it was a good idea to specify the file format, anyway. IETF 
> > > should be about protocols, not about file formats.)
> 
> Which is of course exactly how I would expect legacy 
> resolvers to handle the scheme. This part of the scheme is the same as

Should be "This part of the scheme is the same as we would have to do to satisfy the use cases for policy administration even with a new record"

>
> If it was not for zone transfers and for DNSSEC there would 
> be no reason to have wildcards mentioned in the protocol spec 
> at all. That is why the ambiguity could enter the system and 
> create the need for clarification decades later.

The point here is that a wildcard only ever appears on the wire in a DNS protocol exchange in two cases:

1) During a zone transfer
2) If DNSSEC is in use

If neither of these features existed there would be no reason for wildcards to be mentioned in the DNS spec at all. They would be a server configuration feature, no more. It would not matter how the wildcards were defined, there would be no interoperability issue.

The interoperability issue here has become apparent because we do have DNSSEC. I believe that the definition of wildcard we have now is the optimal one for DNSSEC. I don't suggest changing it since doing so would result in complexity being shifted to other parts of the spec.

If wildcards were a feature that appeared on the wire in contexts which required interoperation I am sure that the ambiguities in the original definition would have been discovered earlier.

> In the context of DKIM there is a need to demonstrate that 
> the wildcard problem can be solved by a script. Note that 
> this wildcard problem, the fact that wildcards don't have the 
> exact semantics you would want is an issue regardless of how 
> the records are encoded (TXT, new record, prefixed, not).
> 
> The alternatives on offer here are 
> 	1) The existing heuristic search 
> 	2) The macro-wildcard mechanism proposed here plus a new RR
> 	3) The macro-wildcard mechanism plus the pointer scheme 
> 'super-wildcards' 
> 		with either a new RR or a prefix label
> 
> I think that most of us here would agree that (1) is not a 
> satisfactory solution.

To give some more context. At present a DKIM policy record can make two useful statements that we all agree are essential:

1) This mail domain originates no mail.
2) All mail that this domain originates is signed.

In case (1) the messages can simply be blocked. For example mail from ver1sign.com is all bogus without exception and should be junked, the domain is only registered to prevent cybersquatters.

In case 2 an unsigned message or a message with a failed signature might be fake or might be a legitimate message that was mangled somehow. This information plus other information may be used by spam filters, phishing detection etc.

So the problem with policy is how to declare an email signing policy for **.example.com that takes effect if there is no more specific policy. The objective being to specify policies such as:

example.com     DKIM  "ALL mail is signed"
**.example.com  DKIM  "No mail is originated"

In the case that example.com is paypal.com or bankamerica.com I think we can all agree that policies of this type are legitimate. In the case that someone has complaints about the management of *.cs.utk.edu they can take it up with their admin. Anyone who really, really wants to set their email configuration themselves should buy themselves their own domain name. Its like owning your own cell phone number, more important than you might think.

The problem is that you may have an attacker send an email from 

A.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com

Checking every node for a policy record is not acceptable. This is made worse when you use a prefix convention (similar to SRV) as you can't even use a traditional wildcard.

At present the spec has a heuristic algorithm, walk up the tree three rungs from the bottom, then start at the top. That is the option (1) described.

If we define a new RR we can replace the heuristic algorithm with a scripted wildcard (macro-wildcard). This works for DKIM but doing it this way means that we have to repeat the process for every protocol that has a defined policy and the number of macro wildcards will quickly increase.

The third option is macro-wildcards plus pointers (super-wildcards). This provides a clear benefit whether you define a new RR or not.

The only impact that super-wildcards have on defining a new record are:

1) You might not want to redefine PTR for use in the forward DNS in this way and so want to define a new RR

2) The super wildcard scheme is prefix friendly and so you may not want to use a new record for the policy scheme.

If there was no legacy deployment of DNS my preferred route would be to propose defining a new RR for the pointer and a new RR which would be used in the same way as SRV, prefixed for defining policy records.

Given the DNS legacy that we have and the fact that much of it is now embedded in NAT boxes such as the netgear I just threw out as a POS I am very averse to creating new RRs unless there is a very significant change in the functionality of DNS itself.

I can imaging getting netgear and linksys to make a DNSSEC capable NAT box, I can't see people making special arrangements for DKIM. This is a problem for me because I see Secure Letterhead as the train to drive deployment of DKIM and DKIM as the train to drive deployment of DNSSEC and thus in turn the infrastructure changes necessary to support new DNS records. If deployment of DNSSEC becomes a precondition for deployment of DKIM I have a deadlock situation. In the simulation models I have run deployment takes decades rather than years with the same set of value proposition assumptions.

> 
> > Okay, it can be preprocessed, but that is going to be a helluva big 
> > zone
> 
> The expansion factor for super-wildcards is similar to the 
> expansion factor for DNSSEC, i.e the number of new records is 
> proportional to the number of nodes plus the number of 
> protocol policy declarations.
> 
> The expansion factor for macro-wildcards plus a new RR is the 
> proportional to the number of nodes MULTIPLIED BY the number 
> of protocol policy declarations.
> 
> 
> If we believe that DKIM is the only protocol policy record we 
> will need then both schemes result in the same expansion of the zone.
> 
> My belief is that we are about to see a dramatic expansion in 
> the number of Internet protocols as a result of Web services. 
> The key here is that the variation in services for human 
> consumption is rather small because people need consistency 
> in their user interfaces. I don't expect there to be many new 
> human interface protocols, the exceptions to this rule are 
> mostly games. Machine/Machine interfaces are not constrained 
> in that way, I expect we will have hundreds of Web Services 
> in regular use and SOAP is sufficiently complex that a policy 
> layer is essential for configuration.
> 
> We could develop something like UDDI or XRI. I don't like the 
> idea of yet another registry. We could use LDAP but today 
> LDAP stops at the firewall and that is going to be the case 
> tommorow as well and I don't expect that to change. LDAP is 
> too powerful and too complex for border directories to be 
> something people get comfortable with.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Jul 2006 09:58:28 +1000

Why is the policy in the DNS in the first place?
	It keeps looking less and less like a good fit.
	Add a way to find a DKIM policy server to the DNS
	and let it hand out the actual policies.  This
	should make it very easy for per user policies without
	having to worry about namespace collisions which is
	what the underscores where trying to prevent with SRV.
	
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Doug Barton <[email-masked]>
Date: Wed, 26 Jul 2006 23:26:40 -0700

On the one hand, because I have in the past wanted something similar to what
you're proposing, the theoretical concept of these super wildcards is
appealing. However, from a protocol standpoint the idea gives me a serious
case of the screaming heebeejeebees.

So, I have a question ...

Hallam-Baker, Phillip wrote:

> To give some more context. At present a DKIM policy record can make two
> useful statements that we all agree are essential:
> 

[ ... ]

> So the problem with policy is how to declare an email signing policy for
> **.example.com that takes effect if there is no more specific policy. The
> objective being to specify policies such as:
> 

Ok, your problem statement makes total sense to me, but I think you're
missing a third option. I'm assuming that the DKIM protocol has a way to
handle total absence of a policy for a domain. So, what if you added a
heuristic to the DKIM protocol that says, "If I do not find a policy at this
node, I will go down the tree until I either find a policy, or hit the TLD."

In regards to your problem of spammers that try sending mail from
1.2.3.4..99.spammer-domain.tld, if the spammers have control over that
domain and can add a node at that point, it will eat up resources to walk
that tree, no doubt. OTOH, if they are playing silly buggers with a domain
they don't have control over, I assume DKIM is smart enough to say that if
there are NO records at all for a node, that it isn't legitimate? Either
way, I agree that the issue you raise is still a problem, however I think
that my proposed solution places the burden for dealing with that problem in
the DKIM protocol, which is arguably where it belongs.

Doug

-- 

	If you're never wrong, you're not trying hard enough

---

From: Julian Mehnle <[email-masked]>
Date: Thu, 27 Jul 2006 09:09:50 +0000

Doug Barton wrote:
> > So the problem with policy is how to declare an email signing policy
> > for **.example.com that takes effect if there is no more specific
> > policy. The objective being to specify policies such as:
> >
> heuristic to the DKIM protocol that says, "If I do not find a policy at
> this node, I will go down the tree until I either find a policy, or hit
> the TLD."
>
> domain and can add a node at that point, it will eat up resources to
> walk that tree, no doubt.

We (the SPF folks) once debated doing such an upwards domain walk for SPF, 
but decided against it for exactly the reason you mention above.  It was 
simply deemed too costly.  Finding an applicable policy for a sub-domain 
is still an unsolved problem, though.

> OTOH, if they are playing silly buggers with a domain they don't have
> control over, I assume DKIM is smart enough to say that if there are NO
> records at all for a node, that it isn't legitimate?

Yeah, mail with a non-existent domain as the sender (envelope sender, From/ 
Sender headers, whatever) should be rejected anyway.  The problem remains 
for sub-domains that actually exist.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Jul 2006 22:46:36 -0400

A couple of points from a couple of messages, perhaps not all that important:

>1) During a zone transfer

With DNSSEC the wildcard isn't on the wire, but you can tell if it's 
been used.  (The label count in the signature record.)

Also, the wildcard could be seen when it is queried for.

Neither of those points matter much though.

>If neither of these features existed there would be no reason for wildcards to
>be mentioned in the DNS spec at all. They would be a server configuration
>feature, no more. It would not matter how the wildcards were defined, there
>would be no interoperability issue.

Wildcards are defined in sections 4.3.2 and then 4.3.3 in RFC 1034, 
which are sections on the algorithm that a server follows to generate 
an answer.  I don't recall that 1034/1035 connects wildcards and zone 
transfers - that linkage didn't come up until a thread by Dan 
Bernstein on the wcard draft.

See: 
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01702.html, 
note the "tone" of a thrown in idea at the end of the message.  I 
think the zone transfer-wild card linkage came from that message.

Wildcards are a minimal case of answer synthesis.  The interop 
problem is getting all the servers to act the same way for a zone. 
If they (the old dudes) couldn't have shoehorned it into AXFR, then 
you'd have seen some other signalling mechanism in place.  (As Dan 
said - rsync.)

>2) All mail that this domain originates is signed.

For clarification, what's the difference between a mail domain and a 
DNS domain?

>Checking every node for a policy record is not acceptable. This is made worse
>when you use a prefix convention (similar to SRV) as you can't even use a
>traditional wildcard.

There was some HTTP cookie policy talk given in Montreal that 
concluded the same thing.  They (too) found that you can't tie 
meaning to the label depth of a zone.  E.g., ietf.org is less of a 
"TLD" than 198.in-addr.arpa.

>	Why is the policy in the DNS in the first place?

'Cuz it's convenient. You can drive a screw with a hammer if you try 
hard enough.  I don't mean to slam DKIM over this, it seems all the 
rage these days.  (I think I ranted on this recently.)

>	It keeps looking less and less like a good fit.

BSD Sockets are a bad fit too.  But we've made do all these years. 
(They [other old guys] thought that the interface to the file system 
was more general than the interface to the network and not vice 
versa.  Oops.)

There are better fits out there - IRIS or maybe LDAP/X.500.  But 
would you want an operator to have to maintain that too?  Or have 
IRIS or LDAP/X.500 being fudged into NAT devices too?  Don't make 
those protocols suffer DNS' fate.

Making the data available is only half the problem.  Mail/SMTP has to 
deal with the fact that it is historically promiscuous - the absence 
of policy isn't clearly a devious mail domain, it could be just a 
little innocent old mail domain that hasn't kept up.  This is 
something the DNS hammer can't overcome.

>	If you're never wrong, you're not trying hard enough

I don't have to try hard to be wrong.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 30 Jul 2006 13:24:55 -0700

>  Neither of those points matter much though.

One may wonder about exposing zones when non-DNSSEC DNS utilize this
scheme, or the related overhead associated with placing redirection RRs
at every NSEC.

> > If neither of these features existed there would be no reason for 
> > wildcards to be mentioned in the DNS spec at all. They would be a 
> > server configuration feature, no more. It would not matter how the 
> > wildcards were defined, there would be no interoperability issue.
> 

As currently defined by DKIM, a mail-domain extends to all subdomains
irrespective of delegation.  Policy is to be acquired for an
email-address's domain when there is not a DKIM signature, or when there
is a DKIM signature by a different parent domain.

> > Checking every node for a policy record is not acceptable. This is 
> > made worse when you use a prefix convention (similar to SRV) as you
> > can't even use a traditional wildcard.
> 

The prefix technique used for the new "super" wildcard scheme overcomes
issues at delegation points, but then a few new problems are created.
As a confluence of RRs become placed within this common location, and
their use evolves, it will not be possible to determine which RR types
exist within this location without querying for RR types separately.
Back to hunting.

This hunting could be ameliorated by also listing the RR types found
within this common node, in addition to the location of the common node
within a new RR type (rather than reusing the PTR RR).  In addition, the
new RR type, rather than a convention for a "**" label, could trigger
the desired behavior for the RR type.

_policy 	IN PWCARD 	<list-of-RR-types> <this-location>
_policy		IN POLICY-X	blah, blah, blah
_policy		IN POLICY-Y	blah, blah, blah
... 

Script or a server embedded function could then place at every node:

*		IN PWCARD <> <that-location>

Transfers might be able to determine whether these wildcard PWCARD RR
types need to be transferred or whether they will be synthesized.  For
the newer version of DNS, any query for _policy would return the results
'as-if' there was a wildcard _policy.*.<domain> for all the policy RRs
located at "this location".

> rage these days.  (I think I ranted on this recently.)

Actually, this approach may not be all that convenient.  There is also a
desire to list designated signing domains.  When your offices uses DKIM,
a means to improve acceptance of your message could be to designate this
work domain's signature for your private email domain.  For a small
outfit, this might mean designating their provider's and
sub-contractor's domains.  

To allow for a small answer, one approach for creating this list would
be to have a query of:
	<signing-domain>._dkim-p.<email-domain>

The records could then be:
*._dkim-p 		IN DKIM-P "<email-domain> & non-designated"
work-domain._dkim-p  	IN DKIM-P "<work-domain> & non-designated"
*.isp-domain._dkim-p	IN DKIM-P "<*.isp-domain> & non-designated"

How would this work when the prefixed wildcard scheme requires that a
query for the prefixed record be made for the DKIM-P RR, followed by a
query for the PWCARD RR, and then followed by a query for the DKIM-P RR
at the redirected location?  To obtain the Designated Signing Domains,
yet another query is required.  This has not substantially reduced the
number of queries when a convention also requires that policy be
established within 4 levels below the TLD.

> something the DNS hammer can't overcome.

Agreed. Few will search for policy.  Policy would be required for every
non-signed message and every message signed by a domain that does not
correspond to that of the email-address. 5 additional transactions is
not very reasonable.

Few will want their providers to prohibit use of their desired
email-address.  DKIM deals with concerns related to who should handle
abuse issues and whether a message from a list of financial domains is a
phishing attempt.  Frankly, neither of these expected uses requires that
policy be retrieved.  To thwart display-names only being visible,
look-alikes, and international domains, anti-phishing requires that the
message be annotated as being signed by a trusted domain. (Perhaps a
domain found in the address book or a correspondence log.) Fortunately
neither of these uses when properly implemented requires that a policy
record be retrieved.

-Doug