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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] Montreal agenda, other than base, (continued)
- RE: [ietf-dkim] Montreal agenda, other than base, Hallam-Baker, Phillip
- Re: [ietf-dkim] Montreal agenda, other than base,
Stephen Farrell <=
- RE: [ietf-dkim] Montreal agenda, other than base, Hallam-Baker, Phillip
- RE: [ietf-dkim] Montreal agenda, other than base, Hallam-Baker, Phillip
RE: [ietf-dkim] Montreal agenda, other than base, Hallam-Baker, Phillip
|
|
|