ietf-mailsig
[Top] [All Lists]

Re: wildcards, was Re: dkim technology?

2005-08-02 17:25:38

In 
<Pine(_dot_)LNX(_dot_)4(_dot_)60(_dot_)0508022341090(_dot_)31690(_at_)hermes-1(_dot_)csi(_dot_)cam(_dot_)ac(_dot_)uk>
 Tony Finch <dot(_at_)dotat(_dot_)at> writes:

On Thu, 14 Jul 2005, wayne wrote:

One example, is the language about the new DNS RR types probably won't
be accepted by the folks on namedroppers, and I can give some
suggestions about what will be more likely to be accepted.  I suspect
that the tree-walking in the current draft will also be very unpopular
with the DNS folks.

Where is the tree-walking stuff in DKIM? I can't find it in the current
draft.

The tree-walking is in draft-allman-dkim-ssp-00.txt section 5:

5.  Query and record format

   Signing policy records for a domain are published in key servers as
   the "_policy" selector.  Signing policy records for individual
   addresses are published as the "user._policy" selector.

      NON-NORMATIVE RATIONALE:  Use of a synthetic selector allows non-
      DNS based access for signer policies.

   To avoid a Denial-of-Service attack, signer policy searches for
   signing policy checks of very deeply nested domains MUST strip off
   all but the last five components of a domain name.  If a policy
   record is not found, the verifier MUST repeat the request to
   successively higher levels of the domain hierarchy until the root is
   reached.  This allows subdomains to inherit the signing policy of
   their parent domains without allowing attackers to specify extremely
   deep subdomains such as
   "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".
   If presented with such a signing domain in a DKIM-Signature header
   field, the search for a policy record would start at
   "x.y.z.example.com" and proceed upwards.  Verifiers MUST stop
   searching at the first policy record they encounter.




-wayne

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