Subject: [ietf-dkim] Re: Protocol Policy Publication

From: Frank Ellermann <[email-masked]>
Date: Tue, 27 Mar 2007 21:46:25 +0200

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 27 Mar 2007 14:39:11 -0700

I don't mind repeating the discussions. I do mind ending up with the same result which was in the end worst case for all concerned AFAIAC.

There is a reasonable solution here that meets all our needs. I would rather argue for that solution than simply assume that DNSEXT are going to be unreasonable.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Frank Ellermann
> Sent: Tuesday, March 27, 2007 3:46 PM
> To: [email-masked]
> Subject: [ietf-dkim] Re: Protocol Policy Publication
> 
> > 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
> 
> >   * 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
> >
> > 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.)
> 
> > 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?
> 
> > 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:
> 
> > 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.
> 
> > 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
> 
>