-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Frank
Ellermann
Sent: Tuesday, March 27, 2007 3:46 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] Re: Protocol Policy Publication
Hallam-Baker, Phillip wrote on the namedroppers list:
One issue that keeps coming up is the desire to publish
some form of
policy indication through the DNS.
I don't think that the IETF can or should ignore this. If we do we
will end up with the situation that most of us like least
and is the
reason that people tend to try to suppress such proposals - without
success. In particular we end up with:
* Protocols that perform 'tree walking' and other forms
of heuristic
policy discovery
* DNS RRs being hijacked for other purposes (e.g. SPF use of the
unprefixed TXT record)
* A proliferation of unregistered, untracked TXT and SRV prefixes.
* People sticking large chunks of XML text into the DNS
infrastructure itself
* People propose rival infrastructures (e.g. UDDI, XRI)
that attempt to superceed the DNS.
* It is not yet happening but if we make DNS RR
assignments into the equivalent of IP port numbers we should
expect to see unauthorized and uncontrolled RR assignments
becoming common.
I don't like any of the above. But from an architecture
perspective I
fully expect that in the future we will see most new
protocols specify
some form of policy layer. And expect the number of
protocols to start
to proliferate very quickly as Web Services / Mashups /
Semantic web
take hold over the next ten years.
I fully expect that the number of protocols that define
policy will be
of the order of hundreds a year. I don't believe that this is
compatible with the idea that each policy record should
have its own
RR. If we go that route we are committing to burn several hundred,
possibly thousand RRs per year to keep up with something
that is not
core to the DNS protocol. That is something that we must also avoid.
Rather than wait for the problem to become serious I would
prefer to
solve the problem now, once by anticipating it.
The solution I want to propose makes use of either one new RR or
possibly two new RRs. The objective here is to get ahead of
the curve
by anticipating a very large number of needs while sticking
to the core principles of DNS.
In particular:
AXIOM1 : The DNS infrastructure is the sole
authortitative lookup scheme for DNS names
COROLARY1 : If a protocol policy is bound to a DNS name
the mechanism for
discovery of that policy must be mediated by the DNS.
AXIOM2 : The DNS supports lightweight queries and responses
COROLARY2 : If the policy does not fit onto a few lines of
text the DNS should return a
pointer (i.e. URI) to the results.
COROLARY3 : If the form of the query requires any parameters other
than a DNS name the DNS result must be a pointer to a
service that can
handle the extended query (e.g. SIP, LDAP, etc.)
AXIOM3 : Adding a new protocol to the Internet should
not require any
change to the core Internet infrastructure,
including the DNS,
nor should this require consumption of any
finite resource (IP
ports, DNS RRs).
This analysis makes me believe that prefix records are the
way to go.
This creates a problem however since prefix records do not
work with
wildcards. In particular it is not possible to define a
wildcard of the form:
_prefix.*.example.com
Which is of course exactly the type of record that the DKIM people
need and many others want.
We can solve DKIM by issuing a new RR and getting round the
restrictive DNS wildcard semantics by using an
administrative wildcard
of some form. We can solve GEOPRV. OK so that is two new
RRs. And two
sets of synthesized data to be created at every node in the
DNS tree. That is arguably manageable.
What do we do if there are a hundred policy protocols to be dealt
with, each of which require their own administrative
wildcard expansion?
**.example.com DIKMP "DKIM"
**.example.com GEOPRIVP "..."
**.example.com NEWPROT1 "..."
**.example.com NEWPROT2 "..."
...
**.example.com NEWPROT100 "..."
Each of those administrative wildcards require a record to be
synthesized for every node in our zone. Say we have 200 nodes. That
means we have 20,000 synthetic records sitting around. Plus another
20,000 signatures if we are doing DNSSEC.
A much better way to solve this problem is to introduce a pointer
record into the scheme. This allows us to create the 'midpoint
wildcard' without changing or disrupting DNSSEC. The policy
discovery process then becomes:
1) Look for TXT at _policy.node.example.com
If found, return the result and terminate
2) Look for XPTR at node.example.com
If not found then return 'NOPOLICY'
3) Look for _policy.<xptr-result>
If found return the result
Else return 'NOPOLICY'
Under this scheme we still need a single administrative
wildcard for
the XPTR record. But every policy scheme can make use of
the same XPTR
record. So in the previous example we would only require 200+200
additional records. The combinatorial explosion is avoided.
So far the chief objection I have received has been 'this is
architecture, it might be wrong'. Which is of course right but
completely unactionable. We can forsee a problem, we have a
proposed
solution. It is quite possible that the proposed solution might not
anticipate every eventuiality but this does not seem to me
to be a good argument for ignoring the problem we can forsee.
What objective criteria can be defined for the correctness of an
architectural proposal? From my point of view the approach
that I take
is pretty minimal, very clean and I think it through at both the
protocol level (bits on the
wire) and the API level (is it possible to encapsulate this in a
fashion that makes sense).
With this addition I believe I can support the features required in
DKIM, SPF, and anything built on WS-Policy. That may not cover
everything but it does at least get us ahead of the fire.
If I am right we avoid what could become a serious problem
within a few years.
Growth in the number of Internet protocols has largely been
constrained by the fact that they have been mostly targetting
human-human and human-machine interaction.
Once we get into the detailed area of machine-machine
interaction the
problem space becomes huge, much larger than OASIS, W3C,
ITU and IETF
combined. Worse still expect that most of those protocols
are going to
be designed by people who have no real concept of the DNS
except what
they learn through administering protocols such as DKIM. For every
standards track proposal there will be tens of proposals
that never make it there.
Anyway, since we are told that it is easy to get a new RR
assigned I
am going to propose the XPTR RR as a standards track
proposal. It has
to be STANDARD, not EXPERIMENTAL or else the DKIM working
group will be unable to make use of it.
The question then is should this be a proposal made to DNSEXT or a
personal submission or what?
Sounds like a plan for a new WG. I'd hate it if DKIM is
forced to repeat old MARID discussions. Can you explain why
something in the direction of UNAPTR won't do what you want ?
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html