ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Montreal agenda, other than base

2006-06-09 13:46:10

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