-----Original Message-----
From: Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
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.