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

[Jim Fenton <[e-mail]>]

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