[ietf-dkim] Montreal agenda, other than base

[Stephen Farrell]

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.
> 
> 
>