Subject: RE: [ietf-dkim] The URL to my paper describing the DKIM policy options

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 Jul 2006 09:55:21 -0700

CC'd to namedroppers for wider discussion.

There are two wildcard problems

1) Wildcards do not match a node if there is any data at the node
	*.example.com TXT "hello" will not match if there is any record at a.example.com

2) It is not possible to define a midpoint wildcard 
	_prefix.*.example.com cannot be defined

The proposal is to use automatically generated records to address the first problem and the PTR hack to address the second.

So for example we might add a new 'superwildcard' record to the configuration language of BIND or your favorite DNS server that recognises the ** wildcard entry which matches with the naïvely expected semantic of 'match any node that does not already have an entry defined for this particular record'.

So our configuration file is:

**.example.com      PTR  _default.example.com
a.example.com       A    10.0.0.1
_dkim.example.com   TXT  "dkim record"

This is then processed by a preprocessor to produce the actual DNS zone:

**.example.com      PTR  _default.example.com
a.example.com       A    10.0.0.1
a.example.com       PTR  _default.example.com
_dkim.example.com   TXT  "dkim record"

Note that DNSSEC already creates the need to separate the configuration file from the zone file. If we were using DNSSEC we would also be inserting the various key and signature records etc.

The handling of ** can be defined to create 'cut outs' for cases where you would expect them to occur. So if we have a delegation to another DNS server we would naturally expect that the superwildcard would not apply to anything in the delegated zone.

Note that we need superwildcards whether or not we introduce a new RR and that this will require code to support the administrators. The reason this is acceptable is that 1) it is still possible to do the job by hand 2) the tool can be bolted in to practically every existing configuration without disrupting the installed servers.

Consider however what happens when we have a large number of policy records and each one has its own record and there is no PTR hack:

**.example.com      DKIM  "dkim record"
**.example.com      DKPOP "dkop record"
**.example.com      DKSSL "dkssl record"
**.example.com      DSMTP "dsmtp record"
a.example.com       A    10.0.0.1
b.example.com       A    10.0.0.1
...
z.example.com       A    10.0.0.1

After processing we will have 4*(26+1) synthetic nodes created and if they are signed each will have a signature record as well.

This is not good if the policy records are all saying the same thing 'this host does not provide this service'.

Using the PTR approach this becomes:

**.example.com      PTR  _default.example.com
a.example.com       A    10.0.0.1
b.example.com       A    10.0.0.1
...
z.example.com       A    10.0.0.1

_default.example.com      DKIM  "dkim record"
_default.example.com      DKPOP "dkop record"
_default.example.com      DKSSL "dkssl record"
_default.example.com      DSMTP "dsmtp record"

Now we only create 26+1 new synthetic records.

We can also use the PTR records to perform class based system administration:

**.example.com      PTR  _default.example.com
a.example.com       A    10.0.0.1
a.example.com       PTR  _server.example.com
b.example.com       A    10.0.0.1
b.example.com       PTR  _server.example.com
c.example.com       A    10.0.0.1
...
z.example.com       A    10.0.0.1

_default.example.com     DKIM  "dkim record"
_default.example.com     DKPOP "dkop record"
_default.example.com     DKSSL "dkssl record"
_default.example.com     DSMTP "dsmtp record"
_server.example.com      DKIM  "dkim record"
_server.example.com      DKPOP "dkop record"
_server.example.com      DKSSL "dkssl record"
_server.example.com      DSMTP "dsmtp record"

In this case we have two separate management groups, machines a and b are in the server group and we can set the parameters for both machines at the same time. Everything else is in the default group.

Note that there is still value to using the PTR hack even if you are going to define a specific policy record.

If someone can demonstrate (as opposed to give opinions as to the state of their intestines) that something ugly happens if PTR is used we could use a different record or even create a new one.

For the sake of example I have shown the scheme with policy specific RRs. The redirection to a prefix value is not essential to the demonstration except insofar as it is better that this process does not result in spurious nodes being created. I could have used a PTR to an unprefixed label:

a.example.com      DKIM  "dkim record"
b.example.com       PTR  a.example.com

