[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
What we had hoped to do in the next revision of the
allman-ssp draft was to unify it as much as possible with
Phill Hallam-Baker's draft. I opened three new issues on
April 16 that I think need to be resolved in order to do that.
(1) Use of XPTR records for SSP. The idea here is to create
a more general policy mechanism that can be used by WS-* and
such. There were about 20 messages discussing this from 5
people. I'm not reading a clear consensus on this.
I would order this slightly differently. The point of XPTR is that it avoids
the need to create new RRs for future policy records. The reason I believe this
is essential is that in the future I anticipate a policy record for every
protocol and I anticipate a vast increase in the number of protocols as we
enter the machine-machine communication era.
Current Internet protocols are almost exclusively designed either for human
endpoints directly or to support protocols that terminate at human endpoints.
This constrains proliferation of protocols. Once we are in the Web Services era
proper we lose this constraint. I expect development of these protocols to be
organic, bottom up with the standards process only kicking in at a late stage.
If I am right a means of distributing protocol policy will be essential to
manage the proliferation, moreover gating deployment on IETF action required to
allocate a finite resource (RR codes) and update the DNS server infrastructure
is simply usustainable.
(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.
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.
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 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.
3) There is an advantage to DKIM in encouraging deployment of DNS servers
capable of DNSSEC.
(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.
If we put it on the table and the DNS cabal raise an objection which is
sustained for cause it will be harder to resist if they make complaints in
areas where they don't really have a cause.
I thought I would want 'I sign all mail from *.example.com' but I don't, and I
don't think anyone else really does.
There are three cases of interest:
1) The node exists in the internal DNS and the external DNS
'example.com', 'alice.example.com'
2) The node exists in the internal DNS but not the external DNS
'bob.example.com'
3) The node exists in neither DNS
'spammer.example.com'
If the site does not have split DNS the only cases that appear are 1 and 3.
I don't think that case 1 is the sort of thing you want to handle with a
wildcard. If you care enough to sign the mail and setup the key records then
you care enough to stipulate the policy.
Case 2 is an interesting edge case, but I don't think it is realistic. If I am
hiding the existence of the node from the external world it should not be
sending mail.
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).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html