A few comments below. Hope I'm not too late if you're
submitting this as an individual I-D this week.
That depends on whether it bounces again.
Use of the word "policy". There are so many things that are
called "policy", and I'm not sure which ones you mean here.
You might want to introduce what's included in that
definition, and importantly what's not. An example of what's
not might be a security policy saying that all computers
connected to your LAN must be running current anti-virus
software. There's also the concern about how imperative (vs.
declarative) such policies may be, given the recipient's
freedom to do as they choose and possible local legal
considerations. That's why I expect we'll end up with the
word "practices".
We were invited to comment on the policy component as criteria for speaking on
the issue at the BOF. I am quite happy to call it anything else.
Lets call it the Splunge.
Section 3.1, paragraph 2: What do you mean by "constant recourse"?
The requirement to have a policy record for each protocol approved by the
DNSEXT working group. Given the behavior of the co-chair at our last IETF
meeting I for one do not want to have as little exchange with that group as
possible.
Later in the section, what constitutes a change to DNS
infrastructure?
Any change that requires changes to the configuration of existing servers.
Is creation of a new RR included?
Yes, unless the DNS infrastructure as deployed is able to handle it without any
changes to either software or configuration.
Section 3.3 example: Why can't this sort of information be
included in key records published by the domain?
Because the key record only describes the key, not the domain in which the key
is used.
If SHA-1 is broken and a zone moves to dual signing its mails with RSA-SHA1 and
RSA-SHA512 an attacker can perform a downgrade attack on the message by only
creating the fake RSA-SHA1 signature header.
The signature policy has to describe the minimum characteristics of the
signature.
Obviously a key record cannot say anything about the unsigned message which is
the most important case where we need a policy record.
Section 3.4, paragraph 1: "principle" -> "principal" As you
later mention, even if a new RR is defined, that doesn't
remove the need for heuristics or search strategies (although
they may be simpler).
That depends.
If you do it my way you have an algorithm guaranteed to terminate in three
steps in all circumstances without exception. That is not a heuristic or a
search strategy that creats a DoS issue.
Paragraph 2, what you mean by the "dynamic DNS component"?
The Microsoft DNS server accepts Dynamic DNS updates and updates via the
registry APIs.
Some folk intent on demonstrating that Windows DNS server does too support new
RRs demonstrated that it was possible to inject the bit patterns for new RRs
via DNS dynamic update. The problem being that the changes are not saved out to
the static DNS configuration file.
So what we end up with is a network administration nightmare, a server that
will change the network configuration unexpectedly when it reboots. Try
administering that in a production environment.
When Microsoft say that their DNS server does not support new RRs they mean
that they have performed regression tests and identified specific failures that
are incompatible with production use.
Policy discovery strategy example: As SSP is currently
written (subject to change, of course!) the lookup would be
to _policy._domainkey.alice.example.com. Alice is a
subdomain, right, and not that person at example who so often
tries to communicate securely with Bob? The example doesn't
describe what happens if the result is NXDOMAIN vs. if it's
NOERROR with no answer (or is this the same?)
I think we are all OK with defining policy for alice.domain.com.
The problem is defining a policy for *.domain.com so that we can discover the
policy for:
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.domain.com
Which may not exist of course.
I'm really confused as to why the use of a PTR would help
here. If example.com wants to publish a policy, and some
host named alice.example.com exists, and a message is sent
from alice(_at_)alice(_dot_)example(_dot_)com, it still won't find
example.com's policy. We don't want to require that an extra
record be published with every A record in the domain!
*.domain.com PTR _default.domain.com
_policy._default.domain.com TXT "Never sends mail"
1) Lookup (_policy.A....z.domain.com, TXT) = NULL
2) Lookup (a....z.domain.com, PTR) = "_default.domain.com"
3) Lookup (_policy._default.domain.com)
The issue about the A record is irrelevant, the DNS wildcards don't work the
way you want them to regardless of whether or not you use a new RR. A DNS
wildcard only matches a DNS node that has absolutely no records.
So regardless of the approach you have to use synthetic wildcard expansion when
you do DNSSEC or attempt a zone transfer.
This is why you want infrastructure so every protocol can use the same PTR:
@.domain.com PTR _default.domain.com
_dkim._default.com TXT "no mail"
_smpp._default.com TXT "always offer TLS"
_http_default.com TXT "always offer TLS"
Where @ stands for synthetic wildcard is much better than:
@.domain.com DKIM "no mail"
@.domain.com SMTPP "always offer TLS"
@.domain.com HTTP "always offer TLS"
....
In the future I expect upwards of 100 routinely used policies
The PTR indirection mechanism adds only one record per node which is not an
excessive overhead.
The define a RR for every protocol policy approach does not scale for new
protocols it is utterly broken.
In step 3 of your example, is this the point at which the
policy for DKIM is differentiated with that of other
services? Does _dkim become _emailtls to retrieve the policy
having to do with use of TLS by MTAs?
The same prefix is used to refer to the protocol in both places. So first we
look for _prefix at the domain node itself, if it is not found we attempt to
follow the politer and then look for the node.
The prefix can be _policy._domainkey. Or _dkim or whatever people want to do.
Section 4.1, DKIKM -> DKIM
Hope this helps; this was a quick and not-so-thorough review.
It was very useful, it has helped me discover that my approach provides an
advantage besides not having to wait for deployment of new DNS infrastructure
or wait for the agreement of a working group that has taken ten years to
deliver on its promise of DNSSEC.
Phill
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html