As is clear from the example however there is now no 'wildcard penalty' for using a prefix record. Although eliminating the wildcard penalty was my original reason for developing this scheme it is not the only benefit. I think that we need this type of functionality regardless of whether we create new RRs or not as otherwise the number of synthesized policy nodes will quickly explode. Every Web service will require a policy specification, the platform requires it. A domain might easily have 100 or more Web services defined. 

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 11:52 AM
> To: Patrick Peterson
> Cc: Hallam-Baker, Phillip; IETF-DKIM
> Subject: Re: [ietf-dkim] The URL to my paper describing the 
> DKIM policy options
> 
> Patrick Peterson wrote:
> 
> >>----- Original Message -----
> >>From: "Hallam-Baker, Phillip" <[email-masked]>
> >>To: "IETF-DKIM" <[email-masked]>
> >>Sent: Wednesday, July 12, 2006 2:05 PM
> >>Subject: [ietf-dkim] The URL to my paper describing the DKIM policy 
> >>options
> >>
> >>
> >>I submitted the draft in both pdf and txt. Only the txt is 
> shown, the 
> >>more readable pdf is attached.
> >>
> >>http://www.ietf.org/internet-drafts/draft-hallambaker-pcon-00.txt
> >>    
> >>
> >
> >I think this is a great idea and am surprised it didn't 
> generate more 
> >traffic on the list. It's not easy to cram needed new functionality 
> >into a backward-compatible solution.
> >  
> >
> So I'm trying to understand the basic algorithm:
> 
>      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 
> 
> So I set up mtcc.com's bind config to:
> 
> $ORIGIN mtcc.com.
> 
> *        IN     PTR    mtcc.com.
> 
> Where mtcc.com is the top level and contains the policy 
> record. When I choose a label that doesn't have any other 
> labels (say, frogger.mtcc.com) it doesn't return anything as 
> TXT so I go to step 2, it points back to mtcc.com and 3 succeeds.
> 
> However, when I use a label *with* a record:
>     fafner        IN    A    216.102.208.11
> 
> the host -t PTR fafner.mtcc.com returns a reply with an 
> answer count of zero.
> Which is just the same thing that happens with TXT.
> 
> So I guess I must be missing something because wildcarded PTR 
> records seem to be handled the same as any other wildcard 
> which is to say, not the behavior you'd hope for.
> 
> Phill?
> 
>        Mike
> 
> 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 Jul 2006 17:17:34 -0700

John,

You are mistake, the point is to retrieve policy data, not reputation data. In point of fact I have already proposed the use of a URL pointer as a means to publish reputation data. This is how secure letterhead works.

We already have policy data, and at the moment we have a heuristic hack to hunt arround for the SSP record. The idea here is to try to meet all the issues that have been raised:

Mail administrators
	The use cases include the ability to make policy statements such as 'no email is sent from any address in this domain. This is fully supported.

DNS mavens
	Have raised concerns about the ad-hoc approach, in particular the fact that the SSP semantics as currently defined do not align with the DNS administration semantics. At present a delegation has very clear semantics, the handover of control is all or nothing. The only measure of control retained by the upper level domain is the ability to revoke the delegation at a later date. This seems an entirely legitimate concern. I believe that the pointer scheme addresses this concern.

Immediate deployment
	The pointer scheme allows full flexibility with wildcards and is entirely implementable with the existing DNS as deployed. Even if a new record is cut the only parties that are required to upgrade are those parties that decide that they need the extended wildcard specification capability.

DNSSEC deployment
	No changes are required to the semantics of DNSSEC wildcards. It is not necessary to rev the DNSSEC drafts to support this mechanism. The utility and advantage of using DNSSEC with DKIM remains prominent. The chicken and egg situation where DKIM is meant to provide an incentive for DNSSEC deployment but deployment of DKIM is dependent on deployment of DNSEXT extensions (and thus in practice DNSSEC) is avoided.

Future proofing
	The pointer scheme offers clear advantages over alternatives in the case where there are many protocol policy statements being published.

Efficiency
	The algorithm always terminates in three lookups without exception.

Given that we have a clear consensus that we need a policy statement I don't see a good reason to do a second best implementation. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Tuesday, July 25, 2006 6:29 PM
> To: [email-masked]
> Phill's hack is indeed clever, but it seems to me egregiously 
> premature to propose a standard way to retrieve reputation 
> data that doesn't actually exist yet.  We could equally well 
> come up with a rule to map the selector to a URL which would 
> work just as well albeit not as fast, again to retrieve 
> non-existent reputation info.
> 
> Let's finish the DKIM signature spec, then see if we can 
> agree to get out the smallest version of SSP on which we can 
> get reasonable agreement (probably two bits, one for signs 
> everything, the other for sends no mail), then we can return 
> to the grand plans.
> 
> R's,
> John

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Jul 2006 12:55:04 -0700

