Hallam-Baker, Phillip wrote:
>> [mailto:[EMAIL PROTECTED] On Behalf Of Jim Fenton
>>
>> (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.
>
>
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.
> 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'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?
> 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.
>
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.
>> (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.
>>
>
> 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.
>
"...is a major cause": currently? I don't see how we can design any
protocol that is misimplementation-proof.
> 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).
>
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
