Damn the cutoff for the -foo drafts was last week ! Actually my idea here was to persuade as many people as I could to plagarize the idea so maybe I would not need to write it up.
> -----Original Message----- > From: Stephen Farrell [mailto:[EMAIL PROTECTED] > Sent: Friday, June 09, 2006 4:35 PM > To: Hallam-Baker, Phillip > Cc: ietf-dkim > Subject: Re: [ietf-dkim] Montreal agenda, other than base > > > Hi Phil, > > That looks like it might be interesting to discuss. > > I hope that writing it up as draft-hallam-dkim-foo isn't too > much work, since that's the barrier-to-entry:-) > > S. > > Hallam-Baker, Phillip wrote: > > I am not sure that I want to propose a different > architecture, it is conditional on whether we are going to > have an incompatible backwards change or not. > > > > I see two cases of interest here: > > > > Case One: Adopt SSP essentially as is without backwards > incompatible change. > > This is an entirely justifiable choice in my view. > > > > Case Two: Adopt a layered architecture that is capable of > supporting generalized policy statements. > > If we do make a backwards incompatible change we should > adopt a layered strategy and develop a framework for > expressing service configuration rather than the current one > off design that is entirely tailored to a single application > protocol and a single security enhancement. > > > > > > Layered Abstractions > > -------------------- > > > > In the second case I would propose that we design the DKIM > policy layer as a single instance of a policy framework that > is extensible and capable of supporting obviously needed > statements about other existing protocols. Demonstrating a > _capability_ is certainly not the same thing as defining a > specification to support that capability but I would want to > see the demonstration that we are not leading the Internet > down an architectural dead end. > > > > Clearly there is a strict limit to the detail that is > practical within the context of DNS publication of service > configuration data, clearly we do not want people entering > war and peace into the DNS to configure an email service. It > is bad enough the fact that airline check in assistants have > to write novels while checking people in for a flight from > Boston to Washington. > > > > > > But the statements we want to make for DKIM are instances > of more general requirements: > > > > "Every email from example.com has a DKIM signature with > characteristics {x, y, z}" > > "The example.com email server always offers STARTTLS > with charateristics {p, q}" > > "http://example.com supports HTTP/2.0" > > > > > > I believe that appropriate layering in which we adopt a > framework that is capable of supporting all these > requirements will result in a smaller, more compact and > consistent specification in which the scope for 'unexpected' > edge cases is reduced. > > > > Note that it is quite likely that the existing SSP might be > used almost unchanged. Certainly there will be a need for tag > value pairs and at most limited structure. > > > > > > Policy Discovery and Wildcards > > ------------------------------ > > > > This approach allows for the otherwise thorny problem of > policy discovery wildcards to be approached in a much more > satisfactory manner than has been suggested to date. > > > > As we know the DNS wildcard scheme is not ideal for our purposes: > > > > 1: There is no way to specify a wildcard of the form > > _prefix.*.example.com > > 2: The prefix *.example.com does not match > host1.example.com if there > > is any record defined for that node > > > > The second problem exists whether or not a new record is > defined. The only way to address this problem within the > existing DNSSEC framework is to add support at the DNS server > level for synthetic wildcards. So the admin enters a policy > for ?.example.com which is expanded out to create records for > every host in example.com that does exist and does not have a > policy record otherwise defined. > > > > The first problem is the hard one, one solution is to > define a new resource record. This is not sustainable as an > infrastructure. Every internet protocol will need a DNS > policy record associated with it so we would need to define > 10,000 new RRs just to support existing protocols. > > > > A better solution is to define a record to act as the > wildcard record. The use of the PTR record is currently > undefined for the forward DNS and allows the needed > information to be defined. Alternatively a new record could > be specified, but this would then make implementations > dependent on the deployment of DNS extensions. > > > > The policy discovery strategy then becomes: > > > > To discover the policy for DKIM at alice.example.com: > > > > 1) policy = lookup (TXT, "_dkim.alice.example.com") > > IF policy <> NULL THEN RETURN policy > > > > 2) pointer = lookup (PTR, "alice.example.com") > > IF pointer == NULL THEN RETURN NULL > > > > 3) policy = lookup (TXT, "_dkim." + pointer) > > return policy > > > > This strategy is guaranteed to always return in three steps > without exception and is 100% compatible with the deployed > DNS infrastructure with no known exceptions. > > > > The strategy is can be applied to an arbitrary protocol and > allows for much simplified administration. In most networks > the majority of the host configurations are essentially > identical. Only a few machines that perform special roles > such as mail handling or file server support will require > custom configuration. > > > > The redirect strategy allows the administrator to define > standard network policy configurations, for example in an > enterprise there would probably be defined network policy > configs for standard desktops, standard laptops and developer > machines. If necessary the standard config may be overriden > for individual domain names. > > > > The redirect stategy does not depend on walking up the > chain, finding a zone cut or anything similar, it also > overcomes a frequent objection to such attempts, it is does > not allow an unauthorized intermediate DNS server to override > policy definitions made by a subordinate zone - except of > course to the extent that it can do this by changing the > delegation and hijacking the entire zone. > > > > > > > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