> [mailto:[email-masked]] On Behalf Of Scott Kitterman

> Is the concept of operations that these servers should sign 
> using the provider's key (so all signatures for the domain 
> are 3rd party) or that the provider should manage multiple 
> keys to support per domain keys and sign the messages first 
> party for the domain?

I think that this use case argues for a means of indirection as the signer may well change their config without notification to the originator.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 27 Jul 2006 12:24:44 -0700

+1

SPF is vastly better than MX 0 .

People really should not do that sort of thing. 

> [mailto:[email-masked]] On Behalf Of wayne
> Sent: Thursday, July 27, 2006 1:09 PM
> To: IETF DKIM WG
> In <[email-masked]> Steve 
> Atkins <[email-masked]> writes:
> 
> > On Jul 26, 2006, at 12:13 PM, Hector Santos wrote:
> >
> >> [mention of the SPF record "v=spf1 -all" as a "we never send email"
> >> notification]
> >
> > "MX 0 ." seems to be the standard way of asserting that a domain 
> > neither sends nor receives email. Shoehorning the same 
> assertion into 
> > multiple different pseudo-standards simply leads to contradiction.
> 
> "MX 0 .", like all MX records with bogus mail exchanges, in 
> effect says "I can not receive email".  This is not quite the 
> same as saying "I do not send email".
> 
> First off, the "MX 0 ." technique will cause queries asking 
> the root for A records, which don't exist.  The root servers 
> already get enough bogus queries, it doesn't seem like a good 
> idea to promote a technique that makes things worse.
> 
> Secondly, I have several domains that, while they never 
> *send* email, I do want to receive email for them.  Some of 
> these domains are stuff that used to be in use, pass on 
> obsolete email addresses on to the correct (newer) domain or 
> are used as spam traps.  However, others are because I want 
> to allow abuse reports for websites.
> 
> There are people who argue that any host that doesn't accept 
> an abuse@host email is in violation of RFC2142 and will block 
> email from these domains, even if that domain is used in the 
> 2821.HELO address rather than the 2821.MAILFROM or 2822.From: 
> address.  See rfc-ignorant.org for an example.
> 
> 
> So, I think the SPF record "v=spf1 -all" is much better than 
> using "MX 0 .".
> 
> 
> 
> > I don't see why people would pay any more attention to an SSP 
> > statement of such than they do to SPF statements of it. Just the 
> > opposite, shoehorning unneeded cruft into SSP makes it less likely 
> > that people will pay any attention to it, I'd think.
> 
> The SPF record "v=spf1 -all" case can be safely used to 
> reject connections for both the 2821.HELO and 2822.MAILFROM 
> during the SMTP session without any of the failure cases of 
> other SPF records.  That is, there are no problems with 
> forwarding and such.
> 
> I can see similar uses for a DKIM policy, although I can also 
> see the argument that having yet another way of saying the 
> same thing is not a particularly good idea.
> 
> 
> -wayne
>

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 28 Jul 2006 8:28 -0400

On Thu, 27 Jul 2006 16:33:42 -0700 Jim Fenton <[email-masked]> wrote:
>Scott Kitterman wrote:
>> On Thursday 27 July 2006 14:00, [email-masked] wrote:
>>   
>>> My requirements
>>>
>>> I sign all
>>> I sign nothing
>>> I sign only 3rd party
>>> I sign all and 3rd party
>>> I sign some mail
>>>
>>>
>>> My Policy/Practice
>>>
>>> I sign all - every piece of mail purported to be from me must be signed
>>>
>>>     
>> Must be signed by you are must be signed by anybody.  If the latter, 
it's 
>> trivially spoofable unless you have a list of others that are authorized 
to 
>> sign.
>>   
>Sure; third-party signatures will have a bigger dependence on
>reputation/accreditation/whitelists/etc. than originator signatures.
>
Or a bigger dependence on policy.  Leaving third party signatures to some 
non-standardized reputation service would effectively make domains that 
couldn't sign their own mail into second class internet citizens.

I think it much better to allow the policy protocol to enumerate which 
third parties are acceptable so small domain holders can be on the same 
footing as large.

Scott K