ietf-dkim
[Top] [All Lists]

Re: tree walking (was - Re: [ietf-dkim] user level ssp)

2006-09-07 15:40:13
william(at)elan.net wrote:

On Wed, 6 Sep 2006, Jim Fenton wrote:

The tree-walking issue (separate from the user-level SSP) issue has
concerned me too.  The allman-dkim-ssp-02 draft has it down to 2 queries
-- much improved from the previous revision, in part because of the use
of a separate RR.

Are you sure there is a limit? I distinctly remember a paragraph from
your draft that says that in case of NODATA the verifier needs to
walk down the tree until it reaches root.
Check draft-allman-dkim-ssp-02; the algorithm has changed substantially
in this revision.

Also while I think separate RR is right way to go, I have to note
that since you want to already use TXT for public key, you might
as well (ab)use it for these policy records too - otherwise you'd
cause difference in adoption rates for those wanting to use
signatures and those who want to use policy, making using police.
And personally I think public key is the one that a lot more
belongs into being separate RR (binary CERT preferably) though
in reality you should just avoid putting large public key records
in dns all together as it brings further abuse and problems for
caching name servers that can be avoided otherwise.
Of course the use of a separate RR will require (probably lots of)
further discussion, but I see the considerations relative to the IAB DNS
considerations draft (draft-iab-dns-choices-03) as being rather
different.  In the case of key records, we know exactly where to look
using the selector and domain name, and the record is either there or it
isn't.  The use of a prefix doesn't hinder that at all.  In the case of
SSP, you can do the same thing with TXT records and a prefix, but it
requires additional queries to distinguish the nonexistent domain case
from the nonexistent policy record case.  That is an argument in favor
of use of a separate RR, but we'll see what the consensus is.

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