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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 9 Jun 2006 13:47:16 -0700

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-masked]] 
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 09 Jun 2006 21:51:11 +0100

> Damn the cutoff for the -foo drafts was last week !

You're in luck, the actual deadline in June 19 [1].

Isn't that handy:-)

S.

[1] http://www.ietf.org/meetings/cutoff_dates_66.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html